開発チームの時間を無駄にしない。それはプロダクト開発における重要課題である
もっとやれる。開発チームのポテンシャルを十分に引き出しきれていない。むしろ、彼らのキャパシティを浪費させるようなことばかりを日常的に強いてしまっている――これは、ソフトウェアプロダクトの開発チームに関して私が常に感じている問題意識です。
開発チームのキャパシティは有限です。そのキャパシティは、プロダクトが提供する価値の総量を維持・拡大するためにこそ割り当てられるべきで、無駄に浪費されるべきではありません。開発チームやそのメンバーが、価値あるソフトウェア開発に費やせる時間、集中できる時間をどれだけ確保できるか。それは、優先度の高いマネジメント課題と言っていいでしょう。
ここでは、プロダクト開発を非効率にする代表的な6つの問題について取り上げました。個々の問題に対する解決策については明確に述べていませんが、議論の出発点となるポイントをそれぞれ列挙しています。
1. 無秩序に投げ込まれる見積り依頼
これは、頻発する突発的な見積り依頼に開発チームが時間を奪われ、開発業務に集中するための時間を十分に割けなくなるケースです。
「何を作るのか」を考える役割と、「どう作るのか」を考える役割が明確に分離している組織では、前者から後者に対する「依頼」という形で見積りが行われます。見積りを行う後者側はもちろん開発チームであり、それを依頼する前者側は企画職も含むビジネス担当者です。このやり方には、問題点があります。計画への「割り込み」と「繰り返し」です。
依頼方式の見積りプロセスは、ビジネス担当者が開発チームに声をかけるところから始まります。その上で、ミーティングを開いてビジネス担当者が「何を作るのか」を説明し、開発者からの質問に答える場が持たれます。「どう作るのか」についての簡単な議論もあるでしょう。開発チームは、ここで話し合われた内容を持ち帰り、見積りを作成し、後日、その結果をビジネス担当者に提出します。
このプロセス自体が、開発チームにとって「割り込み」となります。開発チームは、仕掛中の開発業務を進めながら、ビジネス担当者による任意のタイミングで突発的に開始される見積りプロセスに対応することになるからです。
開発チームにとっては、見積りを定期的なスケジュールで対応できれば計画を立てやすくなるはずです。「毎週月曜に見積り依頼を受け付け、金曜に結果を提出します」「今週は既に予定がいっぱいで、これ以上の見積りをお受けできません」というように。しかし、ビジネス担当者から指定される見積り期限はいつも切迫していて、依頼を随時受け付け、提出するしかありません。
見積り提出後に「何を作るか」に変更が入り再見積りとなる、といったことが繰り返されることもめずらしくありません。それに、依頼元となるビジネス担当が1人（あるいは1チーム）とも限らず、開発チームは並行していくつもの見積り依頼を抱えることもあります。
このような突発的な見積り依頼が頻繁に発生している状況で、開発チームは仕掛中の開発案件の期日、品質を保つための時間を確保することができなくなっていきます。この状況が続けば、見積り時間をあらかじめ確保しておくために、メイン業務である開発に割く時間を小さく見積もって計画を立てざるを得なくなります。
このプロセスモデルでのビジネス担当と開発チームの関係は、プロダクト開発というより、受託開発に近いものです。両者のやり取りのうち、ビジネス担当を「営業担当」に読み替えてみると頷けるはず。しかし、プロダクト開発は、受託開発とは異なります。ビジネス担当と開発チームで、次のような問いについて議論してみることで、解決のいとぐちが見えてくるかもしれません。
ビジネス担当者から指定される見積り期限がいつも切迫しているのはなぜなのか
見積りプロセスは、ビジネス担当から開発チームへの依頼、つまりは「プッシュ型」で開始する方法でなければならないのか
再見積もりになりやすい背景は何なのか。見積りすべきタイミングは正しいのか
見積りの精度を不必要に求めすぎてはいないか
「何を作るのか」と「どう作るのか」を完全にフェーズ分けして考えることは本当に効率的なのか
2. 調整不能で巨大な開発スコープ
プロダクト開発では、「苦労してリリースした機能がユーザーにあまり使われなかった」なんてことがよくあります。時間をかけて作り上げたものであれば、なおさらがっかりしてしまいます。その失敗から学ぶことも大いにあるとは言え、使われないものを作るような時間の無駄遣いはできる限り避けたいところです。失敗することが分かっていれば、その時間を別の機能開発にあてることもできたはず。
そう考えてみると、開発スコープの大きな変更をいきなりリリースしてしまうのは、大きな博打のようなものに思えてきます。成功するか失敗するかなんて、実際にリリースしてみなければ分からないからです。事前に十分な調査や分析を行えば、多少の自信を持ってリリースすることはできますが、それが成功を保証してくれるわけではありません。
この「失敗するかもしれない」という不安や不確実性こそが、実は逆に、開発スコープを大きくしてしまう原動力にも思えます。不安であればあるほど、あらゆるシナリオを想定し、網羅的に機能を追加してしまう。それが人の性というものではないでしょうか。
開発スコープを大きくしてしまう要因は、他にもあります。「何を作るか」に対する承認プロセスです。承認プロセスが成熟していない組織では、その場が機能のレビュー会のようになってしまい、ステークホルダーによって、様々な指摘を受けることとなります。それを反映しようとするほど、開発範囲は広がり、開発難易度も上がってしまうのです。それに、優秀なレビュイーであれば、一度でレビューを通すために、レビューの場でのあらゆる指摘を想定し、自ら事前に網羅的な仕様・機能を用意するかもしれません。
このようにして合意形成に至った「何を作るか」の定義は、開発プロセスでのスコープ調整を困難にし、必要以上に時間を掛けた開発をチームに強いてしまいます。ここで、スコープ調整を困難にする要因は2つ考えられます。コミットメントとサンクコストです。
承認プロセスにおいて、提案者に対し、承認者が立場的に優位であるほど、そこでの合意形成は、提案者にとって強いコミットメントになります。その合意事項をあとから変更することへのハードルは、提案者にとって相当に高いものになるでしょう。
また、苦労して承認を経た「何を作るか」の定義は、時間が掛かった分だけ愛着を感じるものです。そして、労力に比例したサンクコストにもなってしまいます。それが、スコープ調整に対する心理的な抵抗となってしまうのです。
こうして開発に掛けた時間が無駄になるかもしれない範囲を広げてしまわないために、次の問いについて、関係者間で議論してみてはどうでしょうか。
既存の機能のうち、どれだけの機能がユーザーに使われているのか
リリースする度にユーザーの反応を計測して結果を評価しているか。リリースすること自体が、ゴールになっていないだろうか
リリースしようとする機能がユーザーに使われないかもしれないことに対し、過度に恐れていないだろうか。逆に、楽観視しすぎたり、自信を持ちすぎていないだろうか
「何を作るか」が決まるまでにどれほど時間がかかっているのか。それを把握できているか
承認プロセスは何にフォーカスして判断するものなのか。そもそも承認プロセスは必要なのか
3. チームのキャパシティを超えた開発
フェイラーデマンド（failure demand）という言葉があります。そもそも最初からやるべきことを怠ったり後回しにしたために発生してしまう作業の必要性を言います。ソフトウェア開発では、品質に十分な時間をかけずにリリースを急いだために障害が多発し、チームがその対応に追われるといったこともよく聞く話です。これも、フェイラーデマンドの1つです。
業務時間中にアラートが頻発すれば、その度に作業の手を止めてアラート対応にあたることになります。このような状況は、チームの貴重な時間だけでなく集中力も奪い去っていきます。それに加え、業務時間後や休暇中のアラートは、彼らのプライベートを破壊します。こんなことが続けば、チームは疲弊し、気力を失っていくことは明らかです。
このようなやり方は、たった一度のリリースを早めることと引き換えに、それ以降のリリースに必要な開発時間を削り取る行為でしかありません。チームのキャパシティを超えた開発はやめるべきだということです。もし思い当たるところがあるなら、次の問いについて話し合ってみても良いでしょう。
リリースする度にトラブルが発生していないだろうか
勤務時間中、勤務時間外、就寝時間中それぞれのアラート対応回数はどれくらいになっているだろうか
開発期間に対し、開発量が詰め込み過ぎになっていないだろうか。開発チームのキャパシティ（ベロシティ）を把握し、それを超えないように開発計画を立てられているだろうか
4. 仕掛中のアップデートへの急な差し込みや入れ替え
ソフトウェアプロダクトをアップデートするサイクルは、ますます高頻度になっています。定常的なアップデートを1週間や2週間単位とするプロダクトもめずらしくありません。そこでリリースされる変更を開発する期間も、それだけ短くなっていると言えます。
次回のアップデートに向け、僅かな時間で取り組んでいるイテレーション（スプリント）に対し、新たな要素を急に差し込んだり、内容を変更したりといったことが繰り返されてはいないでしょうか。ソフトウェア開発には変化に対するアジリティが必要だとは言え、仕掛中のイテレーションへの変更は、調整コストや手戻りによる影響が大き過ぎます。
どうしても急ぎで差し込まなければならないことや、明らかに間違っている内容を正すようなことは、もちろん発生するでしょう。それをイテレーションに取り込むことはやむを得ません。問題なのは、それが頻繁に発生している現状です。そこには、開発を非効率にする組織的な問題やプロセスの欠陥などが潜んでいると疑うべきでしょう。
計画変更がどの程度の頻度で発生しているのか
計画変更の内容にはどのようなタイプがあるのか。計画変更を発生させる回数が多いタイプはどれか
計画変更の発生源はどこか。計画変更を発生させる回数が多い発生源はいずれか
もっと早い段階で計画に組み込むことはできなかったのか。緊急で差し込んだり入れ替えたりすることになったのはなぜなのか
5. 自動化・仕組み化・形式知化の後まわし
新しい機能を検討する上での調査の一環として、プロダクトの利用状況などをログから集計することはよくあります。そのような調査を、開発業務で多忙な開発チームメンバーに度々依頼してはいないでしょうか。
これも、開発チームが時間を失う原因のひとつです。特に、開発チームメンバー個人に直接的に依頼されている場合、チームからはその状況が見えず、チーム内でのリソース管理上の問題にもなります。
もちろん、利用状況の調査は重要度の高い仕事です。問題は、そのような重要度が高く頻繁に実施されるような業務が、仕組み化されていないことです。このケースであれば、ログやデータなどの分析基盤を構築しておくことで、関係者は誰でも自分自身で調査を実施することが可能になります。
こういった利用状況の調査だけでなく、アプリケーションに関する質問・相談や、日々のオペレーションも含め、ソフトウェアシステムの運用業務は全般的に、仕組み化や自動化、形式知化が後回しにされがちです。どうしても、機能開発が優先されてしまい、開発リソースがそこに全振りされてしまうからです。
この優先順位付けは、短期的にみれば妥当に思えますが、長期的に見ると開発チームの時間を奪い去る最大の原因となりえます。また時間だけでなく、属人化、ミス、成果物の品質のばらつきの原因にも繋がります。ここで議論すべきは、次のようなものでしょう。
開発チームに対し、どのような相談や質問が問い合わされているか把握しているだろうか。同じような問い合せが繰り返されていないだろうか。それらは形式知化できないのだろうか
開発チームに対し、どのような調査が依頼されているか把握しているだろうか。同じような調査依頼が繰り返されていないだろうか。それらは仕組み化できないのだろうか
機能開発の要件には、それを運用するために必要となる仕組みが含まれているだろうか。機能開発と同様に、運用の仕組み化・自動化のための作業もプロダクトバックログに追加できないだろうか
6. ミーティングに依存し過ぎるコミュニケーション
複数の人が協力し合い、共通の目的を達成するためには、コミュニケーションは必須です。それが、個人での活動と、組織での活動の大きく異るところです。ここで注意すべきは、コミュニケーションはコストでもあるという点でしょう。非効率なコミュニケーションは、組織のパフォーマンスを大きく悪化させてしまいます。そして、最もコストが高いと思われるコミュニケーション手段が、ミーティングです。
ミーティングは、そこで話し合われる個々の議題と参加者との関係性の強弱に関わらず、参加者を時間的に拘束します。ある参加者は、1つめの議題に強く関わりがあり活発に発言するものの、2つめと3つめの議題は関係性が薄く、ただ聞いているだけになるかもしれません。3つの議題を持つ1時間のミーティングだとすると、その3分の2となる40分は時間を無駄にしていることになります。
またある参加者は、抱える仕事で手がいっぱいの状況かもしれません。そんな時は、ミーティングに参加しながらも手元のノートPCで内職のようにその仕事を進めてしまいます。しかし、ファシリテーターから名前を突然呼ばれ、意見を求められるかもしれません。進行中の会話にも耳を傾けておく必要があります。この参加者は、手元の仕事にもミーティングにも集中しきれないという、なんとも非効率な状況に陥ってしまいます。
ある人は、1人で仕事を進める中で集中力が高まり、フロー状態に入った状態でミーティングの開始時間を迎えるかもしれません。そのまま仕事を続けられたら、いつもの何倍もの効率や品質で仕事が進められそうですが、「ノッてきたからミーティングは欠席するよ」とはなかなか言えません。集中した状態の余韻を脳に感じつつも、しぶしぶとミーティングに参加します。ようやくミーティングが終わり、さて仕事を再開しよう、となっても既にフロー状態は解けています。まずは何をやっていたか、どう思考していたかを思い出すことから始まり……
そもそも、効率的で効果的なミーティングの運営には高いスキルを要します。その点についてここで深堀りはしませんが、コミュニケーション手段を、運営難易度が高く、参加者を時間的に拘束するミーティングに依存しすぎるのは見直すべきではないでしょうか。ここで議論すべきは、次のような点でしょう。
組織や個人がミーティングに割いている時間はどれぐらいか。それは多いだろうか、少ないだろうか。どれぐらいの時間内であれば適切であると言えるのだろうか
普段行われているミーティングは、コミュニケーション手段として最適だろうか。その他の手段、例えばチャットやメール、ドキュメントの共有などに変えられないだろうか
ミーティングは効率的かつ効果的に運営されているだろうか。そもそも、どういうやり方が効率的で効果的だと言えるのだろうか
1日の中でのミーティングの時間割は、開発チームメンバーが作業にあてられる時間を細切れにして集中力を奪うような配置になっていないだろうか
最後に
繰り返しになりますが、開発チームの時間は有限です。開発チームに対し効率化を求める一方で、日常的に行われる組織に根付いた習慣やプロセス、価値観が、彼らの貴重な時間を無自覚に奪ってはいないでしょうか。ここではそういった問題を6つだけ取り上げましたが、この手の問題は他にもいくつも思いつきます。
開発チームやそのメンバーの時間を浪費させず、価値あるソフトウェア開発に費やせる時間、集中できる時間を確保する。それは、プロダクトマネジメントやエンジニアリングマネジメントにおいて、優先度の高い課題であると言えるのではないでしょうか。
この記事が気に入ったらサポートをしてみませんか？