はじめに
自己紹介
こんにちは。 アソビュー株式会社にてプロジェクトマネージャーをやっております杉浦と申します。
これまでに携わったプロジェクト
私はこれまで１０年以上に渡り在庫管理システムや生産管理システム開発のプロジェクトマネージャーをやらせていただいてきました。現在アソビューでは新たな領域におけるプロダクト開発に挑戦しており毎日四苦八苦しながらも来たるべきローンチに向け邁進しております！
プロジェクトマネジメントについて
今日はこれまでの私の経験から新規プロダクト開発におけるプロジェクトマネジメントの難しさや課題について共有させていただけたらと思います。
プロジェクトマネジメント
プロジェクトマネージャーの仕事
プロジェクトマネジメントにおけるタスクについてはその開発規模やプロダクトの性質により変わりますがITシステムの開発については概ね下記のようなものがあります。
| タスク | 内容 |
|---|---|
| 交渉 | 業務担当者や経営者等のステークホルダと交渉します。具体的には納期やスコープの調整、予算調整等がありますがプロジェクトも終盤になると"機能を削らせてほしい"、"納期を遅らせてほしい"、"予算を増やしてほしい"等発注者側からするとネガティブなお願いをすることが多く最も忍耐が必要なタスクの１つです。 |
| 調整 | ユーザー部門やその他関連部門とプロダクトリリースの順番やそれに合わせた運用スケジュール諸々の調整を行います。外部リソースの調達や協力会社への業務依頼なども含みます。 |
| 計画 | プロジェクト全体のマイルストーン～開発フェーズ毎の詳細なスケジュール管理までステークホルダや開発フェーズにより必要に応じた異なる粒度の計画を見積や事業計画等を前提に作成します。 |
| 見積 | 見積の方法にはファンクションポイント法や積上、トップダウン、三点見積・・・等古来から様々な見積方法がありますが大変難しくプロジェクト失敗の要因として最も多いのがこの見積です。どのようにやっても概ね３割程度の誤差が出るので今後はAI等を活用するのがいいように思いますし誤差の範囲としてはそれほど大差ないのではないかとすら思います。 |
| コスト管理 | 開発人員リソース、インフラの運用コスト、開発・検証等用のハードウェアやデバイス等が主なコストになりますがITシステム開発のコストは開発人員リソースが大部分を占めるためプロジェクトが炎上すればするほど致命的なコスト増につながります。 |
| リスクヘッジ | 個人的にプロジェクトマネジメントにおいて最も重要タスクと思っています。納期、品質、特許等リスクは多岐にわたりますがプロジェクト開始時点からどの程度リスクを拾えるかがプロジェクト成功のカギになりますので可能な限りリスクを洗い出し先手先手を常に打ち続けることが重要です。 |
| 要件定義 | アプリケーションが何をするのかを定義していきます。粒度は様々ありますがこれといって定められた表記法も無くあいまいになりがちです。システム開発の肝となるタスクで完成したプロダクトが使えないのは要件定義がポンコツだからと言っても過言じゃありません。個人的には要件定義は質より量、書き方より漏れが無いだったりあいまいじゃないといったところに価値を置いています |
| 上記以外 | 上記以外にもテスト計画、セキュリティ、リリース計画、保守計画、特許・法務等色々あったりします。 |
理想 vs 現実
ITプロダクト開発についてはこの２０年間くらいの間に様々な開発技法やプロジェクト運用方法等が生み出されてきました。どれも素晴らしい技術なのですがなぜか十分に活かしきれないケースが多いように思います。ここではいくつか掻い摘んでその原因や私なりの解決法を説明したいと思います。
1. アジャイル開発は難しい
一般的にアジャイル開発は素晴らしく一早くウォーターフォール開発を脱却しアジャイル開発に移行すれば開発者は皆救われる！！と思われていますが実施にやると何故かうまくいかないというかなかなかアジャイルにならなかったりします。その原因を少し考えてみました！
- 長期間リリースできないので実質ウォーターフォール開発だ！
上記の絵はMVP開発でよく使用される資料なのですが簡単に言うと
小さなプロダクトを少しずつ作って都度顧客からフィードバックをもらいながら作るから最終的に出来上がるプロダクトは（この絵の場合車！）は顧客の要望からズレてないはずだ！
を説明していますが実際にやろうとするとなかなかうまくいかないことが多いです。良くあるのが上の絵でいうところのスケボーの開発に３カ月くらい必要だったりします。モックを使ったりすれば早いのですがそれだったら正直figmaのシミュレータを使用した方がよっぽど早くフィードバックを得られます。
- ある程度機能が結合してないと興味を持ってもらえない
モック等を使用してある程度のフィードバックは得られます。ただ、プロダクトの本質的な課題に関する指摘等はある程度の機能が実装されていないと得られません。例えば
QRコード出荷指示書を発行しハンディターミナルでQRコードをスキャンするとダッシュボードに出荷実績が追加される
といった要件がある場合、出荷指示書のモックを作成し提供すると出力項目の内容やその表示位置に対してフィードバックは得られやすいです。
但し上記のようにQRコードが並んでいた場合、実際にスキャナを使用すると頻繁に誤スキャンが発生したりします。これはスキャナがカメラでスキャン範囲のQRコードを認識しているため、QRコードはある程度コード間の距離を置いて表示するか少しずらして表示する必要があったりします。こういったことは実際にスキャンしてみないと分からなかったりします。しかしながらこういった実際でのアプリケーションの挙動が現場では最も重要だったりするものです。
- 誰が仕様を決めるのか？
アジャイル開発はスクラム開発やXP、リーン開発等の総称ですがXPでいうところのオンサイト顧客、スクラムでいうところのプロダクトオーナーがプロダクトの要件については責務負うとされています。しかしながら実際はプロダクトオーナーをプロジェクトマネージャーが兼務している場合が多く、マネジメント業務に忙殺されるようなことがあると仕様が策定できずスプリントが回らなくなります。個人的にはプロジェクトマネージャーとプロダクトオーナーとは兼務すべきでないと思っています。顧客の要求を分析しこれを要件や設計モデルに落とすアジャイルサムライ で言うところのドメインマスターなる役割を専門的に担うメンバーがスクラムには必要と感じています。
- どうやって仕様を決めるのか？
ひと昔前まではユーザーからシステム要求を聞き出しそれをエクセルシートにまとめシステム要件としていました。この手法にはいくつか欠点があり、その一つが限られた少人数によってシステム要件が確定するためシステム要求に対して抜けや漏れが発生しやすいということでした。そこで登場したのがユーザーストーリーマッピングです。内容は割愛しますがユーザーストーリーマッピングを実施すると複数の意見を得られるため抜けや漏れを防ぎやすくなります。ユーザーストーリーマッピングの運用で注意したいのは、ユーザーストーリーマッピングを開発メンバーだけで行ってしまうことです。ユーザーストーリーマッピングのメンバーにはユーザー部門から開発領域となるドメインに関して深い見識を持つメンバーが不可欠です。例えば、勤怠管理システムを作る場合等はバックオフィス系の機能を除けば比較的うまくとは思います。それは勤怠管理が私たちにとって身近でありシステム要求を抽出すことが比較的容易だからです。ところがこれが生産管理システム等の一般的には馴染みの薄い業務ドメインに深く関わるシステムとなると話が変わってきます。生産管理に関するナレッジがメンバー間に無い場合、生産管理に使用する作業指示書であったり部品表といった主要なモデルを抽出できないため要求分析の段階で手詰まりとなる可能性が高いです。
- じゃあ結局どうする！？
アジャイル開発については色々課題はありますが、システム要求の変化の速さが著しい現代においてウォーターフォール開発を続けていくことはリスクが高いように思います。そこで私は下記のようななんちゃってアジャイル的な手法でプロジェクトを進めることが多いように思います。こうすると完ぺきではないにしろまぁまぁなところには着地できたりします！
- なんちゃってアジャイル
- 最初はスケボーじゃなくてギリ走れるくらいの車を作る。走れるようになったらユーザーに見てもらう
- 車ができるまではmockの代わりにfigma等のツールを使ってフィードバックを得る。figmaと同じくらい高速に実装できるならmockでもＯＫ
- ふんわりとした要件書を作ってこれをスプリントの入力とする。細かい仕様はユーザーのフィードバックを得ながら練り上げる
- 詳細な仕様などは時間をかけても良いので開発者に口伝で伝える。実装と要件書の乖離を認め場合によっては実装を正とし要件書の方を寄せておく
- ユーザーストーリーマッピングには必ず本物のユーザーを含める
- 納期は可能な限りぼんやりさせておく。ユーザーには開発状況によるスコープ調整の可能性を匂わせておく
2. タスク管理は難しい タスク管理はプロジェクト管理において最も重要なタスクの一つです。タスクを積み上げた結果で見積を行ったりリードタイム計算しスケジュールを定めたりします。また管理者は逐次計画に沿ったタスクを開発者に投入し開発者が目の前のタスクに集中すれば、何れゴールにたどり着ける環境を作ることが重要です。
- 何年やっても見積は当たらない
見積もりが何故ずれるかという説明の1つに不確実性コーンというものがあります。ざっくり説明するとプロジェクトの初期段階では不確定要素が多いので見積もりには4倍くらいの誤差があり、プロジェクトの進行とともに不確実な部分が少なくなってきて誤差は収束に向かうという話です。但しこれを高らかに宣言したところで受けれてもらえないユーザーがほとんどかと思います。
特にSierの場合要求の完了の段階で概算見積という名の正式見積を発行し、これが修正されることは非常に稀です。実際には下記の図でハイライトした部分の誤差のみが認めてもらえます。下振れは許されても上振れはゆるされないことが多いのです！回避方法としてはフェーズ毎に契約を細かく分けるなどがありますが実際はこれに応じてくれる顧客はあまり多くはありません。
- 結局納期が1番大切！
納期と品質をトレードオフするなら絶対に品質だと思います。しかし多くの場合品質を犠牲にしてでも納期を守ることを余儀なくされます。プロジェクトの成否を予算や利益で測るのならば予定の期日までに先に宣言した品質で納品できたプロジェクトが成功ということになります。ただ予定の期日に完了を合わせるのは実際には大変難しくその理由は様々ですが結局そのためには品質を妥協したりスコープを調整して機能を落としたりします。個人的には契約の時点で未来を予見し納品の期日をピタリと当てたりすることにどれほどの価値があるのか疑問です。期日通りにアプリケーションを使い始めるとどれだけ便益に寄与するのかがいまいち理解できません。
- ストーリーポイントの罠
上記はバーンダウンチャートと言って、現在のタスクの総量や1日あたりのベロシティ（生産能力）をストーリーポイントという基準値をもって評価し、タスクの完了までにかかる日数を計算するチャートです。実はこのストーリーポイントには注意が必要です。例えばタスクの総量が500spでベロシティが50spだったとします。必要日数は10日になるはずですが実際はそうはいきません。現在のアプリケーションエンジニアリングは最低でもフロントエンドとバックンドで分業となる場合が多いです。タスク総量500spの内、全てがバックエンドのタスクでバンクエンドのベロシティが25spだったと仮定した場合、10日ではなく20日が必要なリードタイムになります。そのためストーリーポイントやベロシティもバックエンドとフロントエンド、もしくは開発領域が属人的になればなるほど細分化しないと正確な製造リードタイムは分かりません。実際には開発者は1日中開発をしているわけではなく、打合せに参加していたり新しいアーキテクチャやテクノロジーについてのキャッチアップに時間を割いていたりします。そのような間接的な作業時間も含め可動率を考慮しリードタイム計算したうえでスケジュールを管理する必要があります。あとタスク間の依存関係やクリティカルパスも重要でベロシティが足りていてもタスクの依存関係の問題で次のタスクに仕掛かれない状況も発生します。スケジュール管理者は開発者の手待ちが発生しないように常に100%可動できる状況を作る必要があります。
- じゃあ結局どうする！？
結局のところ開発スケジュールを完全にコントロールすることは私にとって極めて難しいのであきらめます。その代わり嘘偽りなくこれを顧客と共有しプロジェクトが最良の結果をもたらせるように不断の努力を継続することが大切です。プロジェクトの目的の納期に間に合わせることではなくどれだけ有益なプロダクトを提供できるかだと思っているからです。
- 私が心がけているタスク管理はこれ！
- クリティカルパスを考慮した本当の納期を把握する
- 契約内容等にとらわれず真実の納期を顧客に偽りなく報告する
- 可能な限りリスクを可視化し工数を積む
- 将来の負債を今現実としてとらえる
- 機能に優先順位をつけスコープ調整含めギリギリまで顧客と調整し続ける
- 最重要はプロダクトの価値！
余談ですが先日車を購入したんですが注文してから納車までに半年かかりました。最初に概ねの納車時期を確認しその後納車日の近くになるとディーラーから納車できる旨の連絡が来ました。納車を待つのは私だけでなく世の中みんなそうなので特に腹も立ちませんでしたし問題とも思いませんでした。システム開発もこれくらいおおらかだと皆んな幸せになるように思います。
おわりに
今回は私が普段行っているプロジェクトマネジメントについて少しでも知ってもらえたらと思い書かせていただきました。書いていて思ったのですが自分はまだプロジェクトマネージャーとして未熟な点が多々あり最近それがやっとわかってきたということです。これまでプロジェクトマネジメントについてエンジニアの経験によるなりゆきでやってきた部分が多く技術的に向き合ってこなかったと反省しています。実はプロジェクトマネジメントにも色々スキルや技法があるのですが実際には活用されていなかったり学ぶ機会も限られていたりします。今後はこういった技術を積極的にキャッチアップし今開発中のプロダクトが少しでも誰かにとって有益なものになるよう日々精進していきたいと思います。
