はじめに

皆様、こんにちは。
佐久間まゆちゃんのプロデューサーの@hiroki_tanakaです。

私は新卒で大手独立系SIer入社し4年間、BtoB向けの大規模基幹システム構築プロジェクトにいくつか携わりました。
(今はWeb系スタートアップに移り、自社プロダクトの開発を行っています。)
それぞれのプロジェクトに特徴や個性はありましたが、全てに共通して言えることはどれも大変で計画通りの完璧なプロジェクトはありませんでした。
そんな中で『アドレナリンジャンキー~プロジェクトの現在と未来を映す86パターン~』という有名なプロジェクト管理の本を読んだのですが、非常に参考になったのでまとめました。
(私のように開発現場で戦っている人の少しでも役に立てれば、と思っています。)

『アドレナリンジャンキー~プロジェクトの現在と未来を映す86パターン~』とは

『アドレナリンジャンキー~プロジェクトの現在と未来を映す86パターン~』は2009年に出版されたソフトウェア開発のプロジェクトによく見られる86のパターンを抽出し、失敗に向かう兆候や逆にうまく回っている特徴を紹介した本です。
著者は5人のエンジニアで中には『ピープルウェア』や『熊とワルツを』で有名なトム・デマルコとティム・リスターもいます。
この本はプロジェクトマネジメントの本のため、読んでもコーディングスキルをはじめとする技術的な知識は殆ど身に付きません。
また、86のパターン1つ1つはどれも2〜3ページで紹介されているため、非常に読みやすいです。

開発プロジェクトのアンチパターン

アドレナリンジャンキー

アドレナリンジャンキーなプロジェクトは猛烈に動き回ることが健全な生産力のあかしだと信じている。
アドレナリンジャンキーなプロジェクトの特徴は、優先順位が絶えず変化する。すべては「きのう」必要である。納期までの時間が足りた試しがない。タスクは全て急ぎだ。次から次へと緊急のタスクがやってくる。誰もが猛烈に忙しい。それも、いつも。

私はいつも炎上プロジェクトに身を置いていたため、アドレナリンジャンキーなプロジェクトには心当たりしかありませんでした。
アドレナリンジャンキーなプロジェクトではメンバは物事を戦略的に考えなくなっていきます。緊急性のみを基準にタスクを行うようになります。
長期的に見れば得られるものが大きくても現在のタスクは緊急度が高くなければ、後回しにされます。
そして、その後回しにされたタスクはある日降って湧いたように緊急度が高くなり、その時になって初めて着手されます。
メンバが戦略的に考えず、短期視点のみでシステムを構築していくとアーキテクチャからソースコードまで暫定対応が多くなり、プログラムのエントロピーも増大し、拡張性・保守性の乏しいシステムとなります。
アドレナリンジャンキーなプロジェクトは緊急度の高い切迫した事態に対応することを、みごとな機動力と勘違いしていることが多く、それによってますます自制が効かなくなります。
アドレナリンジャンキーなプロジェクトの治し方は、いつも緊急事態ではプロジェクトは最大限の成果をあげられないと理解しているマネージャーを据えるしか方法がないと思われます。

アトラス

チームリーダがあらゆることに長けている。
彼女はリーダに求められていることは殆ど全てやっている。ただ1つのことを除いては。
完全なリーダでありマネージャーであるために、重要なリーダやマネージャーの仕事を何一つチームメイトに任せないのだ。
その結果、メンバをリーダーとして育てていない。

チームの最も仕様を理解し、技術が分かるリーダに全てが集まってきて、メンバに意思決定させるのではなくリーダが全ての意思決定を行うという方法は、
往々にして少人数の時はうまく回ると思います。
ただ、同時に以下の3つの問題にぶつかると思います。

上記の通り、将来のリーダであるメンバの成長機会を奪ってしまっています。そのリーダの元では永遠にメンバからリーダになれる人がいません。
少人数の時は上手くいくかもしれませんが、スケーラブルではありません。100人のチームの全ての意思決定に関わることはどんなに優秀なリーダでも不可能です。そのため、そのリーダは大きな仕事ができません。
リーダが突然いなくなった場合にプロジェクトが立ち行かなくなります。

「野球に泣くなんてのはないんだ」

感情を表に出すことを否定する文化は対面を水面下に潜らせてしまう。
知的労働業界の多くが、職場で感情を表に出すことは許されないという不文律を採用している。
気に入らない決定を知って、会議の場で泣き出したり怒りを爆発させたりした人はプロらしくないと切り捨てられてられる。
しかし、感情の発露を許すかどうかを判断する際は、仕事を大事にしていなければ仕事に感情が入り込むこともないということを覚えておくと良い。

ソフトウェア開発は別業界・業種から見れば感情とは無縁な仕事に思えますが、実際は感情が高ぶることも多く、関係者以外には到底理解できないようなものに情熱的になります。
そのため、もし職場での感情の発露を不許可とし、感情の排除したいならば、仕事のことなど気にかけない人材を採用すれば解決します。
しかし、それではプロジェクトは失敗してしまうと思います。
自分の仕事に情熱的になれる人をプロジェクトに投入することは、成功の秘訣です。
感情や情熱は時に爆発することもありますが、その後始末くらいはプロジェクトの成功という高い目標の達成への代償の一部だと思います。

おわりに

本書を読んでパターンを暗記するや知識とするのではなく、様々なパターンに触れて開発現場での直感を磨きたいです。
「このままだとあのパターンに入りそうだ…止めるためには何が出来るだろう？」や「もっとこうすれば、あの成功パターンになりそう。」と考えられるようになりたいです。
次の記事では成功パターンに関して書きたいですヾ(`･ω･´)ﾉ