「刺身」なプロジェクト

前職で、複数多数のプロジェクトフェーズ、タスクが異様に縦にCascadeした並行作業状態を「サシミ」と呼んでいました。最近またそういうプロジェクトに出会う機会が多くなり、現象分析と改善の処方箋について、いろいろ考えています。

「サシミ」の語源は、私は「刺身」と理解していますが、OB含め同僚と意見交換しているうちに説が２つあることがわかりました。

１）料理屋で、刺身がお皿の上で斜めに並んでいるかのようにCascadeしているから「刺身」
２）身を刺すように「痛い」プロジェクト状態だから「刺身」

ずっと１）だと思っていましたが、２）の説を初めて聞いた時は不謹慎ですが少々笑ってもしまいました・・・

「刺身」プロジェクトで一番リスクなのは、いうまでもなく設計、製造、テストの工程が並行になっているがゆえの手戻りの多さです。
大体、前工程が遅れると自動的に全ての後工程は遅れます。
結合対象の単体１つが遅れても結合テスト以降は遅れるわけで、

或るプロジェクトで、稼動前日まで単体テストをやってそれを結合・総合・本番環境テストと同日にエスカレーションしなければならない状況に遭遇しました。楽しくはなかったですが、24時間、それまでに味わったことのない緊張感を持続し、奇跡的に翌日稼動しました（その翌日はすごい落ちまくりましたが・・・）。

・・・どうみても良さそうにできているからこのまま結合はスキップして本番環境へロードしちゃおうか？
・・・いやいや、いっそデバッグが全部終わったことにして、本番環境でとりあえず稼動させちゃおうか？？

ほんと、よろしくない誘惑に一日中かられてました。。。

・・・暴露すると「スキップした」経験は結構あります（・・・ゴメンなさい・・・）。

でも、勝率（？）は別の投稿にも書いた内容に似ていますが、結局経験でエイヤ！と判断した結果は半分くらいしかうまく行かないのです・・・

本当の処方箋は「Cascadeをするな」かもしれませんが、私に来る依頼案件周辺でみえるのはCascade前提のプロジェクトばかり。

１） 最初からどこまでCascadeしてたの？
２） 途中からCascadeし始めたんだったら、それはどうキャッチアップするつもりなの？
３） Cascadeした部分はどう各フェーズが連携して、その状態においてもリスク軽減できるよう運営できるようなクリティカルパスになっているの？
４） ・・・って言うか、そういう事態に対応できる体制に全体的になっているの？？
５） 頑張ったらCascadeの割合が改善する可能性はあるの？？
６） 頑張ったけどうまく行かない場合のCP（コンティンジェンシープラン）やBCP（障害時の業務継続手順）は考えなくていいの？？
７） プロジェクトメンバーには今まで以上の「修羅場」に備え、モチベーション向上策を対処してあるよね？？
８） ステークホルダー、プロジェクトオーナーは各社の責任はどうあれまず事実を正確に理解して、全面的に協力する説得をしてあるよね？？？
９） 当初より品質面の妥協を前提に進めるつもりだよね？？
１０） 他にも・・・具体的に、何か隠し事って、もうないよね？！

最近、さらに、うまく進行できていないプロジェクトからの「レスキューコール」が増えていす。大体において、まず上の１０項目、関係者に聞いてみますが、半分以上は何も考えられていない、対処が中途半端なケースばかりです（泣）・・・

皆さん、頑張りましょう！！