親子ボードゲームで楽しく学ぶ。

世界のボードゲーム・カードゲームで遊び、家族でコミュニケーションしながら知育。おすすめの「初心者や子供でも楽しいボードゲーム」「大人でも楽しめる子供ゲーム」などライトなアナログゲームのレビューです。

デスマーチは続くよどこまでも。発注サイドからみた開発プロジェクトのこぼれ話。

私は仕事でシステム開発プロジェクトに発注者側として関わることがあります。

ソフトウェア開発と建設工事はよく似ているといわれますが、両方みてきた経験からしても確かに似ているかも。

長期にわたるプロジェクト体制が組まれ、そこには多くの関係者が関わります。

受注するのは大手企業でも、1次請、2次請は当たり前。最末端では「何を作っているかも分からない」ことも多いプログラマたち。かなり過酷な労働環境で働いています。最近では日本語がわからない外国人がオフショアでコーディングしていることも多いですね。

 

ただ建設業とソフト開発で決定的に違うのは、進捗が目で見えないところ。建設工事なら「もう3Fまで出来上がったな」と、素人目でもわかりますが、ソフトウェアはそうはいきません。

そのため、ソフトウェア開発の進捗管理は、コンサルティングファームなどからくるマネジメントのプロでも至難を極めます。

開発プロジェクトといえば、クライアントからの無理難題が雨あられと振ってくるなど、受注側からは大変という話が多いですが、発注側から見ても結構ヘンテコな状況が多いです。

というわけで、本日は開発プロジェクトの進捗管理の話です。

 

いつも計画どおり。パーフェクトな進捗管理の行きつく先は?

私が関わるプロジェクトでも、毎月「工程確認会」なる会議が開催されていますが、いつも「計画進捗率40%に対し40%で、予定通り進捗です」と、よくわからない報告が大半です。

40%って、いったい何だよ!数字化されたところで私のような素人にはさっぱりわかりません。一応内部では項目別の内訳はありますが、それを見てもどの作業がどれだけできているのかサッパリです。

 そして、毎月の進捗はほとんど計画通りという内容で報告されます。そんなに毎回キッチリ予定通り進捗するなんてありえないだろと突っ込みたくなるくらい。

 

形式的には計画通りでも、実際は乖離していて、いつかボロがでてきます。毎回順調なはずだったプロジェクトスケジュールは、ある日突然破綻します。

 f:id:bg4kids:20180124124002j:image

 スケジュール遅延の理由は言い訳のオンパレード

報告上は今回発生した事象で遅れたことになっているけど、実際は溜め込んできた遅れを吐き出すもんだから、進捗遅れの理由はまったく理由になっていないものばかり。

 

顧客からの仕様追加も時には救世主?

「先日クライアント様よりご依頼のあった追加仕様のため、工期が2ヶ月ほど伸びることになりました。」

「え?帳票レイアウトをちょっと変えるだけでしたが、それでそんなにかかるとは。じゃ、仕様変更はやめときます。」

「いえ、せっかくいただいたお話です。ご満足いただけるよう、最善を尽くしてやらせていただきます。」

「いやいや、早くできる方が大事なので、余分なことを言って申し訳ない。変更の話は忘れて計画通りで頼みます。」

「あ、いや、工期の方は・・・・別の案件もございまして」

 

顧客からの追加仕様は仕事が増えるので困り者ですが、他の進捗が遅れているときはありがたい。ここぞとばかりに顧客ニーズとして遅れを吐き出します。

 

法令改正対応は必須だけど…

「このたび法令改正に伴って仕様変更が必要となり、工程が遅延する遅ことになります。」

「そうですか。法令には対応しないわけにはいかないので、仕方がないですね。」

「なにぶん法令対応ゆえコンプライアンスにも関わる話ですし、当社としてもきちんと対応させていただきます。」

「ちなみに、どんな法令改正の影響ですか。」

「いや、その…。新元号の対応でございます。」

 

新元号になるなんて、かなり前から分かっていたじゃないか!

というか、これから開発するシステムに、元号依存で作るのはやめてくれよ…。

 まぁ、法令・規則対応は言い訳の鉄板です。

 

突然の海外逃亡?

「今回の遅れについてですが、誠に弊社の勝手な事情ですが、当該機能のコア担当者が急遽新婚旅行に2週間行くことになり、作業が停滞したためでございます。」

 

「突然の新婚旅行」ってなんだよ!

内部リスクも考慮済のプロジェクトスケジュールに、社員の個人的な都合を持ち込むのはそもそも論外ですが、病気や身内の不幸など、もうちょっと同情を誘う理由にしてほしいところ。でも、身内の不幸はちょっと前にも 使っていたなぁ。

もはやズル休みの理由のようになってしまっています。

 

消えたあいつはスーパーマン

 「開発を実質的に切りもりしてきた責任者のAが、転職してしまいまして・・・」 

「先日過労で休職してしまったBは、複数領域に関わっておりまして、引継ぎが十分にできず大幅な手戻りとなってしまいました。」

 

いない担当者のせいにするのも常套手段。責任の取らせようがないわけですから誰も痛みません。

 しかし、こんな時はなぜか「そんな担当者いたっけ?」という知らない名前の人が重要分野を担当していることになっているから不思議です。

 

 ニワトリが先か卵が先か

「経理システムでは、購買システムからの連携データの仕様が決まっていないため、検討が遅れています。」

「購買システムでは、経理要件の遅れにより、システムの仕様決定が遅れている状態状況です。」

 複数分野がクロスする領域は、お互いが相手に遅延の責任を押し付けます。

縦割り組織の会社ではよく、開発ベンダーが噛み合わない顧客の部門同士の要求に振り回されるもの。さらに、大規模ということで開発主体マルチベンダー開発となったプロジェクトでは、ベンダー同士でも押し付け合いが発生します。

楽な仕事は奪いあい、面倒な仕事は押し付け合う、守備範囲の攻防はなかなか熾烈でした。

 

進捗遅れのリカバー方法も斜め上 

遅延原因も言い訳じみているなら、その対策もなかなか対策になっていないものが多いです。

 

間に合わぬなら、ゴールを変えようホトトギス

「今月までにシステム設計が終わる予定でしたが、今回フィージビリティを踏まえて変更し、今月を要件定義終了フェーズとする計画としました。これにより進捗率は改善し、計画どおりの進捗となります。」

 

フィージビリティとか横文字を使いつつ、20km地点が折り返し地点だったのを、15kmを折り返し地点にしただけ。マイルストーンは変更できてもゴールの42.195kmは変わらない…。果たしてこれで完走できるのか?

 

マルチタスクでスピードアップ?

「来月より、Aは会計と人事、Bは販売と購買と、複数タスクを担当することにいたしました。擬似的ではありますが、一人が複数の機能に携わることで、開発スピードを加速させます。」

 

シングルタスクで遅れているのに、マルチタスクなんてできるわけありません。

こういう対策の後は、体制がぐちゃぐちゃになって余計に収拾つかなくてなってしまいます。おまけに責任の所在までぐちゃぐちゃです。

 

工程のオーバーラップ

「開発工程から、机上でテストを開始させていただきます」

「単体テストと総合テストを並行して実施することで工程短縮を図ります。」

 

建設工事でいけば、「基礎工事と屋根を張る工事を並行してやっていきます」というようなもの。

実際に動くかどうか確かめるためのテストを完成前にやっても…。こういうケースでは実際に動いてから不具合が続出します。

 

テストや教育などの下流工程の切り詰め

「弊社のシステムは信頼性が高いシステムですので、テストケースの絞り込みが可能と考えています。これによりテスト期間が大幅に短縮できる見込みです。」

 「充実したマニュアルがございますので、導入周知・教育の短縮が可能と考えてスケジュールを見直ししました。」

 

テストや移行など、最後を切り詰めて帳尻合わせする開発工程は、運用開始後に悪夢が待っています。運用開始後の修正作業続出し、システムサポートの電話が鳴り止まない。

こうなってしまったら、運用開始前にプロジェクトから足抜けすることが、唯一の逃げ道かも。

 

工程管理の嘘は起きるべくして起きる

なぜこんないい加減な遅延理由ばかりなのか。これには開発プロジェクトの構造上の問題があります。

 

  • 正直に遅れを報告すると、原因分析と対策を詳細に要求され、そのための作業が増えて手がとられ、さらに遅れるという悪循環。

 

  • 正直に進捗が良いことを報告すると、「じゃ、これもお願いしよう」と、追加的な要件が降ってきたり、要員を引き抜かれて遅延部隊の応援をさせられたり、貯金の強制放出が要求。

 

というわけで、進捗は計画通りか、ちょっと遅延くらいで報告するのがいいというインセンティブが生まれます。

 

また、原因究明対策についても

  • 本質的な原因は、たいていが要員、スキル、時間、資金などのリソース不足によるミスやキャパオーバー。
  • リソース不足を正直に言うと「開発体制やチェック体制を強化してくれ」とクライアントから言われてしまう。
  • でも、本当に体制を強化していたら受注が赤字になってしまうので、会社が許可しない。クライアントも安易な予算増額はしてくれない。

 

という理由があるので、クライアントから「バカだ」と思われても、そちらの方が実害は小さい。自衛のためにこじつけ理由と形ばかりな対策を報告するわけです。

 

こんな茶番の工程管理のなかで、真実の状況を把握して、立場の異なるクライアントとベンダーを通訳しながら調整。正しくスケジュールを軌道修正するのがプロジェクトマネージャーの役割。なかなか大変な仕事ですね。優秀なPMは、工程会議や報告書類の情報を信用せず、飲み会や喫煙室、給湯室などでの愚痴も拾って状況を把握するとかしないとか。

マネジメントがダメなプロジェクトはどこかで破綻。顧客は「今まで順調だったはず。全く聞いてない」と工期延長や予算増額を認めないわけです。

結局その尻拭いをするのは一番立場が弱い現場の開発部隊。こうして短納期、少ないリソースでの開発となり、いわゆるデスマーチは起きるべくして起きるわけです。

 

騙しているのは誰で、一体誰が騙されているのか、それとも騙されたフリをしているのか。そんな嘘と欺瞞と責任のなすり合いに満ち溢れた、システム開発プロジェクトの工程確認。

次回はこれをブラックユーモアたっぷりにカードゲームにした「Not My Fault!〜俺のせいじゃない!」です。

www.boardgamepark.com

 

Not My Fault! ~俺のせいじゃない!~

Not My Fault! ~俺のせいじゃない!~