(続き)初めてプロジェクト開発に取り組んで1年掛かった話

こんにちは、リアズエンジニアチームの和田です。
前回の続きのお話です。


何故炎上したかという部分は前回も触れましたが、見積もりと計画作りが甘かったという部分に尽きます。ですが、初体験・社内未踏の部分も多くあるのではじめに最後までを見通すのは困難を極めます。
そして市場情勢も変わりますし要求も変わってきます。開発者も知見をアップデートすることもありますし、ある程度の規模のプロジェクトであれば大なり小なり計画がズレるということが避けられないのではないでしょうか。

 

ではどうやってプロジェクトを立て直したか、まずは現実を見つめ直します。
日々状況は変わる不確実性というものが存在することを無視しないようにしました。これはプロジェクト開発にかぎらず世の中全ての事象で言えることですね。

現実逃避…しない!

現実逃避…しない!

 


再見積もりを行いました

相対的なポイントで見積もっていましたが、当初の見積もりでは機能について理解があいまいで必要なタスクの想定が足りていませんでした。また、ポイントの基準・相場というのが少しズレてきていましたので、残りの機能について全て再見積もりを行いました。

 

この機能は前に作ったものが使えるよね、これはnポイントで見積もったけど今思えばmポイントだよね、これって実はこういう実装も必要だよね、というように改めて見直すと当初より確度の高い見積もりが出来ました。

不確実性コーン 株式会社リアズ

不確実性コーン図

 

本来、見積もりというのは確率であってコミットメントではないはずなのです。上記の不確実性コーンで表されるように、ある程度のブレ幅をもって予測するものになります。これを時間軸が進むにつれてアップデートし、ブレ幅を収束させていく形になります。
が、やはりビジネス視点ではどうしてもコミットとして捉えがちです。いつ完成するか分かりません、というのはありえません。未完で作り続ける象徴サグラダファミリアも2026年に完成予定と発表する時代です。

サグラダ・ファミリア

未完成の象徴?サグラダファミリア

 

いつ終わるのか分からなければ、会社全体の事業計画や事業内のロードマップも立てられません。なので特に工数が大きい画面(複数の機能の集合体)についてはある程度のバッファを設けました。「おおよそ◯月から△月までの間に完了する」から「最低でも◯月までには終わる」になりビジネスとしても一応算段が立てられるようになりました。


QCDSというモデルで考える

プロジェクトを立て直す場合、よく用いられるのがQCD+Sという考え方です。

 

  • Q: Quality(品質)
  • C: Cost(コスト)
  • D: Delivery(期限)
  • S: Scope(範囲)

 

このどれかを死守するとなった場合、どれかがトレードオフになるわけです。もちろん初めは全て守ることを目指しますが、炎上したプロジェクトでは全て死守するというのは困難です。

 

 

品質を下げて時間を稼ぐというのは悪手ではないでしょうか。品質を故意に下げるというのは案外難しく、いい塩梅に手を抜くことを考えるのに時間を使うより、普通に作ったほうが早いという開発者も多そうです。

それに技術的負債を返済するためのプロジェクトで新たに技術的負債を意図的に作るというのは本末転倒になってしまいます。雑に作って時間を稼ぐというのは、稼げているようで稼げていません。プロジェクトのその後の作業も不効率になりますし、のちのちの保守や機能追加の際にもかえって時間が掛かり、トータルでは時間を増大させることになります。

 

コストは有限ですし、予算(人員)追加は簡単に出来ません。それに人員を追加したからと単純に人数の掛け算で進捗が速くなるわけではありません。

 

期限・納期も有限なものです。ここを調整できればそもそも炎上はしないといったところでしょうか。リリースが遅れることは、それによってプロダクト価値が低下する・コスト増大するということにも繋がりかねません。よって期限も基本的に動かせません。

 

QCDのいずれも固定とすると、動かせるのはスコープ(範囲)ということになります。
ある機能を計画から外す、機能の内容を調整することで帳尻を合わせることになります。逆にスコープを広げる・増やす場合は、コストや期限を調整しなければなりません。

実際に幾つかの機能を計画から外して調整しました。(一部はプロジェクト終了後にリリースしました。)


それでも調整がつかない

再見積もりを行い、最新の状態にしました。
スコープを調整し、優先順位が低いものを計画から外しました。
おおよその完成予想スケジュールが出ます。前よりは信頼度が高いものです。これで丸く収まれば本稿も綺麗にまとまって格好良いのですが、どうやらそれでも求められている期限には間に合いそうにありません。

 

どうしたか?

 

実は、プロジェクトが燃え始めの頃にメンバーは1人増やしてもらいました。
そして再見積もりとスコープ調整の結果を基に、期限も伸ばしてもらいました。

 

さきほど変えられないと述べたCostとDeliveryを調整したのです。これについては会社の理解があって出来ることなので、感謝しかありません。甘えてはいけませんが、自社サービス・内製開発は関係者が社内なので調整しやすいのが有り難いところです。

 

メンバーも踏ん張ってくれて、様々な改善を行い効率化を図りました。
プロジェクト開始から数えて実に52回のふりかえり会を行い、たくさんのTryを実行してきました。

 

KPTでのふりかえり会 株式会社リアズ

KPTでのふりかえり会

 

そして運営チームの協力や社内の理解もあって、お陰様で何とか最後のリリースを迎えて完了しました。


得られた教訓

見積もりと計画を定期的に見直す
大きなプロジェクトでは見積もり1回では無理があります。ぶれ幅を収束していくためにもプロジェクトの途中で数回見直す必要があります。見積もりをコミットとして求めると、開発者は苦い経験から防衛的に多く見積もりがちです。そういう意味でも途中での見直しが重要かと思います。

 

優先順位を常に意識する
機能の優先順位が明確であればスコープ調整もつきやすいです。優先順位が無いリストの上から順にリリースすると、必要だった大事な機能が期限に間に合わず落としてしまうことにもなりかねません。

 

危険な兆候があれば早めにアラートを上げる
これは社会人として基本的な行動ではありますが切羽詰まると視野が狭くなり案外難しいものです。早めに早めにチームで話し合ったり、上司に相談することを改めて意識しないといけません。

 

 

リアズ第1期のモダン化プロジェクトは終わりましたが、これらの保守と第2期、第3期のプロジェクトを予定しております。

オレ達はようやくのぼりはじめたばかりだからな

このはてしなく遠いモダン化坂をよ…


We’re hiring!

株式会社リアズでは、ともに坂を登ってくれる仲間を募集しています。
PHP、Java、JavaScriptなどの経験があるエンジニアさん大歓迎です。
関係者が社内にいる内製開発で、一緒にサービスを作り上げていきませんか?ご興味がある方はぜひ!
 
採用に関する情報と応募はコチラから
夕方面談、Skypeでの遠隔面談にも対応しています。お気軽にどうぞ!