ソフトウェア開発を成功させるチームビルディング

筆者の岡島さん(id:HappymanOkajima)よりご献本いただきました。ありがとうございます。

岡島さんの前著である「プロジェクトを成功させる 現場リーダーの「技術」」の発売から3年。
本書は、それから現場リーダーとしてさらに経験を積まれ、より洗練されたチームビルディングのノウハウをまとめるために、大幅に改訂されたものです。

管理よりも演出

前著「プロジェクトを成功させる 現場リーダーの「技術」」を読んだとき、印象に残ったのが、

「管理(コントロール)よりも演出」

というキーワードです。

リーダー(マネージャ)の仕事は「管理(コントロール)」だと考えがちな人が多いように思います。しかし、思い通りにチームをコントロールできる天才的なリーダーなんてほとんど存在しません。
突然出てくる顧客要求や、使っていたソフトウェアの思わぬ深い問題、市場の外的要因など、プロジェクトの状況は時々刻々と変化します。
ソフトウェア開発に潜む課題なんていくらでも列挙できますが、過去の工業的な生産管理と違い、ソフトウェア開発の特殊性がさらに問題を複雑にしています。

  • ソフトウェアの構造は見えないものである。*1
  • 人海戦術など、リソースをかけても解決できないことが多い。
  • 作る人の生産性が数十倍のオーダーで違うことがある。

プロジェクトを進めるメンバーだって、すごくプログラミングの出来る人や、抜け目無いテストで能力を発揮する人、コミュニケーションに優れシステム全体のバランスを取れる人、様々です。

つまり、ソフトウェア開発プロジェクトを完全に管理(コントロール)するのは非常に困難といえます。
そんな中、うまく回っているチームというのは、調整のうまい人が仕様の落としどころを見つけ、すごくプログラミングの出来る人が素早くプロトタイプを示し、抜け目無い視点を持った人が品質を上げるなど、プロジェクトを前に進めるために、メンバーがうまく機能しています。こうしたチームは、ソフトウェア開発における数々のリスクに対応することができるだけでなく、メンバーの充実感も高いはずです。

ソフトウェア開発のリーダーに大切なのは、「管理(コントロール)よりも演出」なのです。

本書「ソフトウェア開発を成功させるチームビルディング」は、リーダーが行うべき演出のための考え方や、実践的なプラクティスがぎっしり詰まった一冊です。

チームビルディングはプロセスである。

リーダー(マネージャ)の中には、チームがある瞬間からいきなり問題解決したり、生産性が上がる「魔法の瞬間」狙いのイベントを期待しがちです。

  • 魔法の瞬間狙い
    • イベント頼み
    • 熱すぎる独り語り
    • 訓示病

実際、このようなイベントで、ブレークスルー的な効果は得られることは稀です。
リーダーは、じわじわと改善していく「ウーズスルー」を想定して、小さな仕掛けを、プロジェクトの随所で考えるべきです。
本書では、そんな「仕掛け」のための実践的なプラクティスが、目的や効果とあわせてたっぷり紹介されています。

  • 朝会の進め方と着目点
  • プロジェクトのキックオフ
    • キャラクタマップによる演出
    • パーソナル・ナラティブ
  • ふりかえり
  • 3Pフレームワーク(Pleasure Pressure Pride)
  • アクションかんばん
  • 会議
    • 議事録駆動のプロジェクト推進
  • トラブル解決のステップ

などなど。

こうしたプラクティスを自分のチームにうまく取り込んで、チームのプロセスにしてしまうことが重要です。もちろん、そのまま真似するということではありません。場面・目的にあわせて、適宜引き出せして応用できるような、プロジェクトの「習慣」「文化」にすることを目指すべきです。


リーダーシップは、才能ではなく「技術」である。

リーダーシップは才能ではありません。さらに、マネジメントの知識体系を学ぶことも大切ですが、それだけでは現場は回りません。
チームビルディングに必要なのは、日々の実践です。
本書で取り上げられているプラクティスのほとんどが、誰でも、明日からすぐに取り組めるものがほとんどです。みなさんのソフトウェア開発の現場でも、きっとヒントになるはず。
是非実践して、自分の「技術」にしてしまいましょう!

*1:自分たちで開発したソースは当然読めるでしょうし、オープンソースだとソースまで見える。見る努力をすれば見えないことも無い。しかし、メンバー全員が見えている場合はほとんど無いと考えて良い。システムのモデル化手法の普及など努力は進むものの、それ以上に規模がでかくなったりして、どんどん見えないものになってきていると思います。