この記事でわかること
-
プロジェクトのジレンマを解消する「両利きの思考」
-
メンバーの自律性を引き出す「定例会議」の仕掛け
-
ビジネス側と信頼関係を築く「プロジェクトストーリー」の描き方
変化の激しい現代の開発現場において、エンジニア出身のリーダーは「計画通りの遂行」と「柔軟な変更」という矛盾するジレンマに直面しています。さらにAIなどの最新技術が登場し、プロジェクトの不確実性は増すばかりです。
こうした複雑な状況を乗り越えるカギが、「両利きのプロジェクトマネジメント」です。株式会社コパイロツトで組織のプロジェクト推進力を向上させる「Project Enablement事業責任者」を務める米山知宏氏は、リーダーがチームを管理して動かすのではなく、チーム全員の主体性を引き出す独自のメソッドを提唱しています。
本記事では、米山氏へのインタビューを通じて、自律的なチームを作るための会議設計から、ビジネスサイドとの信頼を築く対話術まで、次世代リーダーに求められる実践的な知見をお届けします。
米山 知宏
株式会社コパイロツト Project Enablement 事業責任者／新潟県村上市役所CIO補佐官
東京工業大学大学院社会工学専攻修了後、株式会社三菱総合研究所、新潟県新発田市役所を経て現職。民間企業や自治体のDX支援を行いながら、プロジェクト推進の方法論を探究している。
【X（旧Twitter）】：https://x.com/kedamatti
両利きのプロジェクトマネジメント 結果を出しながらメンバーが主体性を取り戻す技術
出版社：翔泳社 著者：米山 知宏
【参考】：https://www.shoeisha.co.jp/book/detail/9784798185521
目次
計画か柔軟性か。エンジニアのジレンマを解消する「両利きの思考」
まず、米山様の現在のお仕事について教えてください。民間企業から自治体まで幅広い領域で活躍されていますが、これまでのご自身のキャリアの変遷についてもお伺いできますでしょうか。
現在は新潟市に住みながらフルリモートで株式会社コパイロツトの仕事をしており、クライアントのプロジェクトマネジメント支援をメインに行っています。具体的には、クライアント企業のPMを育成するための研修やワークショップを行ったり、プロジェクトを進めやすくするための仕組みやテンプレートを構築したりしています。
最近はAIを絡めた仕組み化のご相談も増えていますね。 また、コパイロツトの仕事として、新潟県村上市役所のCIO補佐官という肩書で自治体のDX支援にも携わっています。
三菱総合研究所や自治体でのご経験を経て現在に至るとのことですが、どのような課題感から『両利きのプロジェクトマネジメント』を執筆されたのでしょうか。
シンクタンク時代に国や自治体のシステム開発プロジェクトでPMOとして支援し、その後自治体の職員として中に入って当事者として働く経験もしました。そこで感じたのは、民間も行政も「マネジメントがうまくできていない」という共通の課題でした。
それは、プロジェクトをマネジメントできていないということだけではなく、プロジェクトを通じて経験したことから学んだり、ナレッジとして残したりすることができていないのです。そのような状況だと、仕事のやり方に明確な「型」がなく、とりあえず気合で頑張るという属人的な状況に陥りがちです。これは決して健全とはいえません。このような状況を打破し、誰もがプロジェクトを前向きに進めていくための考え方や型をお伝えしたいと思ったのが執筆の動機です。
なるほど、現場の切実な課題感が背景にあるのですね。著書で提唱されている「両利きのプロジェクトマネジメント」についてお伺いします。エンジニアがPMやリーダーを任される際、「計画通りに進めたい（直線的）」という要求と「仕様変更に柔軟に対応したい（曲線的）」という矛盾によく直面します。このジレンマをどう乗り越えればよいのでしょうか。
プロジェクトを推進する際、計画や合理性を重視する「直線的なモード」と、対話や変化を柔軟に受け入れる「曲線的なモード」があります。私たちは意識的か無意識的かはともかく、これらを使い分けているのですが、一方で、どちらか一方に固執してしまうプロジェクトも少なくありません。一度決めた計画に固執して無意味な作業を続けたり、逆に「対話が大事だ」と言って延々と話し合い、結局何も決まらず動き出さなかったりします。
たしかに、アジャイルかウォーターフォールかというように、二項対立で考えてしまうことが多い気がします。私も過去のプロジェクトで「とにかく計画通りに」と進めた結果、後戻りできなくなった苦い経験があります。
大事なのは、進め方の話の前に、「成果を成し遂げる意思」と「自分たちなりの仮説」をまず持つことです。DXや新規事業のような正解がわからない領域では、いくら進め方の議論をしても意味がありません。
まずは「私はこう思う」という仮説を可視化し、意思を示すことがスタートラインになります。その上で、状況に合わせて直線のやり方と曲線のやり方を柔軟に選択することが「両利きの思考」なのです。
正解がない中での仮説の出し方について、何かコツはあるのでしょうか。日本人は特に、確信が持てないと意見を出しにくい傾向があるように感じます。
これには「マクドナルド理論」と呼ばれるものがあります。お昼ご飯を決めるときに誰も意見を出さない中、「とりあえずマックにしよう」と言うと「マックは嫌だ。蕎麦がいい」と具体的な意見が出始めるというものです。
プロジェクトでも同じで、確信度の高低に関わらず、全員がテーブルに仮説を出し合うことが重要です。間違っていてもいいので、まずは叩き台となる意見を出す。すると「それであれば、こっちの方がいい」と相互に触発され、確信度が高まっていくのです。最初の「一歩目」をいかに早く、全員で出せるかがポイントですね。
脱・抱え込み。エンジニアチームの自律性を引き出す「定例会議」の仕掛け
プレイヤーからマネジメント側に進むエンジニアの多くが、「自分で抱え込んで無理をしてしまう」という課題に直面します。この状態から脱却し「全員でマネジメント」する環境を作るための最初の一歩は何だとお考えですか。
チーム全員でマネジメントするといっても、いきなり「みんなでマネジメントしよう！」と言われても、メンバーは困惑してしまいます。最初はハードルを下げて、「同じ時間で一緒に共同作業をする」という体験を作ることをおすすめします。エンジニアリングの世界でいう「ペアプログラミング」のようなイメージですね。
リモートワーク環境下だと、お互いの作業状況が見えにくいので、一緒に作業する時間は貴重ですね。具体的にはどのような作業から始めるとよいでしょうか。
一番簡単なのは、定例会議の議事録をオンラインで一緒に作ることです。同じ画面を見ながら、誰が何を考えているのかを共有する。そこから「ありがとう、助かった」という小さな成功体験を積み重ねていき、徐々にマネジメントの役割をシェアしていくのが良いでしょう。進行役を輪番制にするのも、メンバーの目線を一段上げる効果があります。
議事録の共同編集なら、明日からでもすぐに始められそうです。本書ではプロジェクト推進のコアエンジンとして「定例会議」が挙げられています。単なる進捗報告の場に終わらせず、チームの自律性を引き出すための工夫について教えてください。
会議は単に、プロジェクトマネージャーやプロジェクトリーダーが議論したいことだけを議論する場ではなく、チームとして議論すべきことを腹落ちするまで議論し、会議後のアクションの質をより良いものにしていくための場です。そのため、会議でもっとも重要なことは、会議で議論すべき論点（＝アジェンダ）をメンバー全員が出すことです。というのも、プロジェクトマネージャーだけでは適切なアジェンダを網羅することはできないからです。メンバーもアジェンダを出すことで、チームとしていま議論すべきアジェンダを見出すことができるのです。
しかし、「アジェンダを出して」と言うとプレッシャーに感じる人も多いです。 そこで、「アジェンダ」という言葉にこだわらず、「今モヤモヤしていること」や「ちょっと相談したいこと」をチャットや共有ツールに書いてもらうことから始めます。そうして集まった小さな「モヤモヤ」を起点（①アジェンダ）として議論し、方針を決め（②議事録）、次の行動（③アウトプット）へとつなげていく。このサイクルを途切れさせずに回し続けることが、プロジェクトの強力な推進力になるのです。
「モヤモヤしていること」を集めるというのは心理的ハードルが下がって良いですね。集まった意見は、リーダーがどうさばいていくのが正解なのでしょうか。
ここが一番のポイントなのですが、リーダーが過保護になって勝手にゴールや解決策を決めないことです。意見を出した本人に「これをどうしたいか？ 会議で議論したいか？」を尋ね、当事者に決めてもらうことが重要です。
この「自分で決める」というプロセスの積み重ねが、メンバーの自律性を育んでいくのです。リーダーが先回りして導いたり、頭ごなしに「自律的に動け」と言ったりしても、逆効果になるだけですから。
エンジニアの技術力を組織の成果に変える「4つの管理領域」
書籍の中では、マネジメントすべき対象として「4つの領域」が登場しますね。まず、それぞれの領域について簡単に教えていただけますか。
プロジェクトを推進する上で意識すべきなのは、以下の4領域です。
- プログレス（成果・進捗）：目指すべきゴールに向けた具体的な成果物や進捗状況
- プロセス（進め方）：定例会議を中心とした、仕事の進め方や仕組み
- チーミング（チームのあり方）：メンバー相互の関係性や、心理的安全性、役割の調整
- ラーニング（学び方）：プロジェクトを通じて得た気づきや、未来に活かす知恵の蓄積
技術特化で歩んできたリーダーが陥りやすい、視点の偏りはありますか。
エンジニアに限らずですが、かつては「プログレス（成果・進捗）」だけを見て、やり方やチームの関係性はどうでもいいという風潮がありました。しかし、それでは短期的な成果は出ても、メンバーが疲弊し、中長期的な再現性がありません。
逆に、「プロセス（進め方）」を絶対視してルールでガチガチになってしまったり、「チーミング（チームのあり方）」を重視しすぎて単なる仲良し集団になり成果が出なかったりという偏りも見られます。これら4つの領域のバランスをとり、中長期で持続可能な体制を作ることがPMには求められます。
プロジェクトが炎上しそうになると、つい「プログレス（進捗）」ばかりに目が行ってしまいがちですが、そこをグッと堪えてプロセスやチーム状態を見る必要があるのですね。個人の技術力をチーム全体のパフォーマンスへ昇華させるために、有効な「チーミング」の第一歩は何でしょうか。
プロジェクト開始時に、役割や期待値を丁寧にすり合わせる「ロールセッション」を行うことです。単なる体制図上の役割だけでなく、「AさんはBさんに何を期待しているか」「逆に自分は何が不得意で、どうサポートしてほしいか」をオープンに開示し合います。
お互いの期待や不得意な部分を知ることで、チーム内にどのような変化が生まれるのでしょうか。
期待が可視化されると、「そういうことなら、私はここを頑張ってみる」という自発的な動きが生まれやすくなります。自律性や主体性というのは、自分が何を求められているかが明確になる環境でこそ自然と引き出されるものなのです。
では、日々の業務に追われる中でチームとして学び続ける「ラーニング」を実践するには、どのような工夫が必要でしょうか。
プロジェクトを進めながら学んでいくためのベースになるのは「ふりかえり」ですが、ふりかえりといっても、1時間もかけて仰々しいふりかえりをする必要はありません。定例会議の最後のたった30秒や1分で構わないので、「これは次に活かしたい」「これは改善したい」というような気づきを付箋1枚やドキュメントに一言メモを残す習慣をつけることです。少し先の未来の自分たちに向けてナレッジを渡していく、その最小単位のふりかえりを習慣化することがラーニングの第一歩になります。
エンジニアとビジネス側の溝を埋める共通言語「プロジェクトストーリー」
エンジニアがビジネスサイドと円滑に合意形成を行うために、WBSだけでなく「プロジェクトストーリー」を描くことが重要だと書かれています。この「物語」を作ることで、コミュニケーションはどう変わるのでしょうか。
WBSなどの工程表は「いつまでに何をやるか」を示すのには有効ですが、なぜそれをやるのかという「実現したい状態」が表現されていません。特にDXなど前例のないプロジェクトでは、数値目標やタスクだけでなく、背景や意味を含んだ「物語」として計画を共有することが重要です。
物語として共有されることで、エンジニアとビジネスサイドの溝はどう埋まっていくのでしょうか。
「こういう状態をこういう流れで目指すプロジェクトなんだね」という情景が共有されると、先ほどお話しした「であれば、こうしよう」という動きが職種を超えて引き出されます。自分のタスクだけを見るのではなく、ビジネスサイドが何を考えているのか、なぜこの目標値を追っているのかという数字には表れない背景や文脈を理解できるようになり、より本質的な提案や自律的な行動につながります。
なるほど。ビジネスサイドとの信頼関係を築くために日頃から意識すべき習慣はありますか。
少し難しいかもしれませんが、「相手の頭の中を想像し、相手の視点に立ってみる」習慣です。例えば、ビジネス側からの要望があったとき、その言葉尻だけで判断するのではなく、彼らが日頃Slackでどんな発言をしているのか、どんな資料を読んでいるのかを広くインプットして文脈を把握する。 その上で、「あれってどういう意図ですか？」とやさしく確認してみる。そうやって相互理解を深める努力が、強固な信頼基盤になっていくと思います。
AI時代に選ばれるキャリア。エンジニアが面白がる「ファシリテーター型」PM
AIや最新ツールの登場で、プロジェクトの不確実性やエンジニアの働き方も大きく変わろうとしています。そんな中で、エンジニアが市場価値を保つために、両利きの思考をキャリアにどう活かせるのでしょうか。
トレンドに流されず、「社会における自分のポジショニング」を客観視することが重要です。例えば、みんながAIのスキル習得に走っているのなら、あえてニッチだが価値のある領域に振り切るのも一つの戦略です。
中途半端なAIスキルよりも、自分にしかできない強みを再定義する。過去を棚卸しし、未来の自分を設計する「時間軸の両利き」の視点が欠かせません。
変化の激しい時代において、5年後、10年後も「選ばれ続けるリーダー（PM）」とは、どのような人物像でしょうか。
「自分自身と役割を客観視し、常にアップデートし続けられる人」、そして「正解を探すのではなく、仕事を楽しんでまずやってみる人」だと思います。 「どうしたらいいですか？」と立ち止まるのではなく、「私はこうしたら面白いと思う」と仮説を立てて行動する。失敗してもそれが経験値となり、自分のスタイルが更新されていきます。
まず行動して経験から学ぶ姿勢ですね。最後に、マネジメントに進むことに不安や迷いを感じているエンジニアに向けて、メッセージをお願いします。
以前は、マネージャーといえば「すべてを把握し、正しい決断を下して、みんなを引っ張る強いリーダー」というイメージがありました。しかし、今はそんな管理一辺倒のマネジメントは必要ありません。 もっと気楽に考えてみてください。
すべてを自分で決めるのではなく、決断をメンバーに委ね、彼らが働きやすい環境や仕組みを整える「ファシリテーター」としてのマネジメントも十分に成り立ちます。私自身もコパイロツトに入社して、そのスタイルを知って随分と心が軽くなりました。皆さんも、自分らしいマネジメントのスタイルを見つけて、プロジェクトを楽しんでいただければと思います。
ライター
