こんにちは、すみです！
今回は、私のプロジェクトマネジメントの失敗談をもとにして、他の方が失敗しないためのヒントをプレゼントできればと思います。
※今回は長文になりますのでお手洗いに行ってから読んでいただくことをオススメします（笑）
何を隠そう私は、数々の失敗をしてきました。
私は、年々難易度の高いプロジェクトに任命される傾向にあり、それが自分にとって未経験なものでも「やります！」といって引き受ける人です。
その結果色々な失敗をするわけですが、あるとき考えました。こんな私が世の皆様にお役に立てるサービスってなんだろう？と。
それが今回の「失敗事例の共有」です。
ここで、失敗事例の共有の前に、なぜ私が失敗に着目したか？についてもう少しお話しさせてください。
目次
「勝ちに不思議の勝ちあり、負けに不思議の負けなし」
この一節をご存知でしょうか。これは、東北楽天ゴールデンイーグルスの名誉監督、野村克也氏の座右の銘で、とても話題になったフレーズです。
負け、すなわち失敗には必ずその原因があります。つまり、失敗がわかれば、その原因をつきとめることができ、その対策を行えば失敗しないという理屈です。だから、失敗を知ることは有益なことだと考えています。
また、
「チャレンジしての失敗を恐れるな。何もしないことを恐れろ。」
これは本田技研工業の創業者、本田宗一郎氏の言葉です。まさに、失敗とは何か？を考えさせられる一言です。この言葉の通り私は、本当の失敗とはチャレンジをためらうことを指すのではないかと思います。失敗しても成功するまで諦めなければそれは成功なのです。だから、このブログを見ていただいている方には、私の失敗を見ながら私の屍を越えていただき、もっとチャレンジしていただき、もっと良い失敗をして、その先の素晴らしい成功をしていただきたいと願います。
前置きが長くなりましたが、本題に入ります。
失敗事例
■プロジェクト概要
これは私が携わった直近のプロジェクトです。2016.12～2020.3までの3年強の大きなプロジェクトでした。対象システムは、簡単に言うと現場の端末の動態を管理し指示データを送って配車するシステム、端末はMAX3000台、 3つのサブシステムに分かれます。私はそのサブシステムのうち1つのリーダー、開発委託先がありそこのリーダーや開発者が総勢約15名。その他にもサブシステム毎に会社がいます。開発委託先はそれぞれ遠方。開発はウォータフォールで進めました。顧客は全国に拠点を持ちキーマンが週に2日各地から集まります。顧客側にはコンサルがついており業務フローを作成しそれが当社へのインプット情報となりました。
■要件定義
・インプット情報不足でスタート
顧客から提示された業務フロー。分岐が少なく基本形の一部しか書かれていないようでした。顧客へ指摘するも、顧客側はこれで問題ないと押されてそのまま要件定義がスタートしてしまいました。
・長い会議と膨大なドキュメント
要件定義の会議は、顧客側の全国のキーマンが週2日で本部に集まりそこに私たちも同席し終日行います。またそれ以外の3日は資料作成です。当然このような工程だとゆっくり考える時間は皆無。納期もあるため、とりあえずできた（風の）資料を持参して会議しながらその場で考えながら進めました。当然検討不足を指摘され、終日指摘され続けるメンタルはボロボロになりました。
・怪しい派遣社員
ここで、当社側の要件定義を一緒に行うメンバーは、私、2年目の社員、派遣社員の3名。2年目の子には議事録をお願いし、派遣社員には資料作成や中身の検討をお願いし、私は顧客への説明をしました。しかし、この派遣社員、そしてこの会社は、（抽象的な表現ですが）本当に不誠実でした。詳細は割愛しますが、言動や態度がもう…。要件定義も中盤に差し掛かるところで、決断。その会社を要件定義途中で切ることにしました。その結果、これまで任せていた部分を巻き取るだけの時間も十分にとれず会議では顧客からのクレームの嵐。でも先輩にも助けていただきながら要件定義の終わりまでもつことができました。
※今振り返っても、当時苦労はあったが先を見越してこの会社を切り替えたことよかった。勇気も必要。
■設計
・顧客との長時間会議と膨大な設計書
設計フェーズに入りました。これまた顧客との週2日の会議継続です。設計書を書くことで手一杯で検討不足でした。会議の前日は徹夜で30部くらいを印刷してました。このような中で時間もなく、画面と帳票しか検討出来ませんでした。本来やるべきシステム機能としての振る舞いやデータパターン、異常系の検討が不足していました。
・開発委託先との長時間の会議
顧客との会議以外では、当社内での設計会議を週1回、全開発委託先の3社も集まって行いました。会議では、朝から晩まで行われ、話は発散し疲弊、エビデンスがなく、参加者の認識の中で進むという状況でした。
・開発委託先との距離の問題
遠距離での開発管理はこちらの意図が伝わらず苦戦しました。一から十まで指示するも限界で、途中からは私が現場へ乗り込み張り付きました。
※Skypeも使っていましたがこの後の「能力不足」の通り現場に行くしかなかったのです…。
・能力不足
悪の元凶の一つ、開発委託先のリーダーの能力不足。50代後半の方でしたが、WBSという言葉を知らず、担当者への指示は統一ルールも決めず担当者任せ。当然このような状況で且つ設計書も十分ではないので、設計の意図を理解して進めないと見当違いのものになってしまいますが案の定なってしまいました（泣）途中から方針を変えて私がすべての担当者とコミュニケーションをとって指示出しをすることにしました。朝から深夜まで指示の繰り返し。このスタイルは開発フェーズも繰り返されました。
■プログラム開発
・開発途中の人員離脱
設計は遅れました。遅れによる期間の延長にて、その会社で派遣だった人が契約期限切れで途中で抜けることになった、というのです。まじか！？延長するよう話しましたが止められず人員入れ替え、ノウハウゼロからの辛い状況でした。
※あれ？開発委託先には請負責任があるんじゃないか？担当者を引き留めなかったの？と、疑問があると思いますが、通常の考え方は持ち合わせていないようで、昔ながらの小さな会社だったのです。
■テスト
・疎通すらできないシステム
サブシステム間の疎通ができず基本動作すらしないテストの幕開けでした。設計フェーズの議論のあげくエビデンスが残せていかなったので、各サブシステム間のインタフェースやシーケンスが各社の思い思いのものになっており、正常系すら通らない残念な状態でした。
・収束しない欠陥
ある程度動くようになると、次は正常系のテストで欠陥が多発しました。直しても次から次へと欠陥が出てまさに「モグラ叩き状態」。欠陥はRedmineで管理しましたが、途中から発行するのが嫌になり一旦開発委託先に見直してから再度出すように命じました。ここから先、全部の欠陥を直す時間がないと判断した私は、欠陥を機能別に分けて優先順位をつけて対応、テストもできた機能から順に実施するように流れを変えて少しはましになりました。
・未実装の発覚
あと、忘れもしない未実装事件。これは手抜きですね完全に…。私たちはソースレビューと強化テストを行いフォローすることで挽回しました。もちろんこのようなフォローは予定しておらず他の作業が止まりましたが…。
・デグレ、デグレ、デグレ
直してはデグレを繰り返しました。機能別、開発担当別の欠陥数を見える化したところ、ある開発者の欠陥発生数に偏りがあることがわかりました。でも開発者を途中で変えられずそのまま継続、ただしフォローを厚くしました。内容は、開発着手前に処理設計のレビューと単体テストケースの洗い出しを行いそれから開発するようにしました。このテストケースを先に考えるやり方はテスト駆動というもので有効なので他の開発者にも適用しました。
※とはいってもやってくれない人もいました。みんな忙しすぎて…
■運用テスト
・全国での運用テスト
運用テストは、全国4ヶ所を順に3日ずつ行う予定でスタートしました。前述のテストの欠陥も全部直し切れずのスタートでした。
・１日も運用に耐えられないシステム
最初一か所目は、半日でシステムが止まりました。欠陥でした。その後、現場張り付きで修正、3時間後にリリース、テスト再開。しかし、また停止。失敗に終わりました。
・サービスインの延期
最後の4ヶ所目、この時点でサービスイン2週間前でした。しかし、システムは3日もたず停止。これで、サービスイン延期が決定しました。
■再計画、半年後に再度、運用テスト
・再・運用テストの開始、しかし…
半年後に運用テストが開始しました。今度は４箇所毎ではなく全国4カ所一斉に行うテストにハードルがあがりました。テスト開始から3日が経過、稼働中！しかしその後異常が発生し、瞬時に原因を特定できず復帰の目処が立たないことからテストは中止となりました。原因はサブシステム間でのデータベースのロックの考慮不足でした。
・残り2週間、再テスト、しかし…
再計画後のサービスインまで残り2週間、運用テスト開始、しかし、あるサブシステムからの通信トラフィックがあがると同時に、サーバーが端末からのデータをさばききれず、停止、テストは中止。その後は徹夜で解析しました。
・土壇場での構造設計変更
各サブシステム連携からのトラフィック増加に耐えられるようソースを確認し設計を変更。プロセスを分割して負荷分散する構造にすることで決定（この時期に超リスクだが決行）しました。
・残り1週間、再テスト、そして…
これまでの停止が嘘のように稼働。そしてようやくサービスイン決定しました。運用が始まりました。
■あとがき
いかがだったでしょうか？
実は、運用が始まってからの話も色々あり、仕様かバグかのグレーゾーンにおける顧客との攻防などなど、この辺は長くなるので一旦割愛しましたm(__)m
このようなプロジェクトの状態で、サービスインまでもっていくのは、正直机上の知識だけではどうにもならないことを痛感しました。
特に「人」を動かすことが難しくとても苦労しました。私としては、納期もあるのではっぱをかけて指示をしていましたが、そうすると逆に人は動かないんです。最終的に動いたのは、一人一人の思いに寄り添い、励まし、助けて、導く、ということでした。嘘のようですが本当の話しです。これは、このプロジェクトにおける、私の一番の教訓となりました。
それにしても、このプロジェクトの期間中、私の残業時間は月平均60時間（としておきます…）と、いわゆる長時間労働で、家族と過ごす時間があまりにもなかったことが本当に苦痛でした。子供も小さいので余計に。
正直疲れ果てましたね^^;
でも、終わらないプロジェクトはないってことも身をもって体験しました。心身共にボロボロでしたがファイテングポーズさえくずさなければ、周りが助けてくれました。だから、このような経験を伝えたいと思い、このブログ「森のすみ家」のサブタイトルに「明けない夜はない」と入れて、このブログを読んでくださる方へエールを贈る意味を込めることにしています。
私は思います。このような暗黒プロジェクトがこの世から一つでもなくなり、一人でも多くの人が幸せな暮らしができることを。
また、私自身もそこに貢献できるように、日々自分のスキルアップと共に、これからの人材の育成にも尽力したいと思います。
ここまで読んでくれた方には本当に感謝いたします。
ありがとうございました。
では、また！
コメント