エンジニアのジレンマ ~悩む立ち位置と仲間の境界~

第3回 プロジェクト炎上を防ぐには

この記事を読むのに必要な時間:およそ 2 分

プロジェクトは生き物だ

システム開発に携わったことのない方はたくさんいると思いますが,プロジェクト※1に携わったことがない人はいないでしょう。

プロジェクトなんて普段関わることもないと思っていても,私達の周囲はプロジェクトで溢れています。身近な例では,社員旅行やゴルフコンペ,新商品の開発やセミナーの開催もそうでしょう。プライベートな面では,旅行を企画する事や子供の受験もプロジェクトと言えます。

プロジェクトは,メンバーの能力やモチベーション,性格,とりまく環境,運等の要素が複合して「予定が狂う(ブレる)」のが特性です。今回は上手くいったなぁ,ちょっと失敗だったなぁ,とプロジェクトが終った際に考えるのはブレるからです。例えば,企画した旅行のホテルや食事,観光地が期待外れだったり,思ったよりも良かったという経験を持っているでしょう。

もちろん,システム開発もプロジェクトです。ただし,ブレが尋常ではありません。しかも,上手くいくときはブレが小さく,失敗した時には大きくブレるからタチが悪い。ブレがブレを呼びどんどんと大きくなっていきます。

今回は,大きくブレたプロジェクト(これはもう炎上と表現したほうが適切でしょう)について,考えてみたいと思います。

※1
プロジェクトとは,ある目的の元に一定の期間集まったチームの事を指します。プロジェクトではない活動の多くはルーチンワーク(決まった作業)です。

悲劇はある日突然やってくる

ある日,その出来事は起こりました。筆者が担当しているプロジェクトで「納期が明らかに間に合わない」と複数のメンバーがギブアップしたのです。その2週間前には「厳しいけど何とかします」といった報告を受けていたため,筆者は目の前が真っ暗になりました。

実際にその報告後,事態は急激に悪化し,その日を境に半年間は休み無しで毎日深夜まで働きつづけ,メンバーも10倍以上に膨れたのですから,その日はXデーといえます。最初から参加していたメンバーからは筆者に騙されたという声も聞きました。

今でも,この出来事は筆者のエンジニア人生における教訓であり,活動の指針にしています。

炎上前の伏線

この状況に至るまでの経緯をかんたんに説明してみます。

このプロジェクトは,お客様から弊社に期待しているから短納期でお願いしたい。そのかわり設計終了時に再見積り可能という条件をつけるというものでした。

筆者は他にも複数のプロジェクトを抱えていた上に,得意なシステム分野でありませんでしたが,別に自分が全てする必要もないし,優秀なメンバーをアサイン出来ればやり切れるだろうと安易に考え,何となく違和感を覚えながらも,思考はそこで停止しました。また,幸いにも優秀なメンバーをアサインできる状況もありました。

画像

しかし,プロジェクトを進めていくうちに,筆者は言葉に出来ない不安を持ちました。

「打合せにも半分以下しか出れないし,システム仕様もほとんど理解できない。何となく難しくなっているように感じる」

不安を持ちつつ考える事を止めてしまった筆者には,メンバーに「どう?問題ない?」と聞くしかなく「大丈夫と言って欲しいオーラ」が出ていたと思います。何かおかしいなと思いつつも,上司にも問題を理解していないから,報告できない。それでも,最後の切り札「設計終了時に再見積り可能」が残っていたため,その時点で整理すれば良いと思い,不安を意識的に忘れるようになっていきました。

その後,再見積りを実施しましたが,システム仕様をあまり理解しておらず,「大丈夫といって欲しいオーラ」が出ている筆者に,見積前の前提条件と設計完了後の差異について評価できるわけがなかったのは言うまでもありません。

最後の切り札「設計終了時に再見積り可能」が無意味に過ぎ,程なくしてXデーを迎えました。一度ついた火は,バックドラフト※2のように次々と燃え広がります。炎上したプロジェクトの当事者になり,その後は目の前の火を消す事だけに必死でした。

※2
火災の現場で起きる爆発現象。ユニバーサルスタジオジャパンに映画「バックドラフト」のアトラクションがある事で有名です。

仕事内容に対するジレンマ

本プロジェクトの炎上は,「自分は忙しいし,他の人をアサインしたので大丈夫と思いたい」といった心理状態から引き起こした事は間違いありません。また,プロジェクトのリーダ格の人が思考を止めると,失敗する確立は大幅にアップするのは当然でしょう。

あわせて,上位責任者がいた場合は,ラストマンとしての自覚が薄れ,思考は停止しやすくなります。「自分で全てを理解して,全て判断したい」と思いつつも,時間的制約や能力的制約を受けた場合,どうしても他の人に任せないといけませんが,それによりプロジェクトの中身が分からなります。よって,自分の得意分野以外の仕事は極力やりたくない。でもやるしかない※3)。そんなジレンマをリーダーは持っているのではないでしょうか?

※3
自分の得意分野の仕事は多少複雑になったり,時間がとれなくても,プロジェクトの勘所(キモ)は経験で分かるものです。リーダーよりもメンバーの方がプロジェクト全体を把握している場合は,状況判断がしにくくなります。特に自社が弱い分野で外注会社に委託しないといけないようなプロジェクトは,リーダは大きなジレンマを持ちがちです。

自分が全て理解していないプロジェクトで炎上を防ぐには

全部自分が見ないと仕事が出来ないのでは,仕事を許容できる量は大幅に減り,大きな仕事は出来ません。また,自分の得意分野だけが常に仕事としてあるわけではありません。

失敗を皆無にする事は無理としても,せめて炎上を予防するには,どのようにすべきと思いますか?

最近では,多くの会社でプロジェクトマネージメントオフィス(PMO)という制度を導入し,プロジェクトマネージャの孤独を軽減するような方式も取り入れているようです。

それも重要ですが,私は「理解する事をあきらめない」ことを行うようにしています。 プロジェクトを行っていて,理解出来ない事は誰かに任せますが,その人の話を聞いてみて理解する事をあきらめないようにするのです。

それでも全て理解できるわけではありません。むしろほとんど理解できない事のほうが多いと思います。理解できないなりに質問をして,相手の理解度を確認しています。

これは,前回の「ラストマンとしての自覚」で述べた事にも繋がります。分かっていても難しい事ですが,「今,考える事から逃避したな」「一生懸命分からないなりに考えているな」という感覚で,プロジェクトの局面を自己チェックする事をお勧めします。

著者プロフィール

森平也寸志(もりひらやすし)

システムエンジニア経験が18年。資格としては,PMP Project Management Professionalや情報処理技術者試験(システムアナリスト)などを保有。

これまで数十人のプロジェクトマネージャから少人数での中小向けシステムの導入等の経験がある。過去には自身が担当するプロジェクトで数億の赤字プロジェクトも経験済み。SEがシステムを構築する際には,常に失敗との背中合わせである事を痛感し,お客様との関係や自社の営業との関わり方を日々考えている。

コメント

コメントの記入