はじめに
私が好きな江戸の小話的なものに、こういったものがあります。
江戸下町では、道向かいのそれぞれが軒先を掃くときに、道の真ん中よりもちょっと向こうまで掃くのがならわしだったそうです。両側の人がそれぞれ真ん中よりも向こうまで掃くので、道の真ん中が一番きれいになる、というお話です。
近年こうした「江戸しぐさ」のようなお話は、真偽のほどが定かではないとして、流布することに批判もあるようです。実際この話も正直事実かどうかは全くわかりません。
ただお互い完璧ではない他人同士が肩寄せ合って共に生きる知恵といいますか、プロジェクトへの参画姿勢について良い示唆を与えてくれる話だと思い、その前提で使っています。
実際私が関わる案件のキックオフでもお客様や関係者によくこの話をするのですが、「キックオフでの『道の真ん中の話』、他の現場でも最近してるんですよ」とお客様やパートナー様から言っていただけたことがありました。わかりやすいモチーフなので、皆さんに共感を得やすいのだと感じています。
今回ある コミュニティ で登壇機会をいただきました。登場人物が多い企業システム開発において、この江戸下町のようなプロジェクト運営が理想だと常々思っていて、それを実現するために私がプロジェクトに関わる際に心掛けていることを、「道の真ん中をきれいにするプロジェクトマネジメント」と称してお話しました。ありがたいことにTwitterでも反響をいただき、多くの方に共感を得られるお話なのだと感じた次第です。（本記事の最後に当日の動画アーカイブと発表資料は掲載してありますので、よろしければご覧ください。）
道の真ん中がきれいなチームにするための、10個の原則
今回はシステム開発にたずさわる方により広く知ってもらいたくて、この日の登壇で後半に話した「道の真ん中がきれいなチームになるための10原則」を記事にしました。
この「道の真ん中がきれいなチームになるための10原則」は、メンバーみんなが道の真ん中より向こうまで掃くがごとく、お互い自発的に補完して抜け漏れを防ぎ、高みを目指し互いを助けあい鼓舞できる、そんなイケてるチームに共通するポイントを、過去マネジメントコーチをやっていた頃に習得したコーチングのエッセンスを取り入れて、まとめてみました。
1．「異文化」を知り、受け入れる
2．「意思決定ルール」を明確にする
3．「見えないもの」を可視化する
4．「与党」を増やす
5．「変更」に備える
6．「のりしろ」を設計する
7．「約束」を尊重する
8．「問題」を前向きに解決する
9．「最悪」に備える
10．「目標」を明確化する
チームやプロジェクトがうまくいっていない時に、アジャイルやウォーターフォールと言った方法論の是非や個人の資質を言及することよりも、それ以前にチームとして機能するための行動指針や原理原則が整っていることこそが、大切だと思っています。
ただそうした原理原則が、精神論や抽象度が高い状態で終わることも残念です。良いこと言っているけど、具体的にどうすればよいのかと悩ませるのはもったいないわけです。またPMBOKなどの各種標準は、その網羅性を追求したがゆえに、それぞれのケースでテーラリングすることが前提なので、実際に自分のチームに適用するまで少し距離が遠いと感じざるを得ません。
具体的な行動に落としやすいものが必要だと思ったことも、こちらの作成動機にあります。（とはいえ、一部精神論的な箇所もありますが、実践的で多くの方にイメージしやすくなることは心掛けました。）
自分と同じ失敗や苦労をさせたくない。全部読むと結構なボリュームになるので、気になるところだけでも読んでみてください。
1．異文化を知り、受け入れる
1-1．異なる価値観や文化を持つ人たちとの協同活動であることを知る
ビジネスシーンにおけるシステム開発は、費用の決裁者から利用者、開発者、運用者など様々な人たちが関わります。複数の部署や企業をまたぐことも少なくありません。多くの違った立場の人が関わり、相互にコラボレーションしながら、全体としてハーモニーを奏でる必要があるわけです。
つまり異文化コミュニケーションが大前提で、言葉が違う・文化が違う人同士が一緒に仕事をする前提で構える必要があります。
1-2．自分から相手や前提知識を学ぶ努力をする
たとえばSIの現場において、ユーザー企業の方々に対して、若手SEが陥りがちな誤解がこちらです。
- 「情シス」の立ち位置や立場の強さはどの会社も同じだ
- 「情シス」は自社の業務とシステムのことを何でも知っている
- 「情シス」のメンバーはみんなエンジニアになりたかった人達だ
- 「情シス」のメンバーはみんなITの専門家だ
- 顧客担当者はシステム化の目的を100％理解しているはずだ
未経験だから知らなくて当然ではあるのですが、それを堂々と言うことがプロとしてふさわしいとは言えません。もし会社ごとに違うことが分かっているのならば、まずはお客様の組織や文化を知ることからはじめましょう。
たとえば海外旅行や海外留学に行くとしたら、出発前に現地の国の文化を調べたり、現地では現地の言葉で話そうと努力するのが通常ではないでしょうか？宗教やタブーなどは事前に調べておかないと、大変なことになりかねません。大袈裟に言えば実はシステム開発も同じぐらい異文化コミュニケーションを必要とするのですが、なぜかそれぞれが自分達の言葉、自分達の風習にこだわろうとしてしまうことが多く見受けられます。相手の使う言葉や文化を知り、相手がわかる言葉で話そうとする姿勢を改めて確認しましょう。
こういうと顧客に迎合するのかといったことを言う人もいますが、それは違います。相手が違う前提で、相手を知る努力をまず自分から行いましょうというのがメッセージです。
またそもそもとして、いくらエンジニアだからと言っても、システム取引/受発注に対するビジネスとしてのお約束事は、ある程度知っておくことも重要です。もちろん基本的なことだけでもまったくOKです。事前知識を持っているかどうかでお互いの第一印象は大きく異なります。
参考までに、システム開発にたずさわられる方なら最低限しっておきたい知識については、私が社内教育用にまとめたものをこちらで公開していますので、よろしければご活用ください。
1-3．勝手に他人に期待しすぎない
お客様も一つの会社ですので、J-SOXやISO、各種ポリシーなど無条件に守るべき制約があります。またお客様も当然組織の一員ですから、保身もするし社内の評価を気にするのは当たり前です。お客様も普通のサラリーマンです。お客様に幻想を抱かないようにしましょう。
また肩書や役職がついていると偉い、影響力があると勘違いしてしまうのは大変危険です。実際その肩書や役割がどういう意味を持つのかは、会社やその個人に依存するので注意しましょう。
また、「役職者だからその責任を果たすべく自発的に動いてくれて当たり前」と思うのはやめましょう。それはこちらの勝手な期待でしかありません。その方にやって欲しい役割があるならば、明確にリクエストし合意を得て、プロジェクト計画書や体制図に明文化しておくことが大切です。
1-4．自分と違う価値観を拒否しない
初めてのクライアントや初めてのパートナーとチームを組むときは誰しも不安になります。ただ良いシステム、良いプロダクトを作り、課題を解決したいというゴールはみんな同じはずです。まずはお互いが違うということを認識し、それを前提として相手を理解するところから始めましょう。
何が違うかを可視化するというアプローチも一つあります。キックオフやチーム結成初期のアトラクションとして、各自自分のカルチャーマップを作って発表し合うのも良いでしょう。
楽しみながら、お互いの価値観を理解することができます。
2．「意思決定ルール」を明確にする
2-1．意思決定ルールとは何か？
システム開発という不確実性の高い作業を複数人のチームでやっていれば、日々問題が発生します。問題解決には意思決定が必要になるので、この意思決定の生産性が低いチームは、自ずと問題解決のスピードが遅くなります。問題解決の生産性を高めるためにも、チームの意思決定の生産性を高めることが不可欠です。そのためにはチームにおける意思決定のルールを明確にしておくことが効果的です。もちろん単に決めるだけではなく、その後チームとして統一した行動が不可欠ですので、全員が納得した上で行動できるような意思決定の取り決めが必要なのです。
2-2．おすすめの意思決定ルール
チームで意思決定をするためのおすすめの方法は、以下の3ステップです。
- まずチームの意思決定者を決め、チーム全員で合意する。
- 以下のプロセスを合意する。
- メンバーは意思決定すべき項目について、全力で自分が最適だと思う案を提案する。
- 出し合った後は各アイデアに対して人気投票を取るなどチーム内で議論する。
- 最後は意思決定者が決める。
- 意思決定者が決めた案が正しい意思決定になるようにチーム全員が全力で行動する。
2-3．意思決定のアンチパターン
一度意思決定された案に対して、やっぱり違う案の方が良かったのにと愚痴ったり、結果に従わないのはNGです。
たとえば、みんなでいくランチをカレーかお蕎麦か意見が分かれたとします。皆はそれぞれいかにカレーや蕎麦を食べたいかをプレゼンします。結果、意思決定者はカレーを選択して、みんなでカレー屋さんに行きました。そして席をついて皆でオーダーを選んでいる際に、一人だけ「やっぱり私はお蕎麦が良かった」というのはなし、ということなんですね。
どれだけ自分はお蕎麦が食べたかったとしても、チームでカレー屋さんにいくと決めたら、カレーを食べるという選択が正解になるように動こうということなのです。つまりカレー屋さんに来た以上、カレーを食べることを全力で楽しむことが、このルールを受け入れるということになります。（意思決定した結果が正しくなるように行動する）
もちろん、一度下した意思決定を、意思決定者自身が変更することもOKです。やってみた結果、違うやり方を検討すべきであれば、それは皆も変更を提案すべきなのは間違いありません。
3．「見えないもの」を可視化する
3-1．人は目に見えないものを無意識に恐れる傾向があることを知る
人は元来目に見えないものを恐れる生き物です。少しテーマは異なりますが、昨今のDXブームを下支えたテーマとして、経営者層の「技術的負債」への恐れもあったはずです。ただでさえシステムという当事者以外には内部構造が見えにくいものを取り扱う仕事だからこそ、扱えるものはできるだけ可視化することが重要になります。
3-2．議事録/議事メモは必ずとる
言った「つもり」、合意した「つもり」、理解してもらっている「つもり」は、不確実性の高いシステムという対象を扱う上で厳禁です。原則、内部MTGも含めてメモを必ずとり、終わったらすぐに共有しましょう。こうした議事録/議事メモの意義が最大限に発揮されるのは、トラブルに陥った時です。何か困ったことが起こっても、平時からすべてを議事録に収め、ステークホルダーに確認するという習慣を継続さえしておくことで、あらゆるメンバーにとって心理的なよりどころができます。このよりどころを意図的に作っていくことが、大きなトラブルを未然に防ぐことに繋がります。
議事録や議事メモに関するノウハウは他の多くの文献に譲りますが、スピード感を大切にすること、良いサンプルに触れるのが一番です。良い議事録のサンプルをお探しなら、以下のnoteがおすすめです。
3-3．チケット管理システムを使う
多くの方には釈迦に説法かもしれませんが、ステークホルダーとの依頼事項の管理をメールやチャットだけでまかなうことは、埋もれるリスクも高く非効率でしかありません。可能な限りチケット管理システムを利用しましょう。ツールはRedmine/JiRA/Backlogなど何でも構いません。もし選定に迷うようなら、私は初心者にも使いやすくリーズナブルなBacklogをお薦めします。
チケットは誤解なく分かりやすく書くことも大切です。下記の資料が参考になるでしょう。
3-4．チャットやチケットには既読段階でリアクションする
コロナ禍以降、システム開発もリモートワークが増えました。リモートでプロジェクトを遂行する経験値も上がり、オンラインMTGへの抵抗もほぼなくなったといえます。ただ特にチャットや前述のチケット管理システムを中心としたテキストコミュニケーションに頼る部分が増えることで、やり取りが無機質になる不安は否めません。
「愛情の反対は無関心」だと言いますが、ちゃんと心の中では関心を払っているのに、それを表現していないばかりに仲間が不安を覚えることは非常にもったいない。こうした避けられる不安を払拭するためにも、関心を意図的に表現することをチームの当たり前にできると、チームの雰囲気はそれをしない時に比べて確実に良くなります。
具体的には、SlackやChatworkといったチャットツールにある「了解」「いいね！」といった「絵文字リアクション」機能や、チケット管理ツールのBacklogであれば「スター」機能を徹底的に活用しましょう。
「普段はノーリアクションで、何か特別な時にリアクションする」のではなく、「常にリアクションをして、特別な時はちゃんとコメントでリアクションする」というルールが効果的です。フルタイムではなくパートタイムで非同期に関わるメンバーが多いプロジェクトでは特に効果的です。
費用ゼロでチームの雰囲気を少しでも前向きに出来る施策があるとしたら、やらない理由はあるでしょうか？飲み会や1-1、ピアボーナス1などの取組みも効果的ですが、まだこうした文化形成が出来てないチームは、投資ゼロでやれるこの施策から始めることをお薦めします。
4．「与党」を増やす
4-1．プロジェクトにおける「与党」とはどういう存在か？
ここで言う「与党」とは、困難な状況であっても非難を覚悟で物事を前に進めざるを得ない当事者としての立場を指しています。単に外野からリスクだけを指摘したり批判だけをする存在ではなく、清濁を併せのみ現実と向き合いながら、何とかコトを前進させることが求められる存在のことです。（当然ですが、特定政党の支持不支持とは全く関係ありませんので念のため。）
プロジェクトには問題がつきものです。ただすべての問題をPMが一人称で対応することはできません。当事者意識をもって、問題に前向きかつ自発的に対応してくれる、そんな「与党」の一員として振る舞ってくれるメンバーやステークホルダーをどれだけ増やせるか？難しいプロジェクトであればあるほど、こうした取り組みが鍵を握ります。
4-2．所有感の原則を知る
人は、自分が所有感を持つ事柄については、問題が起こった時に自発的に解決に向けて動こうとします。逆に所有感のない事柄に対しては、問題が起こったとしても自発的に助けようとはなかなかしてくれません。例えていうならば、自分の子供が病気になったときと他人の子供が病気になったときの振る舞い方の違いと言えば、理解しやすいかもしれません。
4-3．特別なイベントへのアサイン
プロジェクトには、大きな節目となったり、重要な方針を決定する大事な会議があります。そうしたカギとなる会議には、所有感を持たせたいメンバーは必ずアサインしましょう。
特にキックオフの人選には最大限こだわりましょう。
あと、現場ユーザーを広く巻き込む必要がある場合は、現場部門からシステム開発に関わるメンバーをアサインしてもらうことがあります。ただこのメンバーのメンタリティが重要なんですよね。現場の利益代表者として、現場の主張だけをするような形になってはまったく逆効果です。システムを作ることの難しさ厳しさも含めて共感してもらえるように、カッコつけずに困っていることも含めて相談するようにした方が、いいアイデアが出たり、運用面で協力してくれることが経験上多かったですね。
また違う視点で言えば、業務のヒアリングにエンジニアのメンバーにも同席してもらうことは効果的です。経験上、エンジニアが直接ユーザーの顔を知っているかどうかで、業務への踏み込み方というか、現場の業務サービスレベルに対する所有感が大きく変わってくることを実感しています。可能な限り時間を確保してもらうようにしましょう。
4-4．会社組織や契約形態という垣根をとりはらう
今の日本の業界構造上、ある一定規模のシステムを完全に社員だけで全うするということは、恐らくほとんどないと言ってよいでしょう。
商用システム開発プロジェクトに関わる限り、ある一定範囲で社外パートナーに協力を得ることが一般的です。その場合、正社員とパートナーさんをどう扱うか問題になるわけですが、当然限られた時間と環境で最大の生産性を上げて頂くことが、発注側にとって得たい状態であることは間違いありません。
そう考えると、原則発注者側は道徳倫理上は勿論のこと、経済合理性の観点でも、横柄な態度を取ったりして心理的安全性を阻害するようなチームの空気を作ることは、全く得策ではありません。
コミュニケーションの黄金律は「自分がそうしてもらいたいように振る舞う」ことにあります。もし性悪説にならざるを得ないとしたら、パートナー選定時点で間違っていると考えたほうが良いでしょう。
4-5．コミュニケーションの回数と頻度を増やす
特にプロジェクトの外部の人の場合、せっかく与党として巻き込んだ人でも、プロジェクトとの接点や情報が希薄だと、次第に気持ちは離れていきます。それを避ける意味でも、ステアリングコミティ（上位層向け）やプロジェクト報告会（現場選抜のアンバサダーの方向け）等の定例会議を有効に活用することが大切です。また会議が難しい場合は、プロジェクトレポートなどを一定頻度でこちらから送付することも効果的です。
プロジェクトがうまくいっている時は継続できている会議も、状況が悪い時には多忙を言い訳に体裁の悪さからこうした会議体やレポートは滞りがちですが、これは逆効果です。うまくいかない時こそ、与党として巻き込んでいる意味が発揮されます。状況が悪いのを誰かのせいにしがちな構造を、「問題」VS「プロジェクト」の構造にするためにも、ステアリングコミティや報告レポートはできるだけ継続させましょう。
5．「変更」に備える
5-1．システムの要件とは「ある瞬間のスナップショット」でしかないことを理解する
システム開発とは、要望を整理し要求にまとめ、要件を決め仕様に落とし込む作業が必ず発生します。このプロセスは1で触れたように前提知識が異なる人同士が合意を得ていく必要があったり、抽象度の高い情報操作が必要になってくることなども含め、非常に経験が求められ一般的に難易度が高いプロセスです。
そうした非常にもどかしく難しいプロセスであるがゆえに、どこか他責的に正解を探しに行くような欲求に駆られることは少なくありません。
ただだからといって、例えばSIer側のエンジニアからしたときに、要件定義とは要件という「正解」を顧客から聞き出す作業だと思っているとしたら、それは大きな間違いです。顧客の誰かが正解を持っているわけでもなく、プロジェクトとして要求や要件を作っていかなければならないのです。
システムとして何を作るべきなのかを考えるにあたって、それは絶対的な答えがあるものではなく、あくまでも時間軸や当事者によって相対的に変わるものだと捉えましょう。変わることを自然なことだと認識したうえで、それを有限の資源の中でどうコントロールしていくかを考えるという捉え方が非常に大切です。
5-2．変更を記録する仕組みを作る
一番大切なのはプロジェクトスコープとシステムスコープの変更を記録し管理することです。具体的にはベースラインの確定と変更要求を審議するプロセスの明確化ということになります。
プロジェクトマネジメント的に言うと「変更管理」という領域の作業です。正直私はこの変更管理プロセスは、商用プロジェクトマネジメントにおいて最も大切な機能だと思っています。より具体的な運用手法については、私が実際にプロジェクトでやってきたおすすめの変更管理プロセス事例を紹介した記事をご覧ください。
5-3．変更を計画に織り込む
プロジェクト開始時の投資費用の決裁と言う観点から言えば、「何かを実現するのにいくらかかり、費用対効果がこれこれだから了承ください」という上申の仕方が一般的です。一方で細かい要件については、システム要件がその時点のスナップショットなわけですから、当然時間の推移に応じて最適な要件は変化していくわけで、その対応にも当然工数が掛かるわけです。一般的には「保守費用」として整理されます。
投資稟議の際は、追加修正も含めて予算やスケジュールを想定しておくことを忘れないようにしましょう。最初のワンショットで完璧なものを作ろうとするから、無理が生じてしまいます。もちろん次の改修フェーズがあるから初回が適当でよいという緊張感のなさは問題外ですが、継続的に拡張していくことを前提とした計画が、最初からなされるべきです。
ユーザー側の起案者は審議のハードルを下げたいあまりに費用を最小化すべく、こうした継続拡張の予算を十分に組み込まないことがあります。ただこれは長期的にも非常にリスキーです。一度で完璧な仕組みが出来上がることはまずないことを信じ、修正や変更分の予算とスケジュールを当初予定に組み込みましょう。
その際、各要求や要件の前提となる仮説も一緒に記録しておきましょう。どういった仮説に違いがあったから、要件を変更せざるを得なかったのかがわかり、後で振り返りができます。
6．「のりしろ」を設計する
6-1．体制の「のりしろ」を作る
そもそも少人数のチームであれば、色々な作業を兼任せざるを得ないことは言うまでもありませんが、体制がピザのルールの上限を超えるとどうしてもチームに分かれます。チームが分かれると、そこにコミュニケーションの断絶リスクが発生します。組織論として、兼任やマトリックス型組織に対して、批判的な意見もありますが、これは私の経験含めて確信めいたものがありますが、マネジメントが楽をするだけの組織のシンプル化は必ず部分最適を生みます。
これを回避する策として一般的に言われているのが「会議体」なのですが、会議体だけだとどうしても人の深層意識までは制御できません。全体最適思想が特別に高い人を除き、どうしても所属組織の利益を最優先に守ろうとする意識が働くことはなかなか抑制できません。
私としては、「横断チーム」や「共通チーム」「横串チーム」、人的な「兼任」などをうまく活用し、意図的にチームをまたがる存在を置きながら、会議体での情報の連携と合わせ技で「のりしろ」を作ることが効果的です。
6-2．工程の「のりしろ」を作る
大工程と大工程の間に「計画・準備フェーズ」を設けることをお薦めします。どうしてもスケジュールが厳しい場合は短くても構いませんが、必ず確保しましょう。
工程が変わると成果物やプロセスも変わります。新しいレビュースキームも発生しているかもしれませんが、メンバーも入れ替わることもあるでしょう。新しい工程での役割の確認、環境の準備など、必ず予定通りにいかなかったり、生産性が一時的に下がります。この期間を予定に組み込んでおけるかどうかで、メンバーのゆとりが全く変わってくるのです。結果そのゆとりが品質につながっていきます。「余裕」は「余剰」ではなく、チームを円滑に回し品質を高めるための「必要コスト」だと捉えましょう。
6-3．コミュニケーションの「のりしろ」を作る
最近はチャットツールやチケットツール全盛となり、以前より情報が溢れることから、各人の発信を必要最小限の宛先に絞ることを意図しているチームもあると思います。
ただ自分は、情報は発信者ではなく受信者側が取捨選択する方が効果的であると考えます。情報が多すぎて困るという人のストレスや情報を見落とすリスクを軽減することのメリットと、情報が不足したために取るべき行動が制約されたり、意識の高いメンバーが全体最適に意識が向けにくくなることを防ぐメリットを考えた場合、私は後者のメリットを優先すべきだと思うからです。実際に過去その方針で運用してきましたが、実際にその運用でうまくいくことの方が多かったと感じています。
基本的にチーム内のコミュニケーションは、チームグループ全員が含まれる宛先にメンションを付けて行うという運用が効果的でしょう。
またマネジメントチームは、積極的にプロジェクト状況をメンバー全体に発信することも心がけましょう。普段の業務に関係ないと思えることも含めて、メンバーにより多くの情報を提供することで、メンバーの当事者意識にプラスの働きも生まれます。
また30名を超えるような体制だと、ほっとくと他のチームに新しいメンバーが入ったり、リリースがあったりしても殆ど我関せずとなることが多いです。月に一度は全体で集まる時間を設け、そうした他チームの状況も含めて共有することも効果的です。自身に関係ない情報は正直無駄に思える人もいるでしょう。ただこういう一見無駄な情報も含めて積み重ねで得た組織カルチャーこそが、気が付くとかけがえのない組織力に繋がっていきます。組織は一度ひびが入れば崩壊はあっという間です。プロジェクト組織は一度切りなのであまり組織に意識を置かないマネージャーも多いかもしれませんが、一度きりだからこそ丁寧に築き上げていきましょう。
7．「約束」を尊重する
7-1．大きな「約束」を守るために、まず小さな「約束」を守る
プロジェクト目標とは、いわばプロジェクト全体とコミットした「約束」です。ただその大きな約束を守る大前提として、日々の小さな約束を守れなければ大きな「約束」が守れるはずがありません。
課題やToDoの期限、チームで決めたルールの尊重、会議の集合そして終了時間の遵守など、普段の業務の中で取り交わされている小さな「約束」を、一つ一つ丁寧に扱うようにしましょう。リーダーが小さなことなのでいいかとしていると、必ず蔭でそのことに心をざらつかせているメンバーがいます。
7-2．「約束」の前には上司も部下もないことをチームで合意する
「約束」の前にはみんな平等であり、上司も部下もありません。「約束」の遵守について、役職や立場を超えて率直にフィードバック・コミュニケーションしてもよいことを合意しましょう。
誰にでも忖度せずリクエストできる権利と、そのリクエスト内容を交渉したり、断る権利を合わせて認めるのが、コミットメントの高いチームになるコツです。
依頼する側が遠慮し出すと、結局組織はストレッチされず、高いパフォーマンスは期待できません。依頼する人はチーム目標を達成するために必要なリクエストを、上司や他チームなど問わずリクエストができる権利を与えます。ただし、リクエストされた人にそのリクエスト内容を交渉したり、Noと断る権利も認めるのです。そうすることで、依頼側は堂々とチャレンジジングなリクエストができるわけです。
シチュエーション1
明日朝一のMTGに向けた資料は上司にレビュー済みです。ただ夜になって前向きな別のアイデアが思いつきました。資料を直したいが上司は帰宅済みです。どうするべきでしょうか？
悪い例
「今頃言うなよ」と怒られることを嫌って、勝手に諦めてそのアイデアを殺してしまう。
良い例
素直に、こういう修正をしたいと電話等で聞き、もし方向OKなら、資料のレビューを翌朝までにしてもらってもよいか？をストレートに尋ねてみる。
解説
上司は「OK！がんばって夜中みてコメントしておきます！」と言うかもしれないし、「ごめん、今晩はどうしてもチェックできないが、話の趣旨はいいので、ノーレビューでMTGに臨もう。何かあればその場でフォローする」と言ってくるかもしれません。また「今回は辞めておこう」となるかもしれませんが、それも受け止めます。
この選択の権利を相手に認めることで、遠慮なくチャレンジできます。無理を言いやすい関係性があるかないかの問題だと解釈されるかもしれませんが、実は違います。物事を前進させるために相互に遠慮なくリクエストをすることを認め、良しとするルールがあるかどうかの問題なのです。
シチュエーション2
資料を依頼することになったが、後続作業の為、少しでも資料を早くもらいたい。
悪い例
気を使いすぎたり、短納期を指定して不機嫌にされることを恐れて、本当に欲しい納期よりゆとりのある期日で依頼してしまう。
良い例
ストレートに最短で欲しい期日を伝える。「この資料を明日18時までに作成してもらえますか？」
解説
相手への拝領もしながら、自分の約束を守るために最善な期日をリクエストします。この場合、「それは無理です。」とNoを言う権利も相手に認めましょう。Noを言いやすい空気作りが重要です。
またYes/No以外に相手が交渉的回答をしてくることも歓迎しましょう。たとえば、「明後日18時までなら可能ですがそれでもよいですか？」などです。Yes/No/交渉という3つの選択肢を相手に認めることで、逆に依頼側も遠慮なくリクエストができるようになります。チームの目標のために、自分のミッションや約束を果たすために、周りにルールに則りリクエストできるチームが理想です。
8．「問題」を前向きに解決する
8-1．「問題」を忌み嫌わない
プロジェクトにとっては問題はつきものですが、正直あまり好意的には出迎えられません。ただ問題はそんなに忌み嫌われるべきものなのでしょうか？そもそも問題とはどういうものかを理解するところから始めましょう。
「問題」を数式的に表現すると以下のようになると思っています。
問題＝ 「目標（達成したい未来）」－ 「現実（なりゆきの未来）」
つまり問題がない状態とは、成り行きでほっといても達成するような目標と計画しか立てていないことになります。
チームとして全く成長がない状態と言えなくはないわけです。
手が届かないような、あまりに高すぎる目標を背負うのもなんですが、低すぎる目標も効果的ではないと言えるでしょう。
問題の遭遇は、ある一定の挑戦すべき目標達成にむけ、前進中であることの証だともいえるのです。
そういう意味で、問題をチームの前進と成長の機会だと捉えれば、プロジェクトに問題が発見されることが問題なのではなくて、問題を解決できる仕組みが定まっていないこと自体が問題だと捉えることもできます。
この問題を忌み嫌うことから問題を前向きに歓迎する姿勢への転換、つまり問題に立ち向かう姿勢のパラダイムシフトこそが、チームの前向きでかつ安心感を生む雰囲気作りに極めて効果を発揮します。
8-2．チームに問題解決の仕組み（問題を受け付け解決する）を導入する
では具体的にチームとしてどう問題と向き合えばよいのでしょうか？
問題を整理し解決するためだけの会議を定期的に開催することがおすすめです。
必要最小限の人数で招集し、意思決定のルールを明確化しておきます。
問題に関する事実情報を出し合い、それを元に皆で解決策や対策を出し合い、どの対策を選ぶか意思決定ルールに従って意思決定をくだします。その後は期日と担当を明確にタスクに落として、あとは他のWBSや課題と同様に進捗を確認していく。
問題を解決するという作業を特別な行為とするのではなく、極めて機械的に処理していくのがコツです。
なかなか前進させられない課題や、遅延が回復しないタスク、メンバーのスキルや関係性に関する問題まで、そのままだとプロジェクトの目標達成を阻害する重要な問題を解決するための「問題解決会議」を定期的に開催するのがお勧めです。（隔週程度が理想）
8-3．正しいレビューの文化を定着させる
問題は問題でも、成果物の品質に関わる問題はプロジェクトにとって致命傷です。成果物の品質を高めるにはレビューを効果的に運用することが欠かせません。
是非自チームに正しいレビューの文化を定着させましょう。レビュープロセスの基本方針として効果的なたたき台となる資料があります。
こちらの記事を参考にしてみてください。
9．「最悪」に備える
9-1．リスク管理を重く捉えず、日常化する
プロジェクトの熟練者ほど、プロジェクトマネジメントにおける最大のポイントは、リスク管理であると言います。特にウォーターフォール型のプロジェクト進行においては、問題を内在したまま進行したことによる手戻りコストが高いので、リスク管理が極めて重要です。PMBOKでもリスク管理は知識エリアとして取り上げられており、その基本概念は是非習得しておきたいところです。
ただマネジメント工数に余裕がない中小のチームにとっては、それを教科書通りに運用することは負担が大きいのも事実です。結果、運用が大変だからリスク管理自体をやらない、となることの方が問題です。もっと軽くリスク管理を運用しましょう。
そのためには、リスク管理を日常化することがおすすめです。
「今チームに起こったら一番困ることは何か？」という問いを、常日頃から全員に対して日常的に問いかけるようにすることがおすすめです。
その時点で一番インパクトの大きなリスク（起きては困ること）を潰すというのがリスク管理の基本です。
そのリスクの対策を自分で何とかできるならOK、できないなら上司に相談するルールとします。
日報・週報に「今チームに起こったら一番困ることは何か？」という項目を設けて、毎回記載してもらうのも効果的です。
10．「目標」を明確化する
10-1．全ステークホルダーにとってぶれない目標を言語化する
Amazonではサービスを企画する際に、プロダクトマネージャーはまずプレスリリースから書くと言います。サービスが実現した時の状況を文章として表現することで、全員にとってのぶれない北極星にすることができます。
もっとシンプルに、日付と達成したかどうかがわかる事柄、ワクワクするフレーズを入れた短い文章を作るというやり方も効果的です。
例：「2021年8月31日までにECサイトをオープンして月商1000万、メンバーが各自の知り合いから使いやすかったよというコメントを聞けるようにする！」
一定サイズのプロジェクトであれば、もう少し厚めに「プロジェクト計画書」や「プロジェクト憲章」というドキュメントも必要です。もし社内や近くに頼れるフォーマットがないようなら、以下を参考にしましょう。
10-2．所有感を大切にする
ただせっかくこうして作った資料やフレーズも、単にリーダーが創ったことに満足して悦に入っているだけでは意味がありません。各メンバーが自分のものとして腹に落としてもらい、日常的な行動指針にしてもらう必要があります。
ここは「 2．「意思決定ルール」を明確にする」でも記載しましたが、最後は意思決定者が決めることになったとしても、その目標や計画を生み出すプロセスに主要メンバーを絡ませ、意見を聞ける状態に置いたかどうかが重要です。マスタースケジュールや見積りなどもそうですが、どうしてもコアになってもらいたいメンバーの所有感の醸成には、細心の配慮を払いましょう。確かに手間がかかります。ただこれは「コスト」ではなく、大切なメンバーからの「信頼」や「コミットメント」という財産を得るための「投資」だと考えましょう。きっとその後にリターンがあります。
参考資料
登壇資料
配信アーカイブ（本セッションは43分30秒頃から）
イベントまとめ記事
最後に
プロジェクト運営の難しさは、業界や仕事を超えて、今も昔も変わっていない気がします。
チームやプロジェクトがうまくいっていない時に、アジャイルやウォーターフォールと言った方法論の是非や個人の資質を言及することよりも、それ以前にチームとして機能するための行動指針や原理原則が整っていることこそが、私は大切だと信じています。
プロダクトマネジメントの重要性がより声高に叫ばれる昨今、ITシステムに関わるステークホルダーはますます多くなることは間違いありません。
そうした中で、違う立場同士がお互いを尊重し合い、相互に職域を越境し合いながら、不確実性に向き合っていくというスタイルこそが、これからのプロジェクトの在り方ではないかと思います。
こうした考え方が、PMやエンジニアのみならずマネジメントや利用者層など幅広い人達に広がり、エンジニアリングチームがより本質的なビジネス課題の解決やプロダクトの磨きこみに注力できるよう、環境が改善されることを願ってやみません。
まとめ
- うまくいっていないPJは「チームの原理原則」が機能していない場合が多い
- 「チームの原理原則」を整えるのがマネージャーの役割
- メンバーを含む各ステークホルダーも、人任せにせず、自ら道の真ん中を超えていこう
最後になりますが、登壇の機会をいただいたJBUG広島、AgileJapna広島支部の皆様、ありがとうございました。
-
仲間や同僚を表す「peer」と報酬を表す「bonus」を組み合わせた言葉で、従業員同士が互いに報酬（ボーナス）を贈り合うことができる仕組みのこと。参考サイト：https://www.noc-net.co.jp/blog/2020/02/column_333/ ↩