ライター
チーム横断課題を解決できないプロジェクトマネージャー
チーム横断課題はどう解決すべきか
このコラムのきっかけは、社内で行われた事例勉強会で参加者から「一定規模以上のシステム開発プロジェクトで複数チームにまたがる問題（＝チーム横断課題）をどのような体制で解決するか」という質問がされたことです。
ITプロジェクトのチーム横断課題解決で鍵になるのは、解決のリーダーシップです。問題の全体像を把握して必要な情報を集め、解決に必要な関係者を全員巻き込み、納得感のある選択肢を関係者に提示して議論を促すファシリテーターが必要です。このファシリテーターには問題の背景全体を整理し解決のオプションを提示する能力（いわゆる問題解決能力）、関係者を巻き込む周囲との信頼関係が求められます。往々にしてこのような課題は、多くの人が逃げ腰になります。そのような中でも、当事者意識を持って解決の中心となって動こうとする覚悟こそが、一番求められる能力かもしれません。
なお、問題解決に必要な情報をしっかり理解していること（知識）も大切ですが、このような問題が発生している時、多くの場合は解決に必要な情報を完全におさえている人がいないので、問題発生時の情報（知識）保持の有無よりも情報収集力や素早く状況を理解する力の方が問われます。
このような問題解決を担うべき役割は、一義的にはプロジェクトマネージャー（以下、PM）です。ところが、PMがこの役割を果たせないことも少なくありません。
PMが問題解決をリードしなかったプロジェクトの事例
ここで私の経験談を共有させてください。株式会社エル・ティー・エス（以下、LTS）に入社する前に経験した一定規模のITプロジェクトのうち2つを共有します。1つはプロジェクトでメンバー数十名、もう1つはプロジェクトでメンバー数百名という規模です。前者のプロジェクトはなんとかシステムが稼働しましたが、当初予算やスケジュールを大きく超過しました。そして後者のプロジェクトはデスマーチ化し、最終的に中止になった完全な失敗プロジェクトです。
まず1つ目のプロジェクトでPMが行っていたのは、スケジュールを引いたり、プロジェクト体制を拡張したり、会議を運営したり、外部ステークホルダーに説明したり、コストを計算したりといった、狭義のプロジェクトマネジメントばかりでした。システムの設計はほぼ個別チームのリーダーと、リーダー間の連携に任されており、当時、まだ経験が少なった私はそのことに疑問も持たず、特定の機能設計チームに所属しながらも、このコラムの冒頭に書いたようなチーム横断の課題解決のファシリテーターとしても走り回っていました。システムは稼働したものの、予算＆スケジュール超過を繰り返し、私が設計に関わった領域の機能は予算ショートの中で「優先順位が低い」として機能削減の対象となりました。
2つ目のプロジェクトも似たようなもので、PMはプロジェクト外のステークホルダーとの調整に明け暮れるばかりで、システムの設計は各機能チームを率いるリーダーに任されていました。しかし、リーダーたちはお互いの利害でぶつかるばかりです。まだプロジェクトが小規模だった初期フェーズは、それでもなんとかプロジェクトは進捗していました。しかし、設計が進むにつれてチーム間の意識の乖離が表面化し、コラボレーションは機能していなかったように思います。プロジェクトマネジメントオフィス（PMO）に所属していた私は、マネージャー間の政治劇に近いタスクの押し付け合いを議事録担当としてただひたすら文字起こしをしていました。そして、このプロジェクトは2年の間、リスケジュールを繰り返した上で中止になりました。
チーム横断課題の解決でポイントとなるアーキテクトの存在
これらの経験を振り返った際に、気になることがあります。それはプロジェクトにおいて「アーキテクトはどこにいたのか？」です。紹介した2つのプロジェクトは、私が見ていた限り、明らかにアーキテクトが不在でした。
アーキテクトとは
言葉に関しておさらいをすると、一貫した思想に基づいて設計されたシステムの全体構造が「アーキテクチャ」であり、このアーキテクチャの設計を行う役割が「アーキテクト」であり、この設計作業を「アーキテクティング」と言います。プロジェクトにおきる問題にはさまざまなものがありますが、それが外部ステークホルダーの巻き込み不足や予算不足、キーメンバーの離脱といったプロジェクト運営上の問題であれば、それはPMが対応します。
一方で、ビジネス要求とシステム設計の不整合であったり、システム全体にまたがる仕様や技術的な問題であったりする場合、これはアーキテクチャ（ITアーキテクチャ）に瑕疵がある状態です。例えば分割された機能間で情報の流れに不整合が起きていたり、システム機能の境界がしっかりプロジェクト体制に反映されておらず、担当が割当たっていない機能があったりという事態です。これに対応するのがアーキテクト※（複数のアーキテクトがいる場合は、チーフアーキテクト）となります。
ITアーキテクト、システムアーキテクト、もしくはビジネスアーキテクトなどと言われます。
アーキテクトの役割
各機能チームからエスカレーションされる横断課題には、プロジェクト運営上の問題もありますが、システム仕様に関するものもたくさん含まれます。これはある程度仕方ないことで、抽象から具体に落としていくシステム設計の流れでは、後工程で上流のアーキテクティングの瑕疵が見つかることを完全に排除するのは、かなり難しいものです。
ただ、瑕疵が見つかった段階でアーキテクトがそれを認識し、機能チームにまたがる不整合を解消した新たなアーキテクチャの姿を提示することができれば、問題解決はスムーズに進みます。その意味で、前述の「問題解決ファシリテーター」は、プロジェクトにアーキテクトが存在している場合、そしてそれがシステム仕様や技術に関わる問題の場合は、アーキテクトが担うべきです。優秀なアーキテクトが存在しているITプロジェクトでは機能的、技術的な横断的問題自体が発生する確率が減りますし、それらが発生してもアーキテクトが問題解決のファシリテーターとして動きます。アーキテクトはチーム横断課題を解決する上での鍵となる役割なのです。
徐々にアーキテクトの役割を担えなくなるプロジェクトマネージャー
PMへの期待と現実
さて、多くの人はこのアーキテクトの役割をPMが担っているはずだと思うことでしょう。確かに「アーキテクト」が独立した役割としてはあまり認識されていない日本では、この役割はPMが担うケースが多いように思います。そして、本来はPMがアーキテクトの役割も担った方がプロジェクトは円滑に進みます。PMはシステムの基本思想を設計し、企画としてまとめて、必要なコストやスケジュールを算出して、ステークホルダーと調整します。プロジェクトが進行して、個別機能チームが組織されるようになっても、PMがシステムのビジョンをチームに提示し、チームからの相談に素早く対応することで横断課題は速やかに解決されていきます。全体的に情報はPMに集約されており、PMは頼れるリーダーとして機能するわけです。
ところが現実のプロジェクト、特に一定の規模を超えるプロジェクトでは、プロジェクトの進行と共にステークホルダーが増え、予算やスケジュール管理も複雑になります。その結果、プロジェクト運営の労力が指数関数的に増えます。その裏側で、システム設計の情報量も同じかそれ以上のスピードで指数関数的に増えます。必然的に、多くのPMがプロジェクト体制の運営にその労力を集中し、どんどん具体化・細分化されていく機能設計は各チームに任せるようになっていきます。そして、チームサイロがどんどん大きくなり、チームの個別最適化が進み、当初の設計思想が希薄化していきます。
しかし、PMはその時点で既に増大したシステム設計の情報量についていけなくなっており、チーム横断の課題があっても有効な解決を提示することができなくなります。結果的に「チーム間で話し合って何とかしてよ」といった曖昧な指示だけをだす残念なリーダーが出来上がるわけです。私が過去に経験した「アーキテクト不在」のプロジェクトで起きていたことはこれでした。
これについては私自身も苦い経験があります。LTSで販売管理システムを刷新した際、当初私の役割はPMでした。プロジェクト開始時はメンバーと密に連携できておりプロジェクトをコントロールできていたのですが、プロジェクトが進むにつれて他の業務との兼ね合いもあって各領域のリードをプロジェクトメンバーに任せるようになりました。プロジェクトの中盤以降さまざまなトラブルもあったのですが、その時既に現場感（情報）が失われていた私は、メンバーからの依頼に言われるがまま対応するしかなく、実質的なプロジェクトのコントロール権を失った状態になりました。
最終的にシステムは無事稼働し、現在のLTSを支える大切な基盤となってはいますが、あの時の私の振る舞いはとても褒められたものではありません。このような体験談を聞くことは多く「アーキテクト不在」という問題は、システム開発の世界では意外と多く起きているのではないではないかと思います。
PMとアーキテクトは「軍政と軍令」の関係に近い
プロジェクト内での肩書はともかくとして、アーキテクトの役割を担う人がいないプロジェクトではシステムに一貫した思想や完成形のビジョンが提示されなくなり、設計が個別最適の山となります。小規模なシステムだとリーダー間の連携や、一部の優秀なメンバーの超人的な働きで、まだ何とかなりますが、メンバー数が20～30人を超えるような規模だともうダメです。結果的にコストやスケジュールの超過、アドオンやカスタマイズの山、それらの反動としての無茶な機能削減や運用回避への逃げ、放置される重大問題が横行します。プロジェクトの目標は当初から逸脱して「とにかく動くシステムを作ること（そしてメンバーがプロジェクトから逃げを決めること）」が最大のゴールになります。
上手くいっているプロジェクトではPMがアーキテクトとしての仕事をしっかりこなしているか、もしくはPMとアーキテクトの双方が存在して連携しつつも、ステークホルダーへの対応とプロジェクト体制や環境の維持に注力するPMと、製品に一貫した思想と完成形のビジョンを提供して設計を推進するアーキテクトの連携が機能しています。
この「PMとアーキテクトが双方存在する体制」は、軍隊で言うと「軍政」と「軍令」の関係に似ています。軍政とは政府等と折衝して、軍事行動全体の目標を設定し、そのために軍隊が動くための環境（人事、予算や体制、法的裏付け等）を整えます（自衛隊だと防衛大臣、旧軍だと陸軍大臣ないし海軍大臣の仕事）。軍令とは目標達成のための作戦行動を立案し軍隊を動かす活動です（自衛隊だと統合幕僚長、旧軍だと参謀総長ないし軍令部長の仕事）。
先ほどのITプロジェクトの例だとPMが軍政を、アーキテクトが軍令を管轄します。ここまでお話した失敗プロジェクトではPMが“軍政”に忙殺され、個別の作戦は各部隊に委ねられ、部隊はお互いの連携もできないまま各方面で右往左往している状態となります。連携を失い、追い詰められていく現場部隊からは正しい情報が上がることもなくなり、そのうち“軍政”側も破綻していくわけです。
アーキテクトの役割を誰が担うべきか
PMとアーキテクトを一人の人間が兼務すべきか、分けるべきかについては意見が分かれるところです。個人的には「マネージャー」と「アーキテクト」は異なる専門性であり、どちらかの役割に向く人が必ずしももう一方の役割に向くとは限らないことを考えると、役割を分けることは悪くない選択肢のように思います。そもそも複雑化し、ひとつのプロジェクトの範疇ですら多様な技術を理解しなければならない今日のシステム開発では、アーキテクティングですらアーキテクトが一人で担うことが現実的なのかという疑問すら湧きます。PMや複数のアーキテクトが連携するアーキテクティングの手法を見つけることも考えるべきなのかもしれません。
その一方で、プロジェクトマネジメントとアーキテクチャは密接不可分な関係でもあり、現実的には綺麗に役割分担して機能させるということも難しいのもまた事実です。アーキテクチャとは開発対象のシステムのプロダクトビジョンそのものであり、ビジョンを管理できない人がPMを担えるのかという疑問も湧きます。
この答えを探す上で、製造業の製品開発の現場は参考になるかもしれません。システム開発が複雑化したと言っても大抵のシステム開発の規模は、高度なシステムの塊と化した一車種の自動車を開発する規模と比べればまだ小規模です。その自動車業界では「チーフエンジニア」をリーダーに置いた開発体制が機能していることを考えると、システム開発でも一人のリーダーが調整とアーキテクトの役割の双方を果たすことで問題を解決できる割合はまだまだ高いと考えます。
プロジェクトマネージャーは「製品責任者」としての自覚を
このようなことを考えた際に、日本ではPMの役割において「プロジェクト運営」の色が強すぎて、PMの「（システムという）製品の責任者」という観点が弱いことが気になります。確かに車のデザイン、機能のほぼすべてに大きな権限を有する自動車会社のチーフエンジニアに比べて、要求がプロジェクトの外部からやってきてステークホルダーとの調整者に膨大な労力を割かれるPMは、コミュニケーターとしての側面が強調されるのは仕方ないことだとは思います。それでも、システムという製品を完成させる上で、一貫した製品思想のない状態で良い製品が生まれるわけはなく、そしてその思想を持つべき人はプロジェクトの外部には存在しない以上、どれだけ外部からの要求があろうと、PMは「製品責任者」の自覚を持つべきです。
その上で、プロジェクトの規模の増大に合わせてPMの下にアーキテクトないしアーキテクトチームを組織し、横断課題の解決を任せていくことは一つの対策にはなると思います。もちろんPM自身も、アーキテクトチームの一員であることには変わりはなく、アーキテクトの側面から逃れることはできません。ですからPMとアーキテクトの関係は、役割分担というよりも、アーキテクトとはPMの一部の役割の分身であり、密接なコミュニケーションの下でアーキテクティングを委譲していく先と思った方が正解かもしれません。
企業はアーキテクト能力の育成を
私が一連の考察を通して再考したのは、アーキテクトという役割の大切さでした。アーキテクトが居さえすればプロジェクトが失敗しないなどという保証はどこにもないですが、少なくともアーキテクトがいない一定規模以上のITプロジェクトがスムーズに進むことはないと考えます。複数機能にまたがるシステム設計を担うアーキテクトの育成は時間がかかります。アーキテクチャはシンプルに見えますが、これは小さな機能の集合体であるシステムの全体像を、要点を抑えて抽象化して表現しているだけであって、アーキテクトが描くシンプルな構造図の裏側には膨大な情報が存在しています。アーキテクトはその複雑さの理解の上に、情報を取捨選択して一見シンプルに見えるイメージを描いています。その意味で、アーキテクティングは一定量の経験が必要で、アーキテクトを一朝一夕で育てることはできません。
このコラムは以上となりますが、皆さんの会社はアーキテクトを育てているでしょうか？もしくはPMは自らのアーキテクトとしての役割を認識し、その能力を育てる努力をしているでしょうか。このコラムが何か皆さんに新たな気付きとなるようであれば幸いです。
