専任の「技術主任」の大切さ

リーダー、マネージャー、アーキテクトはそれぞれ異なる役割・特性を持っている。
それを考慮せず、職制上の上司を「マネージャー兼アーキテクト」にしたことが直近のプロジェクトのデスマーチ化の原因の一つのように思われる。

デスマーチ化後に読んだ「Ship It! ソフトウェアプロジェクト 成功のための達人式ガイドブック」により示された「技術主任」の大切さをずっと認識するために書く。私は「技術主任」とは「アーキテクト」のことだと解釈したので、両者を同一のものとして書く。

リーダー・マネージャー・アーキテクトのイメージ

リーダー、マネージャー、アーキテクトに求められている役割・特性をざっくり図にしてみるとこんなところだろうか。

この図で言いたい事は以下の事である。

  • リーダーとはマネージャーやアーキテクトより強いリーダーシップと未来を語るビジョンによって形作られる。リーダーシップが「結晶」した存在。
  • マネージャーやアーキテクトにも「ここではこの人についていこう」と思わせるローカルなリーダーシップは必要である。
  • 技術を全く理解できないマネージャーではならない。
  • 管理を全く考慮できないアーキテクトではならない。

リーダーをリーダーシップが「結晶」した存在としており、マネージャー、アーキテクトとは一線を引いている。この感覚はGoogleで検索した結果でも伝わってくる。「manager」と「architect」の検索結果では具体的な人間が出て来る。「manager」であれば現場をまとめていく力強さを感じる人物の絵であり、「architect」はヘルメットに象徴されるように現場・技術を感じる場面の絵である。一方、「leader」では具体的な人間が出てこない。大勢にリーダーと認識される写真を撮ることが難しいという理由もあるのかもしれないが、出てくるのは先頭・矢印の尖端・台の上にいる人物「像」なのである。「像」であるからマネージャーやアーキテクトも一面ではリーダー的であれるのである。ある局面で先頭を走ったり、台の上から号令をかけたり・・・。この「ある局面」が上記の「ここでは」強調の意図である。そしてその「像」が本当に人間になるほど強いリーダーシップを有し、未来を語るのが純粋なリーダーだ。未来を語るが故に「ここでは」のローカルな縛りがはずれ、より広い時間軸・範囲でのリーダーとなる。

「leader」の検索結果


「manager」の検索結果


「architect」の検索結果


兼務ではない技術主任(アーキテクト)の必要性

「Ship It!」(p.68)から技術主任の説明を引用する。

技術主任は、ソフトウェア開発プロジェクトの技術面を監督するとともに、その技術的な責任を負います。プロジェクトに技術主任が加わっていれば、技術的な問題をより高度な専門的能力を備えた技術主任に任せられるので、プロジェクトマネージャは技術面の責務から解放されて管理面の仕事に専念できるようになります。マネージャが技術主任を兼任することも考えられますが、もちろん兼任は必須ではなく、多くの場合そのような体制は望ましいとはいえません。必要な技術的専門知識をマネージャが欠いている場合や、そのチームが複数プロジェクトの作業を担当している場合は、マネージャとは別に専任の技術主任を置くことが理想的です。

技術主任が必要な理由
開発者が使っているテクノロジを理解していないマネージャの下で開発を行った経験がありますか?このようなマネージャは非現実的な納期を設定し、作業の遅れに理解を示さずスケジュールについて何かと文句を言います。このような事態が起こる原因は、開発者の作業の内容やテクノロジが機能する仕組みをマネージャが理解していないことにあります。

兼務をすると何が起こるのか

小規模なプロジェクトで、かつ作業内容が見切れている場合には兼務も可能である。それは技術的に新しいこともなく、ルールも決まっており、品質確保の仕組みももうできている、といった場合だ。

そうでないならば、兼務はするべきではない。マネージャーとアーキテクトそれぞれの仕事がすべて兼務者に降り掛かるのである。スケジュールを調整している時に、「この場合はどうしたら?」といった技術的な問いが来てもすぐに答えられるものではない。仮に少し考えれば、というものであっても何度も頭のスイッチを管理と設計で切り替える訳にはいかない。

  • マネージャーの仕事
    • 上位・外部からの管理への対応
    • タスク管理
    • 問題管理
    • スケジュール化・分担
    • 進捗を計る仕組み作り・運用
    • メンバーの状態管理・就業環境改善
  • アーキテクトの仕事

マネージャーの仕事が止まっても、アーキテクトの仕事が止まってもチームの活動はそこで停滞する。また、その1人がダウンしたら、チームからマネージャーもアーキテクトも同時に居なくなってしまうのだ。