読者です 読者をやめる 読者になる 読者になる

MOONGIFTのプロジェクト管理ブログ

MOONGIFTのこれまでの経験を基にしたプロジェクト管理に関するブログです。MOONGIFTではプロジェクト管理のアウトソース、コンサルティングを承っております。info@moongift.jpまでお気軽にお問い合わせください。

プロジェクトにおける最も重要な要素とは?

いわゆる

  • モノ(機能、品質)
  • カネ(予算)
  • 時間

は相互に関係し合っています。機能が増えれば予算も、開発する時間も必要になるでしょう。かといって人を追加投入すれば済むものではないのは良く知られたところです。

さて、この4つの要素の中で最も大事なものは何でしょうか。私としては時間を最重要視しています。時間だけは決して取り戻せない、万人に共通のリソースだからです(大企業などがM&Aを通じて時間を金で買った、なんて話もありますが、そもそもお金があるならシステム開発なんて考える必要もない訳で、今回は無視しします)。

機能をムダに増やして時間をかけた結果、投入すべきタイミングを逃す可能性があります。予め決めたマイルストーンに従って、一旦区切りをつけることが大切です。そこで一つのリリースを設けることで、残った機能は追加開発という形にできます。いつまでもだらだらと開発を続けるのはリソース的にもビジネス的にも大きな間違いになるでしょう。

時間を軸として考える場合は、機能を思い切って削る決断を迫られることになるでしょう。そのため、そもそもの開発段階において優先順位を設けてプロダクトマネージャーが判断する、必要なものから順番に開発を行っておく必要があるのです。2割の機能で8割のユーザニーズは満たせるというのはよくあることで、メインの機能を予め開発しておけば大抵のことは足りるのです。

また、時間を軸としておく(絶対軸という訳ではなく、中心軸として)ことで、予算も自ずと動きづらいものになります。後は機能をフレキシブルに変化させることで柔軟なプロジェクト管理が可能になるわけです。

信頼は小銭の貯金

アジャイル開発の肝と言えるのは信頼だと思っています。パートナー、メンバーそしてチーム全体の信頼関係がなければアジャイル開発は成り立たないとさえ言えます。

相手との信頼関係をどう築くか、それは成功体験の積み重ねになります。もし初めてプロジェクトを行う人と信頼関係を築こうと思うならば、ごくごく小さいアウトプットを繰り返すのが大事です。

例えばあなたがプロジェクトマネージャであり、現在トラブっているプロジェクトに入ったのであれば、まず「いつ」までに「なに」をするかをクライアントに説明し、それを確実に達成しなければなりません。それを積み重ねると相互の信頼関係が生まれてきます。それはあたかも信頼貯金のように徐々に蓄積されていきます。

逆に言ったことをやらないような信頼を損なう行為を重ねるとあっという間に貯金がなくなってしまうので注意してください。なお、この時の「失敗」というのはあなたの誠実な対応でカバーし、逆に信頼を重ねる結果につながる可能性もありますので慎重な対応が望まれます。

いずれにしても人と人との信頼というのは一朝一夕に築かれるものではなく、大きな成功によって一気に稼げるものではありません。日々こつこつと着実に仕事を成し遂げて築き上げていきましょう。

読める仕様書を書こう

なぜかこんな幻想があります。

ドキュメントは正確無比で、全てが網羅されていなければならない

はい、残念!そんなドキュメント無理ですから!

その結果として、ECサイトのショッピングカートへの商品追加処理といった機能のドキュメントが次のようになります。

ユーザが該当商品において「ショッピングカートへ追加する」ボタンをクリックした場合、該当商品をユーザのショッピンカートデータに追加する。その際、商品マスタより該当商品のデータを取得し、現在在庫数から注文希望商品数が引き当て可能であるか判定する。もし現在在庫数が注文希望商品数を下回っていた場合、商品詳細画面へリダイレクト処理を行い、「在庫がありません」というエラーメッセージを赤文字で表示する。注文希望商品数が現在在庫数を下回っていた、または同一であった場合は…

はっきり言って人には読めない文章ができあがります。こんなの読んで理解できるとすれば、それは人間じゃないんじゃないかと思うほどです。書いても読まれない、十分に理解が進まない文書は絶対に書いてはいけません。はっきり言ってムダです。

しかも上記の内容には不備があります。

  • ボタンのラベルがショッピングカートへ追加するではなくなった場合
  • ユーザの定義。未ログインやまだ購入したことのない利用者の場合ユーザと定義していいのか
  • ショッピングカートにある注文情報を考慮していないので在庫引き当て判定が問題あり
  • 在庫がありません、でいいのか
  • 一覧ページから注文できる仕組みにした場合、エラーのリダイレクトが商品詳細画面でいいのか

などなど。細かく書けば書くほど、不備が目立ったり、ドキュメントがバグの温床になる可能性が高くなります。

それを防ぐためには人が読んで十分理解できるレベルであるのが大事です。例えば以下のような感じでしょうか。

お客さんが商品をショッピンカートに追加できるようにします。在庫が足りなかったらエラーを出してください。

後の足りない部分についてはプロダクトマスターに確認して詰めれば良いでしょう。まず読めて、何がしたいのかを把握できる内容であることを優先すべきです。

なおこれはアジャイルな場合なので、オフショアの場合は異なるので注意が必要ですよ。

すぐにでも生産性をあげる方法

もしあなたたちのプロジェクトで、なかなか生産性が上がらずに困っているとしたら、次のことを試してみると良いでしょう。

生産性向上に貢献しない作業を一切止める

これだけです。ね、簡単でしょ?

ムダな報告書を書くのを止める。ムダな会議を止める。ムダに多く流れているメールを絞る。9割9分役に立たないメーリングリストから外れる。証拠と称して単に投げっぱなしになっていたメールを止める。手作業で毎度繰り返している作業をスクリプト化する…などなど。

あとインターネット。これはムダに大きく貢献するので注意が必要。例えば午後1時から4時までは集中タイムとしてネットワークを停止したりすると、意外と集中して作業に打ち込めたりするものです。

定性的進捗報告はやめよう

プロジェクト管理においてタスク管理は最も重要な要素だと思っています。それだけに適切に管理、運用されなければなりません。

しかし重要視するあまり、細かい入力を求めたりするのは更新コストを増やし、手間がかかるだけで却って運用されなくなります。そこで一つ良い方法があります。

ステータスは多くても「未着手」「着手中」「確認待ち」「終了」の4つにしましょう。

良くあるのが20%やら60%といった数字の進捗です。一見分かりやすいように見えて、実は全く意味不明です。何をもって70%と言っているのか、それが60%とどう違うのか全然分かりません。大抵数字で言う場合に限って、最初こそ勢いよく60%くらいまで進むものの、その後はなかなか終わらず、でも進んでいない訳でもないから70、80、85、90…などと細かくなっていったりします。

しかしアジャイル的に考えるならば、0%も95%も顧客に価値を提供していないという点において同一です。なので、やったか、やっていないかで管理されるくらいで十分なのです。

もしそれでも数値で表したい場合は、タスクをさらに小タスクに分けましょう。例えば1つのタスクに紐づく5タスクを切った場合、一つの子タスクが終わるたびに20%ずつ増えていく計算になります。このように感覚に基づく定性的進捗(なのになぜか数値で出す)ではなく、定量的進捗に努めるようにしましょう。

ユーザストーリーの問題点

アジャイル開発において度々出てくるのが「ユーザストーリー」です。いわゆるフィーチャーベースで要望を書き、複数のユーザストーリーをイテレーションの中でこなすというものです。

ユーザストーリーはUMLでいうユースケースに近いもので、「誰」が「どう」する。それは「なぜ」かを基本として記述します。例えば

顧客は商品を購入する。それは顧客が商品を欲しいからだ。

みたいな感じです(実際にはもっと砕いた感じですが)。

で、個人的にはユーザストーリーは殆ど使わないのですが、その問題点として

網羅性に欠ける

可能性が高いというのがあります。顧客であるプロダクトマスターが全ての要望を把握していれば良いのですが、実際にはそのようなことはありません。優先度が高いのに忘れてしまう要望だってあります。例えば

ショッピングカートの商品を削除したり、数量を変更する機能

を忘れてしまうかも知れません。重要な機能だから覚えているはず、という前提に立っているのがユーザストーリーです(またはいつかのイテレーションでは思い出すはずと)。でも実際には本当の最後の最後まで忘れていて、突然思い出したなんてことはざらです。

そのため基本設計くらいのドキュメントは必要であると考えています。現段階で分かっている機能をリストアップしておけば(実装順番は別として)、システムとして実装しておくべき機能が把握できます。一覧で見れば、より漏れがないかを確認しやすくなります。

基本設計くらいの浅いドキュメントであれば、優先度の変化に応じた修正もそれほどの手間ではありません。ドキュメントはとにかく作り込みすぎないこと、これが大事です。

システム開発会社とアジャイルの微妙な関係

アジャイルソフトウェア開発の原則の一つに次のようなものがあります。

最も重要なことは顧客を満足させること。早く、そして継続的に、価値のあるソフトウェアをリリースする。

アジャイル開発において顧客に価値を届けるのを最重要視しています。個人的にはこの価値というのはソフトウェア開発によってなされるものでなくとも良いと考えています。極論で言えば開発ゼロで価値が届けられるならそれがベストであると考えています。

しかしシステム開発会社にとって開発しないというのは自分たちの存在意義すら失いかねない問題になります。さらに言えば開発しなければ売り上げにつながりません。なので顧客が望む機能をさらに膨らまし、開発工数を増やすことがシステム開発会社にとっての肝にすらなります。それは顧客にとっての価値と呼べるでしょうか。

そのため私見としてはプロジェクト管理と実際の開発会社とは切り離して考えるべきと思っています。開発会社の中のプロジェクトマネージャーが幾らアジャイルを習得していようとも、会社の論理に押されて顧客にとっても価値よりも会社の売り上げを優先するケースは十分に考えられます。

とは言えアジャイルにおいては信頼を大事に考えていますので、会社の論理を優先するような所は信頼関係の構築において必ず破綻する日がくると思いますので、中長期的に考えれば顧客にとっての価値を優先するのが最良になるはずです。

精度の高い見積もりを行うためのたった一つの秘策

これは確かJoel on Softwareで紹介されていた方法だったと思うのですが、個人的にずっと実践しているものです。

一つのタスクは最大16時間を限度とする

これだけです。もし16時間以上かかりそうなら、タスクを分割します。このルールを守るだけで見積もりの精度は間違いなく向上します。

なぜかというと、人は今日明日くらいの予定であれば概ね把握しています。明後日になると途端に読めない部分が出てきます(突然ミーティングが入ったり、体調不良になったりなど)。なので1日の労働時間8時間×2日分の16時間は絶対に越えてはいけないのです。

逆に16時間以内で見積もれる範囲にまで作業を細分化すると、概ね自分の経験則から作業量が読めるようになり、予定時間数も分かってきます。これまで何となく“2日分”だった工数が実は15時間分だったのか、はたまた20時間分だったのかも分かるようになります。もし20時間分だったとしたら、元々残業時間まで含んで考えている訳で、見積もりとして大きな問題がありますね。

Joel on Software

Joel on Software

More Joel on Software

More Joel on Software

根拠のない見積もりはなぜ生まれるのか?

例えば「ECサイトに新しい決済機能を追加したい」という要望に対して見積もるとしたらどう回答するでしょう? もちろんこれだけの漠然とした条件では分かりませんが、例えば「3週間あれば」と回答したとしましょう。そこで疑問になるのはなぜ「3週間」なのかということです。2週間と3日間でも、3週間と4日間でもありません。なぜ3週間という数字が出てきたかが問題です。

通常、そこにはこれまでの経験則から導きだされる予想数値が入ります。しかしシステム開発というのは大抵はこれまでにないものを作ることが多いので、経験則だけではカバーしきれません。そこで使われるのが“直感”です。

個人的に直感はおおむね正しいと考えています。しかし直感は定性的なものであり、定量的な測定に対して用いるべきではありません。つまり「できそう」か「できなさそう」かの判断に直感は必要だと思いますが、3週間という数字に対して用いると誤差が大きくなります。

そしてもしお客さんから「なぜ3週間なのか」という疑問が寄せられたらどう答えれば良いでしょう。まさか「直感です」とは答えづらいと思います。対お客さんに対して「直感」という言葉を使うと、それは「適当」という言葉にすり替わるからです。そこで何となくそれっぽい理由を並べてしまったりします。つまり3週間という数字ありきで、後は理由をつけて外堀を埋めていく訳です。こんなやり方をしていたら、それは失敗するのももっともと言えるでしょう。

大事なのは根拠が出せるところまで細分化していくことです。「新しい決済機能を追加する」のに必要な画面修正、データベースの構造変更、テスト、ロジックの変更などを機能単位で書き出していきます。そうすれば経験則でもはかりやすいレベルまで小さくできます。後はそれぞれを足し合わせていけば精度の高い見積もりになるはずです。

人はこれまでにない事由に相対すると、相対的に大きく見積もりがちです。逆に既にある程度把握しているものだと楽観視して低く見積もってしまいます。どちらも正確さという意味においては全くダメです。

根拠がないのであれば、根拠が出せる所まで(自分が胸を張って説明できるレベルまで)細分化しましょう。

プロジェクト管理とは何か?そのたった一つの解答

“プロジェクト管理”とは何か?と質問されたとすれば答えはたった一つしかありません。

プロジェクト管理はプロジェクトを滞りなく遂行するための活動

です。それ以外の何ものでもありません。

何のためにプロジェクト管理を行うかという疑問に対する答えも同じです。別にあなたの上司を納得させようとしている訳でもないですし、お金を払ってくれている依頼主が気持ちよくなるためのものでもありません。それはプロジェクトが滞りなく運行されている中で感じるものであって、プロジェクト管理がその役割を担っている訳ではありません。

つまりプロジェクト管理とはプロジェクトが円滑に進められるために必要な要素を網羅していれば良いのであって「これとこれは必須」というものではないのです。プロジェクトの規模、開発スタイル、ステークホルダーのスキルなど様々な要素によって最適な選択肢があって然るべきものです。むしろ過去の成功体験に捕われて同じ道具やスタイルを突き通そうとする方が問題です。

このブログではプロジェクト管理のあり方、考え方についてMOONGIFTのこれまでの経験をベースに書き綴っていきます。ご質問などありましたらぜひぜひコメントにお寄せください。