プロダクト開発の中で「あれがほしい」「いつまでにほしい」「もっと早くほしい」とリクエストされることは珍しくないでしょう。また一方で、開発側から「これは難しい」「それまでにはできない」「思ったよりも時間がかかる」と伝えないといけない状況も、これまた珍しくはありません。さまざまなツールやフレームワークの力を借り、開発をどれだけ効率化しようとも、不確実性をゼロにすることはできないからです。
つまり、「当初計画していた機能が開発できなかった」「当初計画していた機能とは異なる機能を開発しなければならなくなった」とスコープ調整を決断せなばならない局面もまたゼロにはなりません。 こうした現象は、いわば髪や爪やヤクの背中の毛が伸びるのと同じように仕方なく発生するものですが、いざ発生した際に、「できなかっただと？ふざけるな！」ではなく、「よしわかった。ここから最善策を探っていこう」という反応を得て、前向きにプロジェクトを進めていくためには、なによりも信頼が必要です。
スコープ調整と信頼、というトピックを考えたとき、私はそこに「積み重ね」のような構造をイメージします。まず土台に「信頼を獲得する基本的なアプローチ」があり、その上に「信頼できるプロセスを設計、計画する、”つくれるように決める”アプローチ」がある。そして、積み重ねの最上部に「スコープ調整を前向きに捉えて進めていくためのアプローチ」があると考えます。本稿では、地道に信頼を作り変化に対応する話を、プロセスを特に限定せず書いてみたいと思います。次の図の構成で、下から順に説明しましょう。
図) 本記事の構成。信頼を積み上げることを意識しながら、つくれるように決めてつくり、必要に応じて調整する
- スコープ調整には信頼が必要で、信頼は積み上げるもの
- チームの信頼性を獲得する技術
- つくれるように決める
- 「犬が宿題を食べちゃう」ような不確実性に向き合い、スコープを調整するためには
- もうちょっと具体的なスコープ調整戦略を考えてみる
- まとめ
スコープ調整には信頼が必要で、信頼は積み上げるもの
プロダクト開発の関係者や体制には仕様を受け取ってそのとおりに開発する受託開発、サービスを運用する企業の中の内製部隊、スタートアップで役割分担なく開発に携わるチームなどなど、さまざまな形があります。とはいえ何らかの形で、「あの機能がほしい」と期待する人と、「あの機能」を提供する人は別の人であることがほとんどです。そして、2者の間にはなんらかの形で信頼関係があり、「信頼のありよう」によって、スコープ調整の受け止められ方は変わります。 たとえば
- 過去99回に渡って、期待する人の期待通りのものを提供してきたチーム
- 過去99回に渡って、期待する人の期待を一度も満たせず納期に遅れて不十分なものを提供してきたチーム
この両チームがスコープ調整を提案してきた際、受け止められ方はもちろん同じではないでしょう*1。また一方で、チームの振る舞いの違い、たとえば
- 過去99回に渡って、期待する人の期待通りのものをほぼ半々の割合で提供したり、できなかったりしてきた。100回目は残念ながら達成できないので、頭を丸めてお詫びにいこうかと考えている
- 過去99回に渡って、期待する人の期待通りのものをほぼ半々の割合で提供したり、できなかったりしてきた。しかし、できないときは極力原因と状況を共有し、期待する人の期待と現状とを近づけるよう相談し、できる範囲で最善のものを提供した。100回目は残念ながら達成できないので、原因報告と次善の案を用意している
この両者を比べた際も、やはりスコープ調整の受け止められ方は違うでしょう。前者は、恐らくこれまでと変わらず怒られて謝罪する流れでしょうが、後者はあまり感情的にならず、じゃあどうしようかという相談ができそうです。
信頼は積み重ねによって構築されますが、大事なのは現状認識、現状をどう変えたいのか、そして変えていくためのアプローチです。もしも、いま信頼されていないとしたらそこをスタート地点として、いままでよりも信頼される行動をする、行動をいままでとは変えていくしかありません。
ここからは私の経験を元に、参考になると信じる「信頼を積み重ねるためのアプローチ」を書いていきます。
チームの信頼性を獲得する技術
前述のように、開発するものや体制はさまざまなので、どこでもそのまま使えるような「信頼を獲得する技術」はなかなかありません。ここでは基本的な考え方を示すつもりですが、あわせて「社内のビジネス部門から依頼を受けて開発する技術部門で、1週間～3ヶ月程度のプロジェクトを単位としてして数名から多いと30名くらいのチームで開発する」という内製部隊のケースでのより具体的なアプローチも考えてみます。
【信頼性を獲得する1】小さくつくるを積み重ねる
いきなり邪道っぽいですが、信頼される行動の前に、信頼される行動の回数を増やすことを考えましょう。大きなものを長時間かけて作るよりは、小さなものを短時間で作る方が、期待する人と提供する人の会話ややり取りの回数が増えます。回数が増えれば、その中で信頼される行動をする機会も増えることになります。
これはアジャイルな開発やスクラムの話に限りません。ウォーターフォール型開発でも、大きな機能を複数に分割して一度に開発する機能の数を減らせば、開発期間は短くなり、提供する回数も増えることになります。細かく分割すると効率や生産性が悪くなるように感じるかもしれませんが、多くの場合それは杞憂です。どうしても気になるなら、1週間、2週間、1ヶ月、3ヶ月などいろいろな期間を試してみて、当初の予定通りに進められる確率が高い期間を見つける実験をするとよいです。
また長期の開発プロジェクトで「期待する人に向けたリリース」が1回でも、その中を分割して開発を進められます。半年間を1ヶ月ごとに区切って6フェーズの開発としてプロジェクトを6回実施するイメージです。さらに1回のうちには、ひとつひとつの仕様、設計、テストなどの作業と成果物があります。成果物を細かく区切っていけば、そのための作業量は小さくなり、回数を増やせます。分割されたフェーズの中では作業者と指示者（マネージャーやリーダー）との関係に閉じますが、ここでも信頼を積み重ねる行動の機会はあります。 人間には単純接触効果という認知バイアスがあると言われています。
単純接触効果とは、初めて接したときは好きとも嫌いとも思わなかったような刺激に繰り返し触れることで、好意が少しずつ増していく現象のことを言う（Zajonc, 1968）。これは音楽だけでなく、文字や物、人などさまざまな刺激に対して生じると言われている。
『情報を正しく選択するための認知バイアス事典』
著：情報文化研究所、監修：高橋昌一郎監修、フォレスト出版、2021、Kindle位置2431
頻繁に接するものを、それだけで、好ましく思う傾向があるというものです。たまに会う人よりもしょっちゅう会う人のほうを好む（可能性が高まる）わけです。その点でも、期待する人と提供する人が頻繁に話す機会があるほうが、なんとなく物事が上手くいきやすくなりそうです。
【信頼性を獲得する2】できることをやる
信頼というのは、なんでもかんでも絶対にやれると信じてもらうことではありません。できると言ったことはやってくれる、できないことは先にそう言ってくれる、難しいなら相談したうえでできる範囲を見出してくれると信じられるのが信頼です。期待値が高いことが信頼なのではなく、期待が現実とマッチしているのが信頼です。
寄せられた期待を実現するためには、まずは開発ができる能力が必須です。能力はチーム全体で持っていればいいので、ひとりひとりが何でもできる必要はありません。アーキテクチャが得意な人、コーディングができる人、テストがチョットデキル人、UIデザインの経験がある人、マネジメントが嫌いだけどわかる人のように、それぞれの能力があります。全員の能力の合計がチームの能力だとは単純には言えませんが、必要な能力が一部でも足りなければ「開発できないチーム」となってしまいます。
どういうわけか必要な能力が足りないチームで開発している、というか開発しようとしてできないでいるチームを見ることがあります。チームワークの力を期待していたり、メンバーの成長に投資していたり、単に人手不足だったりと理由はいろいろですが、知らないものは知らない、できないことはできないとはっきりさせるほうが健全です。
できない仕事を無理にやっていると、表面的には動くようになったり、なにかを諦めてリリースにこぎ着けたりと、いったんは進んでいるように見えます。しかし水面下で技術的負債が積み上がったり、品質が悪化していたり、個々人のモチベーションが失われたりして、後々トラブルになる種がまかれたり、トラブルの実がすくすくと成長しがちです。トラブルはだいたい最悪のタイミングで表面化し、信頼を大きく損ないます。
提供する人として、できることとできないこととを、まずは客観的に把握し正直にオープンにしましょう。なにをどこまで期待できるのかはっきりしますし、できる範囲の仕事なら確実に期待通り完成して、信頼を積み上げられます。できる範囲を越えてしまう難しい仕事であれば、「諦めて他の方法を探る」という選択肢が得られますし、予想より時間がかかったり結果が期待通りでなかったりするかもしれないと、事前に認識を合わせることもできます。
チームができないことは、「現時点では」できないというだけです。チーム内に自主的に学習する人がいるなら、時間がたてばできるようになるでしょう。業務時間とお金を使って学習したり研修を受けたりすべき場合もあります。向き不向きによっては、チームメンバーの追加や入れ替えで能力を獲得したほうがいいかもしれません。ですが、まずは「できないという現実」を受け入れないとこういう対策は採れません。
内製部隊の具体的なケースであれば、ビジネス側が実現したいことをヒアリングしながら「できるかどうか」を判断するといいでしょう。内容に応じて必要と思われるスキルを持つメンバーにも徐々にヒアリングに加わってもらいながら、できるかどうかを判断します。判断そのものにもビジネス側の人に参加してもらい、複数のオプションから選んだり代替手段を考えに入れつつ、実現可能な形を固めます。このとき、エンジニアはつい正確を期すつもりで「実現は難しい」「できるかわからない」などの言葉を選びがちですが、「できる」と断言できる場合以外は「できない」と判断を下し、ハッキリ伝えるほうが後のトラブルを予防できます。
【信頼性を獲得する3】リスクを小さくする
提供するものが明確で、単純で、簡単に実現できるものであれば、期待する人の期待通りに提供できる見込みが高まります。逆に不明確で複雑で難しいものはリスクが大きいことになります。そう考えれば話は単純で、提供するもののリスクを小さくしましょう。そうすれば、期待する人の期待通りに提供できる確率が高くなります。
方法は2つあります。ひとつは、やることすべてについてリスクを小さくする方法と、リスクの小さいものを増やすという方法です。
すべてのリスクを小さくするには、開発着手前に仕様を精密に決めたりテストの網羅を高めるなどのプロセス面のアプローチと、技術的にチャレンジングなものを避けるという技術面のアプローチがあります。
ただし、つくるものすべてのリスクを小さくしようとしすぎると、期待する人が本当にほしいものから遠ざかってしまうという、また異なるリスクが増大するので注意が必要です。徹底的にリスクを小さくしようと思えば、手堅く、枯れた、面白味のない手法を用い開発は可能でしょうが、こうしてつくられたものが期待通りの価値を提供できるかは疑問です。リスクがないことは、やる価値もないのです。
もうひとつの、リスクの小さいものを増やすという方法は、つくるものの選び方に関わってきます。初めてのこと、目新しいもの、複雑な機能、曖昧な仕様といったリスクが大きいことばかりやろうとすると、全体としてリスクはもちろん大きくなります。そこにリスクが小さいことも混ぜれば、全体のリスクは比較的小さくなります。たとえば、新しい機能なら簡単な部分を切り出して着手する、初めての技術なら既存機能のつくり直しで試してみる、複雑な機能なら仕様は明確にしておくといった工夫をすると、全体のリスクをコントロールしやすくなります。
以前に試してみたやり方ですが、ほしい機能に規模や工数の見積もりとは別に難易度を記載して、リリース全体のリスクを調整しやすくしました。1回のリリースに難易度が高いものが多すぎると、リリースが遅れる可能性が高くなってしまいます。
図) 機能ごとに規模の見積もりと難易度を別に書く。機能1は時間はかかるが確実に終わる。機能3は早くできるかもしれないが、高難度ゆえすごく時間がかかるかもしれない
実は、前項で示した「小さくつくる」というアプローチも、リスクを小さくすることになります。提供するものの規模が小さければ、全体を見通して計画しやすくなり見落としが減り、予定からの遅れもわかりやすくなります。1週間の作業に1時間の遅れがあっても目立たないかもしれませんが、3時間の作業が1時間遅れたら誰でも気がつき、対策できます。3ヶ月かかるプロジェクトが10％遅れたら6営業日＝1週間以上の遅延ですが、1週間のプロジェクトなら10％遅れは4時間＝半日です。つまり、期待する人への影響をそれだけ小さくできます。
【信頼性を獲得する4】0点を取らない
リリースの予定日に「すみません！何もできてません」と伝えないといけないとしたら、それはだいぶヤバイ状況です。0点といっていいでしょう。なにがヤバイかというと、受け取る側である期待する人にはもはやどうしようもない点です。どうしようもないので、遅れを受け入れるしかないわけですが、受け入れる側の提供する人に対するヘイト値は大幅に上昇します。こうなれば信頼などもはや空の彼方です。
もしリリース日に何もできなさそうなら、できるだけ早めに伝えましょう。もちろん文句を言われたり怒られたりするでしょうが、ギリギリにやるよりはマシです。伝えられた相手の方も、対応する時間と心のゆとりを持てます。もっといいのは、何もできないという可能性を早い段階から伝え続け、リリースの確実性を更新し続けることです。予定通りに受け取れなかったら困るという側の人こそ、遅延の可能性、すなわちリスクに対処する側の人です。リスクを評価し、対応策を準備するための情報は、提供する人から渡すものです。
またリリース日にすべての機能は完成していないが、一部の機能はリリースできるようにするのも有効です。業務であったりデモであったり一般ユーザー向けのフィーチャであったり、一部だけでもあれば意味がある、価値が提供できるような組み合わせが考えられます。それだけでもリリースできれば、0点という評価にはなりません。
仮に、なにもできていないのなら、提供する人が全力を尽くしていても、0点は0点です。「頑張ったんだから評価してくれ」とは1ミリも思ってはダメです！（もちろん、全力を出さずに手を抜いたならマイナス点です。そりゃあなたが悪い！）相手が評価できることをやりましょう。
つくれるように決める
「できることをやる」の項で紹介したように、提供する人が自分たちの能力と「できること」を把握したうえで期待する人から届いている要望が、自分たちのできる範囲なのか、難易度がどのくらいなのかを判断しなければなりません。これからつくるものについて把握していなければ、妥当な計画は作れませんし、結果も「やってみないとわからない」になってしまいます。
なにをするのか、なにをつくるのかを知ったうえで計画すれば、仕事は順調に進む可能性が高まりますし、信頼を高めることにもつながるでしょう。ですから、できる範囲でいいので、なにをつくるか知るための努力をする必要があります。以降は、「なにをつくるか」を知り、また、「どうつくるか」を計画するためのアプローチを書いてみます。
【つくれるように決める1】「なにをつくるか」を計画する、設計する
要望をしっかり受け取る、という作業は、なにをするのか・なにをつくるのかを知る仕事の半分であり、大事な要素です。ヒアリングをしたり、業務フローを整理したり、ユーザーの利用状況を分析したりして要望を把握し整理しましょう。
そして残りの半分の大事な作業は、要望をどんな形で実現するのか決めることです。典型的なウォーターフォール型プロセスであれば、受け取った要望から「要件定義」を作成する部分です。アジャイルな開発であればユーザーストーリーをREADYにする作業です。スクラムならプロダクトバックログリファインメントです。要望を実現する無数の方法からひとつに決める仕事といっていいでしょう。
この仕事のカギは「決める」です。なにをつくるか知るのは、なにをつくるか決めること。決断が求められます。決断とは、選択肢を考え、良し悪しやトレードオフを判断し、そして「よっしゃこれで行く！」と選び取るというプロセスです。
こうした決断は、実のところ設計です。要望をもとに、機能仕様を「設計」する。ユーザーの声をもとに画面を「設計」する。現状のアーキテクチャとコードベースをもとに、機能追加の実現方法を「設計」する。これら設計のためには、情報とともに時間が必要です。しかし、最初に設計してあれば、後段の作業で「あれ、ここってどうするんだっけ？」と考える時間が減り、コードを書くことに集中しやすくなります。
しかし一方で、ここで難しいのは「どこまで決めるのか」と「なにを決めるのか」です。典型的なウォーターフォール型プロセスであれば、要件定義の段階で決めるべき項目が定まっているかもしれません。プロセスを問わずここで重要なのは、どこまで決めておけば後がスムーズになるかです。これはチームとつくるものによって大きく異なる点です。とりわけチームの能力や経験値しだいで、ざっくり決めておけばいいチームもあれば、詳細な仕様や設計が必要なチームもあります。
私が経験した「ここまでは決めておこうね」という例をいくつか紹介します。
- チームの様子：ベテラン勢
- つくるもの：ECサイトのカタログ開発を受託（カートなどの注文機能ははなし）
- 最初に決めたこと：
- 画面ワイヤフレーム
- 主要な入力と表示項目
- チームの様子：新人とベテランで混成された新規チーム（リモート）
- つくるもの：新規サービスをビジネス一体のスクラムで
- 最初に決めたこと：
- アーキテクチャ
- ユーザーストーリーマッピング
- 画面のラフなスケッチ
- 操作フロー（複雑な認証を含む）
- チームの様子：ローンチしたチームが引き続きエンハンスをスクラムで実施
- つくるもの：オンライン教育サービス
- 最初に決めたこと：
- デザインまで含む完全な画面イメージ
- ビジネス面のゴール（KPI）
- DBテーブルごとのCRUD分析結果
- 実装方針を議論し、どのクラスにどう組み込むか決める
- 受入テストケース
- チームの様子：ベテランと若手2名体制
- つくるもの：ハードウェア組み込みの放送受信部分（新規）
- 最初に決めたこと：
- 放送の標準規格の仕様書
- 仕様のどれに対応するか一覧
- クラス図
- シーケンス図
- オブジェクト図
- テスト用データ
上記の整理のとおり、どこまで決めれば後がスムーズになるかは、チームの様子と「なにをつくるか」によって大きく異なります。また、最初に考えて決断すべきことは状況に応じてさまざまで、一般化できません。しかし、いまいるチームがこれから作ろうとしているものについては、特定できるはずです。最初に決断すべきことを先送りにするのは、プロジェクトの後半、時間が厳しくなってきたときに、余計に時間を食う要因になるだけです。「後で考えればいいや」にはくれぐれも気を付けてください。
練度の高いチームならば最初は最低限のことだけ決めて、あとはつくりながらどんどん決めていけます。遠くまで見通しながら進んでいくイメージです。一方で未熟なチームなら、細かな実装設計まで最初にやっておくほうがスムーズです。見通しが利かないので、最初に細かくルートを決めておくイメージです。具体的にどこまで決めるかの見極めは難しいかもしれません。簡単なやり方を紹介します。
- ある事柄について、「ここはどうする？」とチーム全員に聞きます
- 全員が異口同音に「こうすればいい」と言うなら、後で考えればOK
- 意見が異なったり、考え込む人がいるようなら、先に決める
- 先に決めようとして、難しく感じる場合は、「いつ決めるか」「なにがわかったら決められるか」を決めておく
「最初に決断すべきこと」という表現の裏には、後で決断すべきことは最初にしないという意味合いも含まれています。先に考えるとかえって時間の無駄になるものです。プロジェクトが進んでいくと、ユーザーや仕様やデータベースや影響するコードの範囲について、チームの理解が深まります。理解が深まったときの方が、よりよい判断と決断ができるなら、最初に決めない方が有利になります。
アジャイルな開発では、判断を先送りにして最善の判断ができるようにするLast Responsible Momentという考え方をよく用います。先送りするにも限度があるので、これ以上遅らせられないギリギリのタイミングで決断するという意味合いです。単に決断を遅らせるだけではなく、その決断をより的確にするための情報収集も計画に組み込みます。
【つくれるように決める2】つくってみないと決められない
最初に決めるべきことが最初に決められれば、仕事はスムーズになります（比較的）。しかし決めたいのに決められないこともありますし、ユーザーのフィードバックなどによって決めたのに後からひっくり返ることもままあります。そうなってしまったら、チームみんなで「わかってよかったね！」と叫びましょう。
皮肉ではありません。いまは決められない、前に決めたのは間違っていたということが、いまわかってよかったのです。もっと後でわかるよりも、いまわかってよかったね。
わかってよかったのですが、わかってしまった以上は何とかしないといけません。ということは、フィードバックを受けるのがリリース後では、もはや手遅れかもしれず、手遅れにならないタイミング、プロジェクトの初期や前半でフィードバックを受けねばなりません。プロトタイプやUIモック、Figmaなどのツールでユーザーと話し合うアプローチもありますし、アジャイルプロセスであればフィードバックを受けたい部分を早期のイテレーションで開発する計画になります。ユーザーは使ってみないと判断できないし決められない、ということもあるでしょう。できる限り、実際に使ってもらってフィードバックを得ましょう。
また、利用しているテクノロジーや既存のコードベースに足をすくわれて、決断をやりなおす場合もあります。つくるのが思ったより時間がかかる、影響範囲が広い、思っていた方法では実現できないとわかるなどのケースです。これも同じく、プロジェクトの終盤では致命的なので、早期に判明するように計画しましょう。技術を用いて技術に関するフィードバックを得るわけです。
アーキテクチャの全体（エンドツーエンド）を最初に確認する曳光弾開発、採用する技術のPoC（Proof of Concept）開発、着手前に調査や実験の時間を取るスパイク、複数の選択肢を並行して進めながら徐々に絞りこんでいくセットベース開発などのアプローチがあります。端的に言えば、つくれるかわからないまま突き進んではマズいので、本当につくれるのかを早い段階で確認するという考え方です。開発におけるリスクマネジメントの手法でもあります。
こうした得られたフィードバックは常に計画からの逸脱と計画変更を意味します。フィードバックを得ることを計画し、さらに「フィードバックによって計画が変わること」を計画するのです。計画が変わることを織り込んで完成予定日を伝えられれば、最終的に予定通りにリリースできる可能性が高くなります。
【つくれるように決める3】見積もりのテクニック
なにをつくるのか明確になり「これならできる」と確信を持てても、それだけでは計画になりません。どのくらいでできるのか、できるまでの時間、人員、予算などの必要なリソースの目途がないといけません。1週間でできますと、3年あればできますではまったく違います。技術的には可能というのと、30兆円かかるというのもだいぶ違います。見積もりが必要です。
見積もり対象の単位はいろいろ考えられますが、基本的には機能やフィーチャなどの、期待する人が把握できる単位にします。ストーリーポイントとプランニングポーカーがアジャイルな開発ではよく使われる見積もり手法ですが、これら手法の基本的な考え方自体はアジャイル以外でも適用できます。ストーリーポイントとプランニングポーカーには以下の特徴があります。
- 相対値である - 時間や工数のような絶対値ではなく、見積もり対象どうしの対比で見積もる
- 集合知を生かす - 異なる知識を持った複数の人が見積もる
- 専門家が参加する - 専門知識や経験にもとづいて見積もる
- 提供する人による - 開発の作業をする人自身が見積もる
リリースする機能やフィーチャのストーリーポイントを合計したものが、そのプロジェクトの規模になり、実現にかかる時間は、実際に提供する人々の能力に関わります。スクラムであればチーム固有のベロシティが「速度」で、規模が「距離」です。そして距離を速度で割ると時間（期間）を算出できます。ウォーターフォール型プロセスの場合も、自分の組織やチームが同じ規模のプロジェクトをどのくらいの期間で達成してきたか、過去のデータを元に推測できます。実績を元にするという意味ではアジャイルでもウォーターフォールでも変わりません。
ストーリーポイントやプランニングポーカーはアジャイルな開発でよく用いられるものの、ウォーターフォール型プロセスを用いるプロジェクトでも全体の規模を知る方法として有効です。以前、私たちのチームがストーリーポイントとプランニングポーカーで見積もり、別チームは同じものをファンクションポイント法で機械的に見積もったことがあります。結果は3年くらいかかるという規模でしたが、私たちの見積もりもファンクションポイント法による見積もりも、だいたい同じ数字になりました。当たり前と言えばそうかもしれませんが、内心ではお互いに「そんないい加減な・古くさい方法で見積もったって……」という気持ちがあったので、驚きあった記憶があります。なお、複数の異なる手法で同じものを見積もるというのも有効なテクニックです。
見積もりをするときは、機能細分化や開発タスクなどの細かい単位は使いません。計画の細部を詰めるときには必要かもしれませんが、見積もりの時に細分化しすぎるとかえって見積もりが不正確に、とくに過少見積もりになりやすいので気を付けてください。以下に引用した図は、見積もりに投じた労力と見積もりの正確さを示したグラフです。
『アジャイルな見積もりと計画づくり』
著：マイク・コーン、訳：安井 力 / 角谷信太郎、マイナビ出版, P72をもとに編者模写
図は「私の経験に周囲の議論を加味したものであって、測定データにもとづいたものではない」とと注記してありますが、見積もりを細かく正確にしようとしすぎると、想定外の事態を考えられなかったり、コミュニケーションオーバーヘッドや手戻りや確認作業などを過小評価してしまい、かえって不正確になるという傾向を示しています。
【つくれるように決める4】段階的に計画する
開発の現場には色々な種類のやり方があり、いつ計画をするか、そのタイミングもさまざまです。なにをするかわかっていないうちに計画してしまう、計画しないといけないという現場もよく耳にします。予算を立てないと進まない、計画しないと人員が確保できない、まず納期を回答しないと叱責されるなど、なにもわからないタイミングで計画しないといけない事情もあると思います。
ここまでに述べてきた、最初に決めること、後から決めること、計画を変える計画まで考えると、計画には少なくとも3つの段階があることがわかります。
A：一番最初の、決めるべきことを決める前の計画
B：最初に決めるべきことを決めたうえでつくる計画
C：途中で決めるべきことや状況の変化を踏まえてつくる計画
Aの時点の計画は、計画とは呼べないくらい不確実性が大きいものです。古典的なウォーターフォール型プロセスによる受託開発では、Aを概算見積もりなどと呼び、数100%というスケールで大幅に変わる前提で取り扱います。またBに対応する要件定義を終えてから、初めて以降の開発規模を見積もって契約するのがセオリーです（と言い切れるほど一般的かどうかは自信がありませんが……）。
このような段階的なアプローチには理由があります。以下の図は書籍『ソフトウェア見積もり 人月の暗黙知を解き明かす』で紹介されている、不確実性コーンと呼ばれるグラフです。
▲図4-2 カレンダー時間に基づいた不確実性のコーン。『ソフトウェア見積もり 人月の暗黙知を解き明かす』
著：Steve McConnell、訳：溝口真理子 / 田沢 恵 訳、監修：久手堅憲之、 日経BPマイクロソフトプレス、P41 図版は編者による模写
このグラフは見積もりをしたタイミングとその確実性、というよりも不確実性を示したものです。プロジェクトの初期に立てた見積もりは確実性が低く、25%から400%という範囲で大幅に外れますが、プロジェクトが進むにつれて、確実性が徐々に高くなり、外れる幅が狭まっていきます。不確実性がゼロになって見積もりと現実が一致するのは、最終的に完成した瞬間です。
しかし同書では、さらに次の図を示してこうも言っています。
図4-3(下の図)は、プロジェクトがバラツキを減らすことに注力していない場合にどうなるかを示しています。…問題は見積もりが収束しないことではない。プロジェクト自体が収束しないことなのだ
▲図4-3 プロジェクトがうまくコントロールされていなかったり、うまく見積もられていなかったりすると、コーンで表される見積もり誤差よりもさらに多くの見積もり誤差を含む「不確実性の雲」になる可能性がある。『ソフトウェア見積もり 人月の暗黙知を解き明かす』
著：Steve McConnell、訳：溝口真理子 / 田沢 恵 訳、監修：久手堅憲之、 日経BPマイクロソフトプレス、P42 図版は編者による模写
また、『PMBOKガイド 第7版』には「不確かさパフォーマンス領域」が定義されています。同書では、プロジェクトのマネジメントにおいては「不確かさ」や「曖昧さ」といったプロジェクトに内在する不確実要素を認識し、対応する必要があると述べています。またそうした対応はプロジェクト期間を通じておこない、徐々にリスクを下げていくと示されています。こうした継続的な活動こそが、最初に決めないことを途中で決めたり、想定外の状況に対応すること、つまり変化への対応です。ここで、先に示した計画における3つの段階を再掲します。
A：一番最初の、決めるべきことを決める前の計画
B：最初に決めるべきことを決めたうえでつくる計画
C：途中で決めるべきことや状況の変化を踏まえてつくる計画
アジャイルな開発ではCの計画がある意味ではすべてになります。もちろん、プロジェクトを開始するときにはAとBの計画がありますが、アジャイルな開発は、積極的に変化を起こしていくのが前提です。つまりBの計画があっても、たちまちCの計画によって上書きされます。さらにCの「途中で決めること」「状況の変化」はたびたび起きるので、何度も何度も計画し直すことになります。常に計画し続けると言ってもいいでしょう。価値を高めるために計画を変えたり、納期に間に合わせるために計画を変えたりと、ゴール目指して計画し続けるのです。
アジャイルな開発では、継続的に計画し続けます。このことを、書籍『アジャイルな見積もりと計画づくり』では名詞の計画（plan）に対して動詞の計画づくり（planning）と呼び分けて表現しています。アジャイルに進めれば、常に変化に対応し、計画づくりを続けることになるのです。
ウォーターフォール型プロセスではそこまでの変化を想定しません。変化がゼロということではなく、スケジュールやマイルストーン、予算に合わせて許容する変化を制限し、コントロールします。逆に言えば、許容できる変化は受け入れるし、それはやはりプロジェクト進行中の変化が避けられないためです。ウォーターフォール型プロセスで変化を一切許さない計画を立ててしまったら、それは理想ではなく夢物語と言っていいでしょう。一般的には工数のバッファを設けて、変化に対応しても重要なマイルストーンが守れるように利用します。お金で解決できる問題のために、予算バッファを設ける場合もあります。
いずれにしても、計画と現状を照らし合わせながら、プロジェクトの完成を待っている人、期待する人、関係者に最新の状況を共有するのが大事です。とりわけ計画から大きく外れたり、計画が大きく変わったりする状況は、できるだけ早く、正確に、正直に伝えて今後について話し合いましょう。これもまた信頼を積み上げる行動です。
【つくれるように決める5】納期は幅で表現する
先ほど紹介した不確実性コーンで示されるように、見積もりには不確実性が含まれます。とりわけプロジェクト開始前の初期コンセプトで見積もると、実績は4分の1から4倍になる可能性があります。要求の完了まで進んでから見積もったとしても、見積もりの約70％から1.5倍になる可能性があります。月曜の朝に「やることは決まりました。簡単なので今週金曜にできます！」と言ったとしても、結果的には来週の水曜日までかかってしまう可能性があるということです。「4週間でできる」といったなら、プラス2週間必要になる可能性があるということです。ちょっとしびれますね。もちろん不確実性コーンはごく一般的な概念に過ぎず、実際の幅は状況によって異なるので、自分たちの実績、とくに見積もりと最終結果のデータを参考にした方が正確性は高まるでしょう。
見積もりや納期に不確実性が含まれるのであれば、その通りに伝えるのが正直です。つまり「1週間かかります」「金曜日にできます」「4週間です」と伝える代わりに「営業日で5〜8日かかります」「金曜から来週水曜の間にできます」「4〜6週間です」のように幅を持たせて表現します。伝え方は相手によって工夫が必要です。そのように伝えても記憶には最短の納期しか残らない人もいます。幅で言われても、それを受けてどうしたらいいかわからずに困ってしまう人もいます。納期を伝えるのは提供する人の仕事ですが、期待する人が納期を聞いてどう考え行動するといいか、一緒に相談するといいでしょう。
不確実性はプロジェクトという非定型業務、いうなれば水ものの仕事に本質的に内在するものです。上手にやれば上手くいくとか、最初にちゃんと考えればいいとか、能力があるチームならできるとか、そういう話ではありません。理想的な状態でも不確実性があります。逆に、下手にやったり、最初に考えなかったり、能力がないと、不確実性はさらに大きくなってしまいます（なので、ここまでに理想に近づけるやり方を紹介してきました）。
なお、確実な納期を伝えようとすると、全体的に遅くなってしまう傾向もあります。Shiibaさんの「約束は開発を遅らせる」に直感的にわかりやすく書いてあります。思いついてパッとつくるのに比べて、つくれるか考え見落としを防ぎリスクも計算に入れて計画すると、確実ではあるけれど時間のかかる開発の進め方になってしまう現象です。また、見積もりに参加するひとりひとりの頭の中に「確実な納期」という気持ちがあると、自然と安全寄りの見積もりになりがちでもあります。さらに、余裕のある確実な納期でも、納期前に完成することはなく常に納期いっぱいまでの時間を使ってしまうというパーキンソンの法則もあります。幅を持って納期を伝えられれば、こうした影響を排除しやすくもなります。
「犬が宿題を食べちゃう」ような不確実性に向き合い、スコープを調整するためには
私は小学生のころ忘れ物が多くて、とくに宿題をよく忘れるので担任の先生からにらまれていました。あるとき私の苦手な作文の宿題が出たのですが、これは忘れずちゃんとやったのです。想定されたリスクは回避できました。ところが、想定外のリスクがありました。やった宿題を飼っていた犬が食べちゃったのです。ほんとです！
その後どうなったかはご想像にお任せしますが、世の中にはこうした思わぬ状況の変化、想定外のリスクがあります。ソフトウェアやプロダクトの機能やフィーチャを開発する、提供するという場面において、「状況の変化」は煎じ詰めると次の2つになります。
- 提供する側が、やろうとしたことができないと気づく
- 期待する側が、ほしいと言ったものが変わったと気づく
そしてどちらにしても、リリースの納期を変更するか、リリースの内容を変更する必要が出てきます。大枠の話としては、想定外のことにも対応できるように計画すべきですし、対応できるマネジメントのスキルを持たねばなりません。ここではより絞り込んで、リリース内容の変更、すなわちスコープ調整に対応するテクニックをいくつか紹介します。
【調整する1】「これはマズい！」と「これはスゴい！」の2種のリスクを理解する
まずお伝えしたいのはテクニック、というよりも、リスク（変化の可能性）の捉え方です。リスクには脅威と好機の2種類あります。脅威はプロジェクトの成功を脅かすもので、遅延だったり、技術的問題、見落としの発覚などがあります。提供する人の側で起きる状況の変化は、この脅威になることが残念ながら多いようです。もちろん、期待する人の側にも、必要な機能の見落としや、パフォーマンス要件が甘い、急な納期の前倒しなど脅威となるリスクがあります。
それに対して、好機は当初考えていたよりもいいことが見つかるリスクです。納期よりも早くリリースできる、思ったよりユーザーを多く獲得できる、自プロダクトに有利な法制変更が起きるなどがあります。これはいいことですが、起こりっぱなしで放置すると好機を逃したり、メリットを得られなかったりします。たとえば開発が順調に進んで予定より2週間早くリリースできるのに、関係者への調整をしなかったため誰も利用しないとか、サポート部門が間に合わないからリリースを早められないなどの「もったいない」結果があり得ます。
リスクが脅威であっても好機であっても、実際に状況が変化したのであれば対応する必要があります。ローンチしたサービスが予想よりも速いペースでユーザーを獲得できているなら、ユーザー獲得のフィーチャよりもリテンションのためのフィーチャやサポート強化のための機能を優先してスコープ調整をするかもしれません。
こうした好機を生かすアプローチはアジャイルな開発で多く見られ、ウォーターフォール型プロセスでは積極的でない印象があります。開発の一部が1日前倒しで進んだとき、スクラムならプロダクトバックログから1日ぶんなにか他のことができます。ウォーターフォール型プロセスで計画が組まれていると、そこで着手できる1日ぶんの仕事が見つけられず、そうした仕事を捻出するにも労力がかかり他への影響もあったりして、せっかくの1日が無駄になってしまうようです。時間ができたらやる小さな仕事を、いくつか用意しておくといいかもしれません。
まとめると、スコープ調整は別に悪いものではありません。状況が変化してしまったなら、可能な範囲で変化に合わせた方が有利です。状況の変化には悪いものも良いものもあるので、両方とも生かしましょう。こう考えてみると、当初予定通りに終わる方が、変化に対応せず好機も生かせなかった「失敗」プロジェクトに見えてきます。
【調整する2】変化は当然のものとして受け入れる
期待する人の気が変わったら、そのことは受け入れましょう。前はこう言ったじゃないか！と反論しても、変わっちゃったものはしかたないのです。単に気が変わっただけならば、説得して元に戻せるかもしれません。しかし多くの場合、気が変わったのではなく、「期待する人が置かれた状況」が変化しているのです。
期待する人も仕事なので、なんらかの情報を元に判断して、ほしいものを考えます。ユーザーの声、市場環境、ビジネスの好調さ、世の中の動き、売り上げ目標の達成状況といった、さまざまな情報や状況をもとに、なにがほしいかを決めます。ただし、こうした状況はソフトウェア開発の都合以上に大きく、頻繁に、びっくりするほど変わります。2022年で考えてみれば、SNSサービスを提供する企業や組織はイーロン・マスクがTwitterを買収したとき、ユーザー奪取のための千載一遇の変化（チャンス）に遭遇しました。*2
そうした変化に応じて、提供する側にスコープの変更を依頼するのは当然です。もちろん、だからと言って期待する人の言い分を100％受け入れる必要はありません。必要なのは、提供する人も一緒に状況の変化に向き合うという態度です。
【調整する3】同じ立場から最善の打ち手を考える
なんらかの状況の変化に対応するための、最善のスコープ調整とはどのようなものか考えてみましょう。最善策は、「変えたいところをぜんぶ変える」と「以前の計画からまったく変えない」の間のどこかにあるはずです。期待する人にも事情があるし、提供する人にも事情がある。それぞれの事情を一緒に広げて眺めながら、どうしたら新たな状況に対応できるか策を練りましょう。「問題 vs. 私たち」の構図を作るわけです。その意味では、期待する人と提供する人が心理戦や駆け引きを繰り広げて対立構造をつくることはおすすめしません。
上記2資料は平鍋健児氏の『アジャイルは本当に日本のソフトウェア開発を変えることができるか？』スライド45, 47より
期待する人が見ている状況の変化は、プロダクトやビジネスを取り巻く状況の変化なのですから、当然提供する人にとっての変化でもあります。その変化に対して、誰がどう対応すると一番上手くいくか、これは両者が一緒に考える方がよい解が見つかるに決まっています。簡単な話まで全員が集まる必要はないでしょうが、そもそも両者の、全員の問題だという意識は持っておくべきです。ここから、プロダクトやビジネスを取り巻く状況については担当者だけでなく全員がうっすらでも知っておくべきだし、変化がなくてもときどき共有をするといいという話にもつながります。
状況の変化に直に接した人は、びっくりして過剰反応してしまうこともあります。どうしてもこうしなくては！ と思い込んでしまったりもします。全員、状況に関わってはいますが、その関わり方や距離感には違いがあります。違った見方をできる人で集まった方が、冷静に建設的な議論がしやすいでしょう。逆に温度差がありすぎてみんな緊張したり、距離の違いが対立を生んでしまうケースもあると感じており、こういう場合は外部のファシリテーターがいるといいなあとも思います。
【調整する4】大きくするより小さくするスコープ調整
スコープ調整は、多くの場合、機能追加したいという希望の形を取ります。次にリリースするとき、この機能も足してほしいとか、あの機能をこう変更してほしいというものです。しかしそのまま受け入れるとリリースが大きくなってしまいます。「小さく作るを積み重ねる」の項で書いたように、リリースが大きくなると信頼を損ないやすくなります。
ですから、機能を増やしてリリースを大きくするよりも、小さなリリースの回数を増やすように調整しましょう。小さく作るのは信頼を高める方法ですし、リリースを小さくすればリスクも小さくなります。リリースを小さくする案を考えてみます。
- 【案1】もともとのリリースに機能A,B,Cが含まれ、そこに機能Dを増やしたいとします。まずはA,B,Cをリリースしたうえで、Dだけの開発を始めます。
- 【案2】機能A,B,Cから、Cを捨てて代わりに機能Dを入れてリリースします。アジャイルな開発でインクリメンタルに進めていれば、有効な手段です。
- 【案3】機能A,B,Cをすべて中断し、まず機能Dだけを開発してリリースします。続いて、中断していたA,B,Cを再開します。
- 【案4】もともと機能A,B,Cを予定していて、BをB+に変えたいとします。まずはA,B,Cをそのままリリースし、その後でB+に作り替えるリリースを計画します。
- 【案5】機能A,B,CのうちBをB+に変えたいので、A,Cだけを先行してリリースし、それからB+を作ります。
- 【案6】逆にA,Cを中断してB+だけを作ります。ここでさらに小さくし、Bだけのリリース→B+のリリース→A,Cのリリースと分ける手もあります。
リリース回数を増やすと、リリースの手間も増えてしまうので避けたい気持ちが働きがちです。一般論としては手間を減らすより回数を増やす方が、リスクを小さくできる反面、全体の手間や工数は増えてしまう傾向があるからです。特にリリースに手作業が多いと、工数にも影響しますしヒューマンエラーが起きやすいという別の問題も出てきます。
そのためリリースの回数を増やせるよう、リリースの手間暇、工数を小さくする努力も必要になってきます。リリースが大変だから避けるのではなく、リリースをたくさんすべきだから安全高速にするということです。これにはDevOpsのアプローチが有効でしょう。デプロイ作業の自動化、ビルドの自動化、テストの自動化などです。ウォーターフォールだから自動化の優先順位が低いという意見も聞いたことがありますが、無視できないレベルの恩恵があると私は考えています。
【調整する5】松・竹・梅どれをつくるのか。レベルを調整する
スコープ調整では機能単位で増やしたり減らしたりするだけでなく、ひとつの機能のレベルを調整することもできます。機能としては同じでも、とっても手をかけて美しい特上の出来映えにもできるし、みすぼらしいけれど動くには動くという並以下の出来映えにすることもできます。うな重の松竹梅とか、並と特上みたいなものです。並ではちょっと物足りなくても、うなぎ（機能）がないよりはマシという場面は多いでしょう。
どんな出来映えを目指すか、レベルを調整することでアーキテクチャや実装設計に選択肢が生まれます。たとえば処理に時間のかかるユーザーリクエストを、分散したキューを経由してエージェントで処理し完了したらメール・SMS・プッシュ通知でユーザーに連絡するのか、Webブラウザでタイムアウトしたらリロードしてもらうだけか、という選択肢もあり得るでしょう。後者の実装はエンジニアとしていまいちだと感じるかも知れませんが、できないと言ってしまうよりは有効な選択になり得ます。
期待する人と提供する人それぞれに選択肢があります。そうした選択肢を用意し、検討し、決断するうえでは、これまた両者の視点があるほうが上手くいきます。選択肢を用意するのはそれぞれの専門性が生きるところですし、用意された選択肢をどのように評価するかにも専門性が必要でしょう。評価を付記した選択肢を持ち寄って選ぶ場合は、両者がそれぞれの言い分や事情を共有しましょう。エンジニアならば、つくり方に口出しされたくない、という気持ちがあるかもしれません。しかし、よりよい選択のためにも、またお互いのことを知り合う意味でも、つくり方の選択肢も説明する方がいいと考えています。*3
ただし、「レベル」は調整できても「品質」は調整できるパラメータではないことは認識すべきです。仮に、見栄えが悪かったとしても、機能面では問題なく動作しないといけないのですから、品質は維持する必要があります。また内部品質が悪化すると技術的負債として後々まで影響が残ります。
余談ですが、梅や並のレベルの機能をリリースしたのに、それで十分に満足してもらえるという面白い結果になることがあります。使い物になるかギリギリだと思っていたのに、意外と利用されている、評判も悪くないというものです。そうはならないこともあるのですが、いずれにしても利用状況をウォッチしていると、あとから作り直したり改善したりする機会が作れたりもします。
【調整する6】雑談で先手を取る
状況の変化を早めにキャッチできれば余裕を持って対応を考えられます。まったく未知の方面で誰にも予想も理解もできないことが起きるなんてことあるわけが、なくもないですけれど、あんまりありません。多くの変化には予兆や気配があって、詳しい人や近くにいる人は早く気づいています。チームのメンバーのだれも詳しく知らない領域のことは、大きな変化が起きて初めて知ることになりがちです。
そこでチーム外の人々から情報を集めるため、雑談をおすすめします。変化に備える、変化の影響を和らげるための戦略です。ユーザーやステークホルダーが、最近どんなことに興味があるのか、プロジェクトについてどう考えているのか、今後の見通しをどう考えているかなど、気軽に話す場をときどき（できれば頻繁に）でいいので、設けます。
チーム外の人にいきなり雑談を持ちかけるのは気が引けるかもしれません。向こうも驚くかもしれません。その状況自体が、危険をはらんでいます。お互い、なにかちょっと気になること、聞きたいことがあるときに「気が引けるなあ」と思って、やめてしまう。時間がたって重大な事態になってから「早く言ってよー」とぼやくことになる。そんなのはお互いに損ですね。
普段から雑談をしていれば、そういう事態は減らせます。だから雑談を始めて、続けましょう。とくに理由がなくても、必要ないと思っても、3分話すだけでいいので、相手の席にふらっと行って「最近どうですか？」と声をかけてみましょう。
オンラインならもっと気軽で、チャットで「いまちょっといいですか？」とZoomやSlackハドルミーティングに誘いましょう（テキストチャットの雑談はかえって時間を取るのでおすすめしません。話す方が早いです）。数回やっていれば、相手も慣れてくれます。相手が嫌がりそうなら、雑談の目的を説明したら納得してもらえるかもしれません（この記事を見せてもいいかもしれません）。いきなり声をかけるのに抵抗があるなら、スケジュールを入れるのもいいでしょう。どうしてもダメなら無理をせず、応じてもらえそうな他の人を探しましょう。
雑談の声かけが難しく感じるかもしれません(そんなことない人も多いかもしれませんが、私はすごい悩みます)が、たとえばこんなふうに切り出すといいです。
- 最近どうですか？
- なにか面白いことありましたか？
- このあいだからなにか変化ありましたか？
- 最近順調でヒマなんですよ、そちらはどうですか？
- 最近バタバタで忙しいんですよ、そちらはどうですか？
- このあいだ言ってたあれ、やってみた/見てみた/調べてみましたよ
- なにか相手の関心がある分野のニュースで話を振る
無理に話を引き出したり延ばしたりすることはありません。「どう？」「まあまあ」だけで終わっても構いません。何かあったら話せる関係性と場作りに意味があります。「なにも話さないということは、なにもないのだ」という安心材料にもなります。
ただ、忘れてはならないのは、雑談をとおして先手を取るのは「状況の変化」に対して、ということです。相手がやろうとしていることを、先取りしたりしてしまうと、警戒されて話してくれなくなってしまうかもしれませんし、利用しようとしてくるかもしれません。なにかアクションを取るときには、あらためて相手と認識や背景を共有する方が安心です。
もうひとつ忘れてはならないのが、「あいつは話し始めると長くなる」と思われないようにすることです。しつこく聞き出さないと話をしてくれない人もいたりするので面倒もありますが、これは雑談とはちょっと違う問題ですね。
もうちょっと具体的なスコープ調整戦略を考えてみる
最後に、スコープ調整のさくせんについて、チームの構成や状況など、いくつか前提を設定し、具体的な例をいくつか紹介します。
新米スクラムチームの場合
こうした状況では、なによりも安定して成果を出せるようになるのが第一で、そのためにスクラムのフィードバックサイクルを用いて改善と開発能力向上、そのための学習に集中すべきでしょう。
この状態でチームが「スコープ調整しなきゃ。どうしよう」と心配してもあまり意味はありません。まだできるようになっていないチームだとまず自分で認め、周囲にも理解してもらいます。チームとして求められる品質のものがアウトプットできるようになり、さらにそのスピード（スクラムならベロシティ）が安定して初めて、納期について話を始めてください。そうしないと納期を守ろうという意識のせいで、プロセスもなく開発そのものが崩壊し、品質が無視され、学習も改善もできずたんなる無秩序な日々を過ごさざるを得なくなるリスクがあります。スクラムの正反対ですが、失敗パターンのひとつとしてよく目にする光景でもあります。
サービスのローンチ前～直後の場合
最初のリリースに向けて開発が順調に進んでいると、ローンチに含める機能について迷いが出てくることがあります。必要最小限のMVPで大丈夫か、最初のターゲットユーザー層は合っているか、もうちょっとオペレーションやサポートの備えが必要ではないか……など。小さくリリースして仮説検証サイクルを回すのが基本ですが、正解がない世界なので常に悩みはつきません。
「やってみないとわからない」世界であれば、全員でよく考えてもあまり意味がありません。PdM（プロダクトマネージャー）やPO（プロダクトオーナー）のような専門領域の知識のある少人数で議論・検討し、小さなリリースを積み重ねることを意識しつつ、最善と思える決断を素早く下し続けるしかありません。
この局面で役に立ちそうなアイデアとして私が学んだことがあるのは、デュアルトラックアジャイルと、Gabrielle BenefieldらによるMobiusを用いたOutcome Deliveryです。いずれも実際に使ったことはないので、紹介に留めておきます。
デュアルトラックアジャイル*4は、プロダクトのディスカバリーとデリバリーという2つのトラックを設け、1つのチームの中で両方のトラックを並行して進めるアプローチです。ディスカバリートラックでは仮説を設定し検証するための大小様々なサイクルを進め、開発すべきフィーチャを見つけます。デリバリートラックでは実際にそのフィーチャを開発しデリバーします。2つのトラックの活動が同時に、同じチームの中で起きており、常に学びを生み続けるという複雑なアプローチになります。最近では継続的ディスカバリーとも呼ばれるそうです。
Mobiusはメビウスの輪のように繰り返しループするイメージを用いて、ディスカバリー・オプション・デリバリーの3つのフェーズをぐるぐる回すという進め方です。日本国内では株式会社アトラクタによるOutcome Delivery Practioner研修がありますが*5、各フェーズで使えるさまざまなテクニックがカードとして提供されており、カードを選んで実践しつつ進め方自体を試行錯誤しながら学べる形になっています。ayumi_h’s blogの記事がわかりやすかったので紹介しておきます*6。
サービスを運用中の開発チームの場合
運用作業もあるし、監視をして障害があったら対応しないといけないし、チームは拡大するし、コードベースは複雑になるしと、混乱の中で日々追われるように仕事をこなす、という状況もあるでしょう。（とはいえ、サービスが当たるって幸せなことですね！） こうした状況では、あるていど計画された仕事と、突発的な対応の両方があります。エンハンスや緊急ではない障害対応は、ある程度計画を立てられるものの、突発対応が割り込むので計画はどんどん狂っていきます。期待する人も多様になってくるので、それぞれの要望に対して見積もりと納期の約束をしたくなります。
しかし、なにかひとつ遅れると玉突きですべて遅れていくのでスコープ調整の対応だけでも大変になってしまいます。ですから、約束したくなるのをぐっと我慢して、いまやっている作業だけについて完了見込みを伝えます。その先は、自分たちでもわからないので、わからないとはっきり伝えるしかありません。あるいは、非常に大きな幅、たとえば1ヶ月〜6ヶ月というような、「わからなさ」が伝わるような幅で伝えます。
再三お伝えしていますが、リリースはできるだけ頻繁に、小さな単位で行うので、少なくとも次のリリースだけは予定が当てになるようにしましょう。ある程度大規模な機能追加をするため小さなリリースに収まらない場合は、複数回のリリースに分解して開発・デプロイします。機能が揃うまではフィーチャートグルで無効化するようにして、ビッグバンマージとビッグバンリリースの影響を最小化します。
さらに混乱が深い状況、たとえば、サービスの品質に問題があったり、サポート問い合わせが多かったり、監視やオペレーションの手作業が多い、といった状況では直近のリリースですら予想できないくらい割り込みが多くなる場合もあります。開発の時間を一定量確保するために、一定の工数を最初から割り込み向けに確保したり、割り込み担当のメンバーや別チームを用意する手もあります。ただし、同じメンバーが割り込みだけをずっと担当していると苦しくなりがちなので、適宜ローテーションするといいでしょう。
私が知るなかでは、サポートからの問い合わせの担当を1人おき、毎週交代するチームがありました。開発チームが3つあるなかで1チームに割り込みを受け付けてもらい、そのチームを毎スプリントローテーションするというケースも見たことがあります。小規模なスクラムチームでPOが割り込みに対応しているのも見ましたが、PO自身が沈没しがちだったのでおすすめはしません。
サービスが成功して規模拡大するフェーズでは、関係者、ステークホルダーも増えていきます。そして、それぞれの思惑を持ってサービスに関わってくるので、サービスの目的やゴール、ビジョンについて全員の認識が合っているとは限りません。そうした人々がそれぞれに開発チームやスクラムチームのPOに依頼をしてくると、依頼の交通整理コストが一手に開発側にかかってきてしまいます。これをさばけるパワフルなPOやPdMがいればいいですが、調整型の人だと押しつぶされてしまうこともあります。
そうしたときは、誰かが頑張って調整するのを諦め、ステークホルダーを一堂に集めてその場で意見を統一してもらいましょう。スクラムであればPOがそうした場の主催者になりますし、スクラムマスターは場作りと議論のファシリテーションを手伝えるはずです。スクラムでないなら、プロジェクトマネージャやチームリーダーがそうした役割になりますが、可能であればプロジェクト外から第三者のファシリテーターを呼ぶことをおすすめします。
まとめ
本記事では、期待する人と提供する人の間で必要に応じて建設的なスコープ調整をするための前提や考え方を紹介しました。繰り返しますが、まずは信頼関係が必要です。そして、ちゃんとつくれるように決めてからつくるという進め方、そして自信を身につけなければなりません。脅威だけでなく好機を捕らえて生かすためにもスコープ調整は大切です。スコープ調整は状況の変化に対応するためのポジティブな手段です。なにより、期待する人の期待に応えたり、提供する人が期待に応えてくれたりするのは、楽しい仕事です。みなさんの仕事が楽しくなるよう願っています。
編集：はてな編集部
*1:99回成功してきたチームでも、100回目の失敗で激しく信頼を損なう、という結果ももちろん想像できます。過去の信頼の積み重ねだけでなく、チームが置かれた状況、文化といった要素も結果に影響します。そして、もしもチームが「成功して当然失敗は認めない」みたいな文化にいる場合には、大幅なバッファを積むとか、人のせいにするとか、政治・権力的な後ろ盾を使うとか、本稿で語られないアプローチのほうが有効そうです。
*2:日本経済新聞「マスク氏のツイッター買収、競合SNSにユーザー流出」
*3:とはいえ相手によりけりです。あからさまに聞きたくないという態度を示す人もいます。お行儀よく聞いてくれるけれど何も理解してない人もいます。数回やってみて、上手くないようであれば方針を変えてもいいと思います。
*4:以下の記事などを参考にしました。『現場起点のアジャイル開発でビルドトラップを避け、組織のカルチャーにより「熱狂」を届ける【デブサミ2021】』『最強の開発手法！？デュアルトラックアジャイルをエンジニア向けに解説』『デュアルトラックアジャイル× Agile Testingから 見えてきたQAのミライ』
*5:2020年を最後に、日本での開催予定はないようです。オンラインだと難しいのかな……。
*6:ヌーラボの中村さんの記事もおすすめです 。
- 安井 力（やすい・つとむ） @yattom / yattom
- 通称やっとむ。合同会社やっとむ屋代表 。アジャイルコーチとして10年以上、開発の現場をプロセス面と技術面から支援している。ワークショップの設計と提供、特にゲームを用いた気づきや学びの工夫を凝らしている。著書・訳書に（共訳）、『テスト駆動Python』（監修）など。ゲームは『心理的安全性ゲーム 』『宝探しアジャイルゲーム』『チームで勝て！』などを提供する。
他、『アジャイルな見積りと計画づくり』『スクラム現場ガイド スクラムを始めてみたけどうまくいかない時に読む本』（ともにマイナビ出版）など、アジャイルやスクラムに関する著書、訳書も多数。
ブログ：やっとむでぽん
