はじめに
組織の中には複数のメンバーや部署が関わりながら進められる「プロジェクト形式」の仕事が多く存在する。その推進役であるマネージャーが頭を悩ませるのが、トラブル発生による「スケジュール遅れ」ではないだろうか。定期的にミーティングを行い、進捗状況を確認してきたにも関わらず、プロジェクトが山場を迎えるタイミングで次々と発覚する問題。こうした問題の予兆をできる限り早い段階で察知し、発生を未然に防ぐためにはどうすればいいのだろうか。
ProductZine Day 2024 Winter（2024年1月30日開催）に登壇した、NCDC株式会社プロダクトマネージャー／シニアエンジニアの武方順平氏は、「プロダクト開発のトラブルを予防するために ～どうして「大丈夫です」と報告されるのにスケジュールは遅れるのか～」と題したセッションで、トラブルの早期発見と予防に向けた施策を紹介した。この施策は主に、プロジェクトメンバー間の「コミュニケーション」における課題にフォーカスを当てたものだ。
「炎上」を避けるには「リスク」への早期対応が不可欠
武方氏は、フルスタックエンジニアとして、Webアプリ、スマホアプリの開発経験を積んだ後、現在は自社プロダクトの立ち上げに関わっている。マネージャーとして、多くのメンバーが関わるプロダクト開発を推進する立場にある。同氏はまず、プロダクト開発におけるバッドケースを示した。
ある日の進捗会議。マネージャーがメンバーに「進捗どうですか？」と尋ねる。それに対してメンバーは「大丈夫です」と答える。これを聞いたマネージャーは「スケジュールも今のところ予定どおりだし、メンバーも問題ないと言っているので大丈夫そうだ」と判断する。
さて、このプロジェクトは本当に「大丈夫」なのだろうか。
数週間後。プロジェクトには少しずつ不穏な気配が漂い始める。メンバーからは「このままだとリリース予定日に間に合わなさそうです」「スコープが厳しいので、この機能は入りません」「リリース後に不具合の報告が多数出てきています」といった声が上がる。
タイミングを合わせるように、経営陣やステークホルダーからのプレッシャーも強くなる。「リリース日は厳守してください」「プロジェクトの状況を把握していないって、あなたの仕事は何ですか」といった厳しい指摘が相次ぐ。刻々と状況が悪化する中、何とかプロジェクトの立て直しを図ろうとするほど、メンバーは疲弊していく。「それぞれがタスク消化に精いっぱいで、チームの空気悪くないですか」「いつまでこういう状況が続くのですか」「つらいので、プロジェクトやめさせてください」といった不満の声が日に日に大きくなり、チームとしての形を保つこともおぼつかなくなってくる。いわゆる「炎上」の状態である。
「ここまでひどい状況はなくても、自分が関わるプロジェクトを振り返って『部分的には当てはまる』と感じる人も多いのではないか」と武方氏は言う。このセッションでは、メンバーとのコミュニケーションを軸にして「不安」を共有し、リスクを早期に察知して、対処できるようにする方法を考えたいとした。
プロジェクトが本当に「大丈夫」なのか、現場の声を聞くツール
PJ Insightは従来型のプロジェクト管理手法では把握が難しかった「プロジェクトメンバーの本音や不安」を定期的に収集して、PMやPMOが現場の状況を把握しやすいように可視化します。PJに潜むリスクの早期察知に課題を感じられている方は、ぜひPJ Insight（公式サイト）をお試し下さい。無料トライアルも実施中です。
「計画の難しさ」にマネージャーはどう立ち向かう？
プロダクト開発における「難しさ」には、大きく3つの側面があると武方氏は言う。1つ目は、プロダクトが顧客と市場に受け入れられるために何が必要かを考える「企画の難しさ」。2つ目は、目的とする『価値』を一定以上の品質で期日までに届けられるかという「開発の難しさ」。3つ目は、正しい計画を立てて遂行する「計画の難しさ」である。
本セッションのテーマである「計画の難しさ」は、市場のニーズが変わったり、重要なチームメンバーが急に離脱したりといった問題をきっかけに「予定したスケジュールまでに開発が完了しない」といった『トラブル』として具体化する。武方氏は「プロダクト開発には『不確実性』がつきもの。それによって生まれる問題への対応が後手に回れば回るほど、計画の狂いが大きくなっていく」と指摘した。問題への対応を後回しにせず、計画への影響を最小限に抑える対応を行う上で必要なのが「リスクマネジメント」の考え方だ。
武方氏は、このセッションでは「リスク」を「計画を阻害する『起こり得る』事柄」、「問題」を「計画を阻害する『すでに発生した』事柄」と定義した。この定義に基づけば、まだ具体的な形として現れていないトラブルの種が「リスク」であり、「リスク」が顕在化したものが「問題」ということになる。
「リスクをマネジメントするために必要なことは大きく2つ。一つは『潜んでいるリスクを洗い出す』こと。もう一つは『リスクが顕在化した時の影響を考えて、行うべき対応を考える』ことだ」（武方氏）
システム開発の領域における、主な「リスク」要因としては、
- スケジュールの欠陥
- 要求の増大
- 人員の離脱
- 仕様の崩壊
- 生産性の低迷
といったものが知られている。しかし、こうしたリスクのすべてに同じように備えておくことは、リソースの制限などから難しい。その場合、必然的に「優先度の高いリスク」から順に対応していくことになる。その際、判断基準の一つとして「顕在化する可能性が高いリスク」への対応を優先するという方針が考えられる。そのためには「注目すべきリスク」を見つけ出し、その状況を詳細にモニタリングする必要がある。
「顕在化しそうなリスク」を見つけ出す方法
では「顕在化しそうなリスク」は、どうすれば見つけ出せるのだろうか。前出の「プロジェクト炎上の例」を改めて見てみよう。
マネージャーが進捗会議でメンバーに「進捗どうですか？」と訪ねた際、メンバーは言葉では「大丈夫です」と回答していながら、実は心の中で「リスク」の予兆を感じ取っていた可能性がある。数週間後に状況を確認したとき、「リリースに間に合わなさそう」と話したメンバーは、その前の段階で「仕様確認の手戻りが多いな」あるいは「この感じで進めて大丈夫なのだろうか」といった不安を抱えていた可能性がある。また「リリース後に不具合報告が多数出ている」と発言したメンバーは「今のタスクには影響が出ていないが、コードの品質が下がっている気がする」と感じていたかもしれない。
そのほかにも「会議ばかりで時間がとれない」「見積もりが間違っていたかもしれない」「この機能、優先度が低い気がする」「仕様の理解があいまいになっている気がする」「ステークホルダーと話すと手戻りがあるから気が進まない」「このタスク、自分には荷が重いけれど他の人は大変そうだし自分でやらなければ」などなど、「進捗どうですか？」の回答にはならないが、プロジェクトに対するあいまいな「不安」がメンバーの中に芽生えていた可能性がある。
「メンバーはそれぞれの役割を果たす中で、ささいな違和感や不安を覚えることがある。これは『プロジェクトのリスク』を『不安』という形で敏感に感じ取っていると考えられる」（武方氏）
こうした違和感や不安を「顕在化しそうなリスク」「すでに部分的に顕在化しているリスク」と捉えるべきだというわけだ。
マネージャーであれば「分かっているなら先に言ってよ」と思うかもしれない。しかし、ここで問題にすべきは「メンバーが思っていた不安を『言わなかった』こと」ではなく「不安を『言えなかった』こと」あるいは「マネージャーとしてそれを聞き出せなかったこと」であると武方氏は指摘した。
メンバーの「不安」から顕在化前のリスクを察知するツール
PJ Insightは従来型のプロジェクト管理手法では把握が難しかった「プロジェクトメンバーの本音や不安」を定期的に収集して、PMやPMOが現場の状況を把握しやすいように可視化します。PJに潜むリスクの早期察知に課題を感じられている方は、ぜひPJ Insight（公式サイト）をお試し下さい。無料トライアルも実施中です。
「不安」の表明には心理的なストレスを伴う
特に仕事の場において、あいまいな違和感や不安を表明する行為は、多くの人にとって心理的なストレスとなる。「もしかしたら大丈夫かもしれない」「ただの考えすぎかもしれない」といった正常性バイアスが働くことで、表明のハードルはさらに高くなる。
組織行動学の研究者で「心理的安全性」という概念を提唱したエイミー・エドモンドソン教授は「心理的安全性を妨げる4要素」として、
- 無知だと思われる
- 無能だと思われる
- 邪魔をしていると思われる
- ネガティブだと思われる
を挙げている。例えば「仕様の理解があいまいになっている」という不安を伝えるのは、チームに対して無知だと取られる可能性がある。また「見積もりが間違っていたかもしれない」と表明するのは「自分の見積もり能力が低い」と思われる可能性がある。「機能の優先度が低いと感じる」という意見表明に対しては「チームのタスクを邪魔している」と感じるメンバーがいるかもしれない。また自分の限界を伝えて、他の人に頼る姿勢は「ネガティブ」な印象を持たれるのではないかという懸念がある。
メンバーが何となく感じていた違和感や不安を表明するのをためらった背景には、こうした要素が影響していたと考えられるのではないだろうか。心理的なハードルを乗り越えて、違和感や不安を表明できる雰囲気をチーム内に作っていくことが、優先度の高いリスクを早期発見することにつながる。
「仕組み化」を通じて不安を共有しやすい組織を作る
では、チーム内の雰囲気あるいは組織の文化を変えるためにマネージャーには何ができるのか。武方氏は下図のようなイメージを浸透させることが1つの方法であるとした。
この図では「感じている不安をマネージャーに伝えること」つまり、個々のメンバーが「心理的なハードルを乗り越えること」で、プロジェクトが改善し、自分の不安も減るということを表している。この認識は、メンバーが不安を表明するための動機付けになる。ただ、それですべてのチームメンバーが不安を口にできるようになるかといえば、話はそう簡単ではない。個々の性格などによって、やはり難しいというケースもある。
「できない可能性があることをメンバー任せにするのは得策ではない。そこで不安を共有する『仕組み』を作って習慣化することで、各メンバーの意志に依存する割合を下げる」（武方氏）
「仕組み」のアイデアとしては、各メンバーとの個別面談を比較的短いスパンで定期的に行い、不安を共有してもらいやすい関係性を作ることや、全体で不安を共有できるような「心理的安全性」の高い場を設けるといったことが考えられる。
各メンバーからチームに「本音」を伝えやすくするツール
PJ Insightは従来型のプロジェクト管理手法では把握が難しかった「プロジェクトメンバーの本音や不安」を定期的に収集して、PMやPMOが現場の状況を把握しやすいように可視化します。PJに潜むリスクの早期察知に課題を感じられている方は、ぜひPJ Insight（公式サイト）をお試し下さい。無料トライアルも実施中です。
NCDCにおける具体的な取り組み例
ここで、武方氏が現在勤務しているNCDCで実際に行われている、チーム内のコミュニケーションを「仕組み化」するための施策について紹介された。この取り組みが始まった当初、同社のメンバーは約30名で、同時に5～10ほどのプロジェクトが並行して動いている状況だったという。同社では毎週月曜日に「朝礼」と呼ばれる全社ミーティングを通じて、さまざまな情報共有を行っていた。
この朝礼では毎回、Googleフォームを用いたシンプルなアンケートを実施した。具体的な進め方としては、
- 自分が抱えるプロジェクトに対する不安度を5段階評価で回答してもらう
- 朝礼中にリアルタイムで入力してもらい、集計された結果をみんなで確認する
- スコアが下がっている人や気になるコメントをしていた人に対して、直接どんなことが起きているのかを尋ねる
- その場で対応が必要かどうかを判断し、アクションを設定して改善につなげる
といった流れになる。
「アンケートを送っておいて後で回答してもらう方法も考えたが、それだと回答率を高めるのが難しいと判断した。また、結果に対する詳細なヒアリングが必要なため、朝礼の場でリアルタイムに回答してもらう形式とした。こうした取り組みが個別のプロジェクトで閉じてしまわないよう全社朝礼の場で行い、会社全体で取りこぼしが起こらないように考慮した」（武方氏）
このリアルタイムアンケートには、良い点と問題点の双方があった。
良かった点としては、特定のプロジェクトでリリースへの不安を早めに発見し、スコープやスケジュールなどを調整する場を設けられるようになったという。また自分だけではなく、他のメンバーがどんな不安を抱えているかを可視化できたことで、その解消に向けたアクションを取りやすくなった。不安を共有することがプロジェクトの改善につながることを全社共通の認識として得られたことも大きかったとする。
一方の問題点としては、全社朝礼の場であることが心理的安全性のハードルを上げてしまい、自分の不安を話すことに強いストレスを感じるメンバーも少なからずいたという。
「ファシリテーターは、ヒアリングを行う際に『どうしてそういう不安があるのか』と聞いてしまいがち。こういう聞き方をすると、その質問自体が圧力になる。そもそも、漠然とした不安に対する理由を説明すること自体が難しい」（武方氏）
また「社員の増加」も、この施策を難しくする一因となった。社員が増え、朝礼の規模が大きくなると、施策の実施に時間が掛かるようになる。その結果、決められた時間の中で「不安」の原因を深ぼりすることができなくなり、対応も表面的なものになりがちだったという。
問題点を改善し「組織文化」と「システム」の両輪でリスクを可視化
こうした状況を受けて、NCDCでは施策の改善を図った。
まず心理的なハードルを下げるために、不安について「全社朝礼で話す」形式をやめた。アンケート結果は全体では確認せず、プロジェクトごとにマネージャーがチェックし、必要に応じてメンバーに確認して状況をまとめ、その内容をしかるべきメンバーでのみ共有するようにした。
「回答率の低下が懸念されたが、これまでの取り組みですでに社員にはアンケートに回答する習慣ができていた。そのため、リアルタイムでの確認をやめても大きな回答率の低下は見られなかった」（武方氏）
また「問いかけの圧力」を低減するための取り組みとして、この施策の「目的」を共有することを徹底した。アンケートやそこから派生する質問は「プロジェクトのリスクを知って改善に生かす」ことが目的であり、ネガティブなコメントをしたところで、個人の批判や人事評価につながるものではないということを改めて説明するようにした。また問いかけるマネージャー側も「なぜ？」という形で「理由」を聞き出すのではなく、実際にどのような「事実」があったのかを聞くよう心がけたという。
さらに「規模の拡大で施策に時間がかかる」という問題については、アンケートを全社ではなくプロジェクトごとに実施して取りまとめるという形式に変えることで改善が図られた。
これらの改善が行われた後の流れは、
- プロジェクトごとにアンケートを採る。アンケートフォームが毎週メンバーに送信され、メンバーは各項目にスコアを付けて回答する
- 得られた回答を元に、チーム内でコミュニケーションを取る。主にマネージャーが中身を確認し、メンバーと会話をしてどのようなリスクがあるかを把握していく
- マネージャーはレポートを作成し、状況をステークホルダーへ共有する（これは、マネージャー自身にとってもプロジェクトの状況を整理するきっかけになる）
- ツールに、複数のプロジェクトを一覧して状況を確認できる機能を追加する（不安を共有しやすい社内文化を醸成することを意図）
となっており、現在も実施と改善が続けられている。
「プロダクト開発には多くのリスクが潜んでいる。そして、それらのリスクはメンバーが『不安』という形で早期に察知していることが多い。その不安を共有できれば、リスクに対して早期に対応でき、具体的なトラブルになるケースを減らしていける。NCDCでは、そうしたリスクマネジメントに向けて『不安を共有する文化の醸成』と、それを支える『システム』の両輪で対応していこうとしている」（武方氏）
なお同社では、自ら実践している『メンバーが感じている不安の可視化』をサポートするシステムを「PJ Insight」というプロダクトとして公開している。武方氏は「このツールが、皆さんのプロダクト開発を円滑にする一助になればと考えている。ぜひ利用して感想を聞かせてほしい」と述べてセッションを締めくくった。
マネージャー層から見えにくいPJメンバーの本音を可視化するツール
PJ Insightは従来型のプロジェクト管理手法では把握が難しかった「プロジェクトメンバーの本音や不安」を定期的に収集して、PMやPMOが現場の状況を把握しやすいように可視化します。PJに潜むリスクの早期察知に課題を感じられている方は、ぜひPJ Insight（公式サイト）をお試し下さい。無料トライアルも実施中です。
