プロジェクトの不確実性を下げるたった3つのコツ
この記事は株式会社ココナラ Advent Calendar 2024 9日目の記事です。
こんにちは。世界から法律に関わる悩みをなくしたい高崎です。普段はココナラ法律相談という、弁護士の先生方と相談者のマッチングサービスをつくっています。
今年も大小さまざまなプロジェクトに関わってきましたが、その中でもこのチームや人は仕事の進め方がうまいな〜とか、なぜかスムーズに仕事が進むな〜と感心することが多くありました。
そういった人たちを観察して分かった共通点はプロジェクトの不確実性を下げるのがうまい、ということです。その中でこれは再現性高く汎用的に使えそう、と感じたポイントを3つまとめてみました。
そもそもプロジェクトにおける不確実性とはなんだろう？
タイトルにもある不確実性とはそもそもなんでしょうか？元々は経済学の分野などで使われる言葉ですが、とりわけソフトウェアエンジニアリングの世界では、プロジェクトの計画、設計、開発、運用において、予測や決定が困難な要因や状況を指します。
例えば以下のような状態は不確実性が高いと言えるでしょう。
- 要件が不明瞭で、クライアントやユーザーが何を必要としているか明確でない
- 新しい技術やツールを採用する際、それが期待通りに動作するかどうかわからない
- 作業時間や予算の正確な見積もりが困難
- チームメンバーの能力や経験がプロジェクトの要求に十分対応できるか不明
より身近に個人のタスクレベルで考えてみると、自分が予定通りに開発を終える自信が相対的に少ないタスクが不確実性の高いタスクと言えます。
書籍「エンジニアリング組織論への招待 ~不確実性に向き合う思考と組織のリファクタリング」では、こういった「不確実性」を下げ、「具体性・明確さ」をいかに効率よく高めていけるかが、エンジニアリングという行為であると説いています。
一般的に不確実性は、プロジェクトの進行とともに下がっていきます。そのような、時間と不確実性の関係を示した図が不確実性のコーンです。プロジェクトの前半は終了時期に大きなバラツキがありますが、それが時間経過に従って、減っていっていることが見て取れます。
出典：『アジャイルな見積りと計画づくり ~価値あるソフトウェアを育てる概念と技法~』(マイク・コーン著, 2009, p.27)
言い換えるとプロジェクト開始時の不確実性が高い状態から、いかに効率良く後半の不確実性が低い状態に持っていけるかが、エンジニアにとって腕の見せ所と言えますね💪
プロジェクトの不確実性を下げる3つのコツ
それでは上記で説明した不確実性を下げるコツを見ていきましょう。
1. 不確実性が高いものからやる
最初のコツはシンプルに、不確実性が高いものからやる ということです。
例えば、普段からよく触っている技術やリポジトリを触るタスクと、全く未経験の言語や初めて触る環境が絡むタスクの場合、後者の方が不確実性が高いことは明らかです。もし、それらタスクの着手順番がコントロールできる場合、できるだけ後者から着手するようにします。
なぜなら不確実性が高いタスクは、完了時期が読みづらいからです。そういうタスクは、そもそも正確に見積もるための情報が不足しているので、まず着手し行動することで、見積もりの精度を上げる必要があります。その結果、想定よりも早く終わる可能性もありますし、逆にもっと時間がかかると判明する可能性もあります。
早く終わる分には問題ないですが、予定より時間がかかることがプロジェクト終盤で発覚した場合、とれる対策がほぼなくなります（俗に言う炎上が確定した状態🔥）
逆に序盤でこのタスクに着手していた場合、もし想定以上に工数がかかることが分かった場合でも、プロジェクト全体の時間でみると余裕がある段階なので、さまざまなリカバリー策を講じる余地が生まれます。
不確実性が高いタスクを序盤で片付けることが出来れば、後半は見積もりが比較的正確なタスクが残るので、プロジェクト全体として成功率を高めることができるでしょう。
ポイント
プロジェクトが始まるとき、タスク一覧を見てこの中で不確実性が高いのはどれだろう？と考えてみましょう。その上で不確実性が高そうなタスクがある場合は「こっちから先にやらせて欲しい」と提案してみましょう。
もちろん、それぞれのタスクに依存関係がある場合やその順番自体にビジネス上大きな意味を持つ場合など、不確実性を基準に順番を変えるという選択肢がいつも取れるとは限りません。しかしそういった制約がない場合は、経験上比較的容易に調整可能だと思います。
2. リリースを分ける
次のコツは、リリースを分けるです。
元々作りたい機能が複数あった場合、本当にすべてが揃っていないと、機能として成立しないのか？検証したいことが分からないのか？を考えましょう。もし一部の機能だけでも成立するのであればそれを最初のバージョンとしてリリースし、まずユーザーからのフィードバックを得るという選択肢をとれます。
特に新規事業のプロダクト立ち上げの際にはよくあるケースですが、さまざまな機能を盛り込んでしまい、結果的に不確実性が高まり開発コストが増し、ファーストリリースが遅れてしまうことはよくあります。（特に機能が充実した他社のキラキラした先行プロダクトがある場合など、どうしてもその存在を無視できません🥲）
また、これはよくあるジレンマですが、特に経験のあるエンジニアほど技術的負債 という言葉に敏感なこともあり、本来の目的以外のタスクを見出し、結果的にリリースが遅れてしまうという場合もあります。
そうした焦りをグッと堪えて、まず自分たちはこの施策やリリース、プロダクトを通してどんな仮説を検証したいのか、何をユーザーや市場に問いたいのかを定義する必要があります。 その目的が達成されるのであれば、それ以外のタスクは本来はやらなくても良かったことかもしれません。
ポイント
本来の目的に照らし合わせ、もし一部の機能のみでもその目的が達成できるのなら、スコープを調整しその分早くリリースすることを提案してみましょう。結果的にビジネスメリットもありながら、段階的にリリースすることで、そのリリースにおける不確実性を下げることができます。
3. 仕様を変える
最後は仕様を変えるです。そもそものプロダクトの仕様（場合によっては要望・要件）から変えるという、前述のコツよりも積極的な行動です。
例えば何らかの機能のリプレイスをするケースを考えてみます。A, B, Cという機能が存在し、それらを別のアプリケーションに移行する必要がある場合、Bを移行対象から省けば、その分の不確実性を取り除けます。
もちろん、ただ単に不確実性を下げたいから、という理由で移行対象から外すことはできないので、それが移行不要であることを説明する必要があります。そのためには、実際にユーザーや社内の詳しい人に話を聞いてユースケースを理解したり、GA4やログなどで利用状況を確認したりする必要があり、ステークホルダーとの合意形成などそれなりの労力がかかります。
ただ、それらの労力は自分の経験上「機能移行に伴う調査、実装、テスト、リリースのコストの総量」と比較した場合、確実に少ないです。
これは過去に管理画面のリプレイスをした経験からなのですが、それなりに歴史があるサービスの場合、実際の業務とシステムの実態に乖離があることが多いです。
なので、そもそもが最適とは言えないものをリプレイスしたとしても費用対効果が悪く、苦労した割にユーザーの満足度が上がらない場合もあります。
そこで当初の要望から一歩踏み込んで、本当にこれをやるべきなのかを費用対効果と不確実性の観点からエンジニアが判断し、提案することでやるべきタスクを減らすことを検討してみましょう。
また、ここでは例として「機能を減らす」というケースを示しましたが、それ以外にも
- 公開範囲を絞る
- 実装方法を代替する（例えばAPI連携ではなく、CSVなどを使った半自動連携に簡略化するなど）
などさまざまなパターンが考えられます。
「公開範囲を絞る」という方法は以下の記事に詳しく書かれています。
これはエンジニアの仕事なのか？と問われれば会社やチームによって違うでしょうし、もしかしたら一般的ではないかもしれません。ただ、不確実性を下げるという観点においてこの方法は非常に効果的であり、そういう意味ではエンジニアリングの一部とも言えます。
またプロダクトマネージャーなどの非エンジニアは、内部の実装には詳しくない場合もあり、不確実性や開発コストを正しく判断できない場合も多いです。よってプロダクト内部の事情を踏まえた状況判断はエンジニアだからこそ発揮できる価値でもあります。
ポイント
「たった数週間のプログラミングで、計画に割く時間を何時間も節約できる」という言葉があります。プログラミングは楽しい作業なのですぐに作業に取り掛かりたくなりますが、まず自分たちがプロジェクトを通して得たいものを見定めて、仕様で削れる部分はないか？もしくはより不確実性の低い代替手段はないか？を検討してみましょう。
それをフィードバックしてよりよい計画を立てるのに協力するのも、エンジニアの責任であると考えます。
もっと自由な開発のために
ツラツラと書いてきましたが、要点をまとめると以下になります。
- 「不確実性」を下げ、「具体性・明確さ」を効率よく高めていくことがソフトウェアエンジニアリングにおいて重要
- 「不確実性」を下げるために、エンジニアが取れる手段はコードを書く以外にも色々ある
- その具体例が今回の記事で書いたような「計画づくり」にエンジニアがコミットすることである
自分の根底にはもっと楽しく自由に開発をしたい、という想いがあります。そのために仕事の不確実性を下げることが重要であると思っており、施策の優先度や仕様、スコープなどの計画づくりにおいてもPdMや企画者任せにせず、エンジニアの視点から貢献したいと思っています。
エンジニアはビジネス部門の指示を受けて、ただモノをつくるだけの存在ではありません。プロジェクトのさまざまな側面から価値提供ができます。結果的にそれが自分やチームだけでなく、ビジネスにおいてもいい影響を与えられると信じています。
今回はそのヒントになりそうなコツを、自分の経験や同僚の振る舞いをもとにまとめてみました。なにか参考になれば幸いです。
明日は@mintak21さんによる これができればGithubActions上級者だ！ です。
ココナラでは積極的にエンジニアを採用しています。
採用情報はこちら。
カジュアル面談希望の方はこちら。
Discussion