Zenn
🗓️

わからないに立ち向かうプロジェクト運用、計画

2022/04/17に公開
マネジメント
プロジェクト
アジャイル
idea

はじめに

プロジェクトの計画、運用ってほんと難しいですよね。なんでスケジュール立てられないんだろう、なんで予定通りに進まないんだろうというのは、多くの人が抱えている悩みだと思います。私たちのチームでも同じような悩みを抱えています。その原因分析・振り返りの一環として、エンジニアリング組織論への招待　～不確実性に向き合う思考と組織のリファクタリングを参考にプロジェクト計画・運用に関する向き合い方を記事にまとめました。
管理者、担当者問わず、プロジェクトがうまく回らず悩んでいる人のお役に建てれば幸いです

プロジェクト運用は、わからないへの対処が大事

うまくいかないプロジェクトの悩み例

例えば私の経験したプロジェクト計画・運用の悩みについては、以下のようなものがあります。

  • ケース1: プロジェクトが開始できない！
    計画が中々決まらない、大線表を引きたいんだけど、開発タスクまで落ちないと見積も出せないから規模感がわからない。
    大線表を引いたはいいけど、要件が中々詰まらず開発が中々開始できない。

  • ケース2: プロジェクト開発が思ったように進まない！
    スケジュールは引いたのに、全然予定通りに進まない！
    開発タスクが細かすぎて、何やってるかわからない！

  • ケース3: プロジェクト計画の見直しができない！
    え、バグが多くてリリースに間に合わない？もう約束しちゃってるから無理だよ。。
    え、設計していた部分が予定通り出来ず、思ったより難易度が高くて進捗が上がらない？そんなこと今更言われても。。。
    え、追加作業が必要になった？そんなバッファないよ。。。

上記ケースは、少し乱暴にまとめてしまうとわからないことへの対処がうまくできていなかったということが言えるかと思います。

ケース1については、最初にやるべきことがわからないので、規模感や要件詰めの仕方がわからない状態。
ケース2については、現状の把握の仕方がわからない状態。
ケース3については、わからないことをそのままにして進めてしまい、後になって詰んでしまった状態です。

プロジェクトをうまく進めるには、「わからない」を「わかる」にすることが重要

エンジニアリング組織論への招待では、エンジニアリングの説明で以下のように記載しています。

つまり、「曖昧さ」を減らし、「具体性・明確さ」を増やす行為が「エンジニアリングとは何か」という答えでもあるのです (初版 P.11より)

プロジェクト計画も同様で、不確実性のコーンという図では、プロジェクトが進むほど不確実性が減っていくことを説明しています。

(図はプロジェクトの本質とはなにかより引用)

曖昧さを減らし具体的にすること、わからない状態をわかるようにすることが大事となります。
この記事でも、どのように不確実性を減らすか？わからないことをわかるようにするかをまとめていきます。

わからないに立ち向かうプロジェクト運用

ここでは、わからない状態をわかるに持っていくためのプロジェクト運用に関する話をしていきます。

わかるようにするための仮説と検証: PDCAサイクル

不確定要素の多い状況でわからないことをわかるようにするためには、仮説を立ててその検証をしていく必要があります。
その検証プロセスといえば、PDCAサイクルです。

  1. 仮説を立て (Plan)
  2. 実行し、 (Do)
  3. 検証し、(Check)
  4. 次の仮説を立てるための行動に移す (Action)
  5. 1に戻る

PDCAサイクルをタスクベースで作業を進めるプロジェクト運用に当てはまると、以下のようになると思います。

  1. まずはプロジェクト計画を立て (Plan)
  2. その実現に必要なタスクを実施し、 (Do)
  3. タスクの進捗と成果物を管理し、 (Check)
  4. 状況を元に、計画の見直しやタスクの細分化を行う (Action)
  5. 1に戻る

仮説としてのタスク作成、結果の検証、結果を元にしたタスクの繰り返しです。
PDCAサイクルを回す上では、特に「なにが仮説なのか」、そして「どのように検証できるのか」が重要です。
プロジェクト運用も同じく、計画を立てることと、その計画のうまくいっている点、いっていない点を検証していくことが重要となります。

わからないを検証し、わかるを目指すアジャイル

この計画と検証を繰り返すサイクルは、アジャイル開発がイテレーションでやりたいことと同じだと思います。
イテレーションとは、以下のLike this!の図のように、少しずつ動くものを作り上げていき、その内容に対するフィードバックを得ながら開発を進めていくサイクルのことを言います。

(https://www.ankr.design/designtips/making-sense-of-mvp より引用)

イテレーションで動くものを意識しているのは、動かないものでは求めている方向性かどうかが評価できないからです。これは、PDCAの話で出た「どのように検証できるのか」の部分に近いと思います。イテレーションは、本当に欲しいものがわからない状態のソフトウェア開発を、小さなリリースにより検証し、欲しいものがわかる状態にするサイクルと言えると思います。

アジャイル開発プロセスにおけるイテレーションは、ソフトウェアリリースとユーザーからのフィードバックの繰り返しになります。リリースまで到達できています。プロジェクトだとリリースまでいっている状態は大体成功しているようにも見えます。では、この記事で考えたいプロジェクトがうまく回らないことにはアジャイルは活かせないのでしょうか？私は活かせるところがあると思います。

イテレーションを実施しているアジャイル開発の根底にあるのは、アジャイル開発宣言です。
ここで大事にしているのは個人と対話、動くソフトウェア(検証可能な成果物)、顧客との協調、変化への対応です。それらの根底にあるのは、潜在的にある顧客の求めるものをわからない状態からわかるようにするために、機敏に対応していこうというものだと思います。
タスクベースのプロジェクト計画・運用に対しても、個人との対話を尊重し、調査タスクなら検証可能な成果物を求めて次のタスクブレークダウンに繋げ、顧客と結果を共有しあい、その検証から見えた作業状況の変化や新しいタスクの登場といった変化への対応していく必要があります。
わからないものが多いプロジェクト運用にこそ、アジャイルな姿勢が重要ではないかと思います。

わかる状態に向かうサイクルを回すための、情報の透明性

プロジェクトをアジャイルに運用していくには、プロジェクト全体の情報の透明性が大事となります。ここでは管理者と担当者の2つの立場に分け、双方の情報開示の意味について記載していきます。

管理者→担当者の情報開示の意味: 目的・ゴールを合わせる

大抵のプロジェクトは、不確定要素のある中で開発をはじめます。その不確定要素を埋めるためには、担当者が適宜調査タスクをこなして情報を集めてくる必要があります。
その際には、まず管理者と担当者がプロジェクトでやりたいことの目的やタスクのゴールを合わせる必要があります。ゴールがあっていないと成果物が合いませんし、なにより目的があってないと、調査で出てきた新しい要素に対応できません。これでは効果的な調査をすることは難しいでしょう。
その目的を合わせるためには、プロジェクトとして何がしたいのかの情報を正しく共有し、その詳細をタスクを通して明らかにしていく必要があります。

アジャイル開発で使われるインセプションデッキは目的意識を合わせる情報開示のいい例です。プロジェクト全体の方向性や目的を明確にして、進むべき指針を示しています。


(https://agilewarrior.wordpress.com/2010/11/06/the-agile-inception-deck/ の中の1枚を引用。他は元リンクを参照ください)

もしかしたらそんな調査作業ないよ、必要なタスクはわかっているよというプロジェクトをお持ちの管理者もいるかもしれません。そういった場合でも、その認識に差異がないかを確認するため、わかっているタスクの可視化を行い、同じく担当者が誰でも全容を把握できる状態にする必要があると思います。
作業を円滑に進め、変化に対応するには、このタスクは何をするためのものなのかの目的を合わせ、正しく期待されたタスクをこなせるよう情報を開示していくことが重要となります。

担当者→依頼者の情報開示の意味: 正しい成果の把握

情報開示は、担当者側から依頼者に向けても重要な要素となります。

やることのタスク化ができると、そこからタスクに対して見積もりによる作業予測を行い、日々の作業実績を可視化をして行きます。
アジャイル開発のスプリント計画では、この作業実績を元に、スプリント毎のタスク消化量(ベロシティ)を決め、どのくらいのタスクが消化できそうかを見ていきます。チームの作業予測と実績から、徐々に精度の高い実体にあった作業計画を行うことが出来るようになっていきます。(見積もり手法も多数ありますが、ここでは省略します)
この予測・実績を正しく行うためには、担当者からの正しく情報開示が必要です。

正しい成果を把握するためには、仕組みや環境づくりが大事

環境によっては担当者が正しく報告しなくなるケースが存在します。
例えばこの見積もりを出した時点で達成しなければいけないノルマや約束事として扱い、担当者に責務を押し付けた結果、担当者は自分を守るために虚偽の見積もりや報告を行うようになってしまうかもしれません。

経済学や政治学の中では、このような担当者が自身の利益になることを優先する状況をエージェンシー・スラックと呼び、そのような状態をインセンティブや監視体制等で回避するプリンシパル＝エージェント理論というものがあるそうです。

プロジェクト運用でも、担当者にとって正しい報告をすることがデメリットとならない仕組みや、担当者が何をやっているかわからない状態を作らないための環境づくりといった対策が大事となってきます。

わからないに立ち向かうプロジェクト計画

前述のように、プロジェクト運用のサイクルを回す中で徐々に不確定要素を潰して計画を更新していく必要があります。しかし、現実ではまずスケジュールの大枠が引かれ、期限が決まっていくのが通常だと思います。
なので、ここでは、わからない状態をわかるに持っていくためのプロジェクト計画に関する話をしていきます。

わからない状態をバッファとして計画に取り入れる

計画を行う際には、プロジェクト開始時点でわからない状態が多いことを見越しておく必要があります。最初の計画で全てを確定してしまうのではなく、不確定要素が確定した後に、計画のアップデートができる状態にしておきます。
例えばCCPMという管理手法があります。必要タスク1つ1つに対しては作業のバッファを持たせずに計画を立て、プロジェクト全体のバッファを確保しておく手法です。

(CCPMの基本をわかりやすく解説！実施のポイントとは？より引用)

最初はプロジェクトバッファを多くとっておき、プロジェクトのわからない状態がわかるようになるにつれ、バッファの部分を切り崩してタスク化していきます。そうすることで徐々に計画が精密になっていくというアプローチとなります。こういった手法を取り入れつつ、不確実なものは不確実であることを理解した上で計画を立てる必要があります。

バッファが足りなくなったらトレードオフをしながら調整

計画段階でバッファを取って作業していたが、作業を進めるとバッファを超えるような規模のタスクが必要になることがあります。その場合は、期間、スコープ、品質など何かを犠牲にして調整する必要があります。
全てを満たした調整方法はほぼ存在しないといってもいいでしょう。こんなサイト、みなさま見たことあると思います。

アジャイル開発では、トレードオフスライダーを用いて、プロジェクトの中でなにがより優先すべきかを定義し、調整の際に何を犠牲にするかの指針を作る工夫をしています。

(https://agilewarrior.wordpress.com/2010/11/06/the-agile-inception-deck/ より引用)

わからない状態を早く無くすための計画づくり

トレードオフについて話をしましたが、それが出来るのは、早めの状況把握があるからこそです。ギリギリになってしまっては調整するチャンスもなくなってしまいます。顧客からしても、いつまでも不確定なままいつ完成するかわからない計画を進められ、土壇場で無理でしたと言われても納得いかないでしょう。
そうならないためにも、早くプロジェクトの中でわからない状態のものを解決していく工夫も必要です。わからないことが多い作業ほど最初に取り組み、できるだけ早くわかる状態が多い状況を作るよう計画を立てる必要があります。

わからないを明確にするPoC(Proof of Concept)

不確定要素を早く潰す手段として、PoC(Proof of Concept)というものがあります。実際にやりたいことの試作開発をして、その結果を元にやりたいことと合致しているかの検証をする手法です。このPoCを通して、やりたいことの具体像を掴み、具体的な計画に落とし込むことが出来ます。

PoCを実施する上で気を付けないといけないのが、PoCでうまく行くと証明できた成果物は、そのままリリースで利用できるかどうか限らないことです。私自身、PoCで作った成果物が、気付いたらそのままリリースされるような計画になり、結果リリースの品質には耐えられずにかえって開発期間が延びてしまったなんていう経験もあります。
PoCの目的は小さく、素早く検証をすることであるため、ユーザーに利用してもらう目的にもっていくためには、改めてどんなタスクが必要となるのか評価することが大事です。(もちろんその結果PoCで作ったものがそのまま利用出来ることもあります。)

このような、プロジェクトの内容を具体的にし、それに合わせて計画の更新をかけていく取り組みを取り入れることも重要です。

さいごに

プロジェクト運用・計画について色々と記載してきました。正直言うは易く行うは難しなところも多いと思います。それでも一つ一つ出来ることから改善して、プロジェクトがうまく回るよう努めていくしかないと思います。
銀の弾丸はないので、わからないことを泥臭くでも一個づつ潰してプロジェクトの可視化に努めていくことが、プロジェクト運用の中でも一番の近道だと思います。

参考

記事全体の参考:
エンジニアリング組織論への招待　～不確実性に向き合う思考と組織のリファクタリング

各参照リンク:
プロジェクトの本質とはなにか
アジャイル開発宣言
CCPMの基本をわかりやすく解説！実施のポイントとは？
fastgood.cheap
The Agile Warrior/The Agile Inception Deck
NEXTSCAPE blog/インセプションデッキ
PoCとは？意味・やり方・ポイント・事例10選

Discussion