五郎丸選手のルーティンにみるここ一番で失敗しないための２つの対策

システム開発をしていて「ここ一番の失敗できない場面っていうのはどこだろう」なんてことを「選「無心で蹴りぬく ラグビー日本代表 五郎丸歩」」の五郎丸選手のルーティンを見ながら思っていたんですね。

最初に思いついたのはデータセンタでの本場切り替え作業でしたが、実際は、結合試験などのシステム的に連携するときかなぁ、と。いやいや、負荷試験もじわりとメンタルにくるし、移行リハーサルなどでの手順もドキドキ感も忘れられない。いやもっと前の一番最初のデータセンタでの作業は割とお作法がわからないところで作業をするケースもあってそこが最初の壁だし、とつらつらと並べてみるんですが、皆さんはどこの場面で失敗したくないと思いますか。

そんなことを考えて思い当たったのは、要件定義のような外部レビューとか日々の進捗や個別検討などの会議の場こそ失敗したくないと思うかもしれないなぁということ。結局、その場の当事者になる場面で失敗したくないんだよなぁ、と身も蓋もないことだったり。

仕事での失敗には２つの種類があるんですよね。１つはチームとしての失敗。２つ目は個人としての失敗。

チームとしての失敗は、ときどき書いていますが、作業プロセスに起因する失敗です。手順書が間違っていて操作を誤る、手順ごとに操作する人に理解と判断を求める手順とか抑止力のないチェックリストのどうにゅうなどなど。誰か一人の技量に由来するものではなく、誰でも失敗する可能性を秘めているもの。

２つ目は、個人の技量に由来するもの。技術レベルが足らず設計で要件を見落とす、手順通りにやれば失敗しないところを個人の浅はかな思い込みで判断ミスをするなどなど。これらはいくら正しい作業プロセスや手順を作成していたとしても、個人がそのレールを踏み外すために引き起こされるからどうしようもない。いや、再監を置くとか作業前後で連絡がないと先に進められないとか色々工夫することで予防はできるのですけど。

プロジェクトマネージャや技術リーダの立場であれば、この両方を見極めて失敗したくない場面で失敗しないための手を打っておきたいと思うのは当然のことだと思います。

プロジェクトマネージャが失敗したくないと思っているのは実はプロジェクト中は常時ですが、大別すれば対外的に見える作業、つまり、報告する作業では絶対に失敗したくないし、開発チーム内で閉じている作業であれば辻褄が合っていればいいくらいに思うんじゃないでしょうか。そのくらいメリハリはつけたくなるしメリハリをつけられないようなプロジェクトはそれ相応に覚悟を決めてやるでしょうし。あぁ、この作業が失敗すると「手戻りがあそこまで…」のような作業は前者に含まれますね。

それで「ここ一番で失敗したくない」をどうやって実現するかですが、次のように考えるといいと思います。

・チームメンバ一人ひとりの技量を知る
・手順は全員でレビューさせ、書いてある手順にその都度理解させたり判断させない作りになっている
・メンバに個別環境で習得させる
・習得時に作業時間を計測する
・作業プロセスには一人の判断で進められないゲートを設ける

結局、ここ一番で失敗したくないという「作業の主役は誰か」で考える他ないんですよね。人手がなくて例えプロジェクトマネージャが入るとしても、作業プロセスや手順は主体者のメンバが考え、間違いを見つけ、正しいプロセスに載せないといけない。

そのプロセスに載せるとしても、考え、対処するのはあくまでもメンバなのでその気になってもらわないといけない。それってこのあたり（youtubeへのリンク）　の手順の確立を当事者のメンバに作ってもらわないといけないということです。

そうはいっても一つ一つの作業は一人のメンバの操作にかかっているのですから、メンバ個人の技量を把握しておかないと作成された手順で事故防止の配慮が適切かどうかの判断ができないですけど。五郎丸選手が高校生の頃に試合でキャッチを失敗してチームが惨敗した後にキャッチの練習を長い期間やっていた　エピソード（youtubeへのリンク）　はそれですね。

手順も技量レベルの話もプロジェクトマネージャは関与できるようで関与しきれないんです。とはいえ祈るばかりではギャンブルだし、運とは掛けた手間暇の可視化でしかないですし。

結局、手間暇かけた分だけしか成功しないので、今日もしょうがないけれどメンバと一緒に頑張りましょうか。