前回までで、失敗を防止するための対策を策定するところまで説明しました。PDCA（Plan-Do-Check-Act）サイクルで言うなら「Plan」が完了したところですので、次は防止策を実施する「Do」以降に進みます。
防止策を策定（Plan）したところで満足してしまうのはもちろん、策定した防止策を実施（Do）しただけでは意味がありません。
取り組む対象の成功率が「千三つ」であるなら、失敗防止策の成功率も「千三つ」である可能性を疑うのが失敗学的姿勢ですから、「Check-Act」も欠かせません。
実施の徹底
まずは防止策の実施を徹底することから始めましょう。
ひょっとしたら、以下のような理由から実施の徹底が難しいかもしれません。
- 確認項目が多過ぎる
- 確認に時間が掛かる
- 確認が面倒
- 確認内容が曖昧
ですが、そのような防止策を策定したのは他ならぬ自分自身です。
あまりにも実施が困難ならともかく、逆に「防止策を改善するための情報収集のチャンス」ぐらいに考えて、まずは目の前の対策を実施することに注力しましょう。
後述しますが、高度な技能を身に着けようと思うなら、重要なのは地味な繰り返しです。
たとえば弊社の導入研修の場合、失敗防止策をチェック項目一覧として作成し、レビューの際には成果物の良否を確認する以外にも、防止策実施の徹底度や効果も確認（＝本人・講師によるダブルチェック）するようにしています。
対策の改善
前節まででPDCAサイクルのPlan-Doまでは完了しました。
次は、当初策定した防止策を検証（Check）し、必要に応じて改善(Act)を行います。
失敗防止策に限らず、一旦定まってしまったルールは、往々にして一種の神聖不可侵化が進みがちです。
しかし本稿冒頭でも述べたように、失敗防止策の成功率も「千三つ」だと思えば、妥当性や過不足を日々確認し、常に改善を続けることに抵抗は無い筈です。
最初（Plan）の段階で非の打ち所の無い対策を立てようとするのではなく、日々の対策適用（Do）の中で改善点を拾い上げ（Check）、それを反映させていく（Act）作業こそが重要だと言えます。
たとえば弊社の導入研修の場合、各自の防止策＝チェック項目一覧に対して、一定期間ごとに以下のような見直しを行うことにしています。
- チェック項目の具体性はあるか？
- チェック項目の実効性はあるか？
- チェックの実施は（時間・労力の点で）現実的か？
必ずしもチェック項目を増やすだけが改善ではありません。
何度も繰り返し対策を実施することで、チェックリストを使用しなくても無意識的に行えるようになったなら、思い切ってチェックリストから外す、という選択肢も有り得ます。
チェック項目の数が多すぎて全ての確認が行き届かない場合も、まずは当面重視しなければならない項目のみに絞りましょう。
ルーティン化
多少なりとも自分の実力に自信がある場合、基本的な失敗防止策を律儀に実施するのは面倒に感じることでしょう。
しかし、基本的な確認実施を反復することで、可能な限り自動的＝無意識的に確認実施ができるようになれば、より高度なレベルでの判断に意識を集中することができます。
卑近な例で言えば:
入力速度よりも思考速度が遅いので、タッチタイプは必要無い
と言う人は多いですが:
タイピング検定に通るレベルまで極めたけど、思考速度が追いつかないので、「見ながら入力」に戻した
という話は、寡聞ながら筆者は耳にしたことがありません。
弊社では、新入社員には必ずタッチタイプを修得させるようにしています（タイピング検定レベルまでは求めませんが…）。
実装／設計能力の向上で目に見える程の生産性を改善するには、決して少なくない時間を必要としますが、タイピング速度の向上による生産性の改善は比較的簡単にでき、その上、タイピング速度の向上で余裕ができた時間を勉強にまわすことで、その後の実装／設計能力の向上にも寄与できるためです。
もちろん、タイピング速度を補って余りある能力があるなら話は別ですが…
また別な例で言えば、特定のプログラミング言語で一定以上の開発スキルを持つ人で、普段のプログラミングの際に、「はじめての～～」や「プログラミング言語～～」といった書籍でいちいち文法を確認している人もいないのではないでしょうか（ライブラリのAPI確認は除きます）。
人間の能力では、一度に意識的に注意を払える対象の数には限りがあります。アスリートが日頃の練習でひたすら基本を反復しているのは:
より高度なレベルの問題に意識を集中しても、
基本的な動作が無意識のうちに実施できるようになるため
なのですが、これは以下のように言い換えることもできます。
基本的な動作が無意識のうちに実施できないようでは、より高度なレベルの問題に意識を集中できない
使うものの違い（筋肉・脳細胞）こそあれ、「意識しなくても実施できる」ようになるために、まずは「繰り返しを意識的に行う」必要があるのは、どの分野でも共通だと思います。
対策実施契機の上流化
（少なくとも）ソフトウェア開発の場合、失敗防止の対策実施契機を上流工程へと移動させることで、同じ対策実施であっても、さらに高い効果を得ることができます。
プログラムの作成（＝実装）における失敗防止の対策として、チェック項目による確認を実施するケースを題材に、契機上流化の例を示します。
実装後に確認
なにはなくても、まずは実装後に必ず確認する習慣を身に付けましょう。
何事も基本が肝心です。
実装しながら確認 ～ 実装力の向上
半ば無意識的に出来るようになるまで実装後確認の習慣が付いたなら、今度は実装の最中に確認作業を行ってみましょう。
今まさに実装しようとしているプログラムに対して、関連するチェック項目を頭の中から引っ張り出し、条件が満たされているかを確認しながら作業を進めてください。
実装後確認が習慣化することで、チェックリストの項目があらかた頭に入っているとはいえ、いちいちチェックしながら実装するのですから、以前と比較して作業が進まないことに苛立つかもしれません。
しかし、何も考えないで実装して後から確認するのは、さらに効率の悪い進め方であることを理解してください。現時点では一見効率良く見える（実は単に「早い気がする」だけなのですが）としても、ある程度の規模を超えたなら、考え無しで実装する手法は通用しません。
最初からこの実装方法を推奨しないのは、前述したように、一度に意識的に注意を払える対象の数には限りがあるためです。
プログラムを書くのもチェック項目での確認も、どちらも一杯一杯の状態では、両者を同時にこなそうとしても中途半端に終わるのがオチです。
実装と確認が平行化することで:
- 実装後確認まで進んでからの、些細な問題による手戻りが減少
- 実装後確認の際に、より重要な部分の確認に注力できる
といったメリットが得られます。
実装する前に確認 ～ 設計力の向上
実装中の確認が習慣化してきたなら、次は実装を開始する前の段階で:
どのように実装するつもりで、その際に発生し得る失敗はどのようなものか？
それを防ぐにはどのように実装すべきか？
といったことを先読みしながら作業を進めてみましょう。
作業工程を事前にシミュレーションすることになりますから、適切な検討・対策が実施されていれば、工程が進んでから手戻りする率を低下させることができます。
このような先読みの際には、たとえば「変数の初期化が正しいか？」といった実装上の具体的なチェック項目よりも、実行性能や資源消費、拡張性、保守性といった、より上位からの視点でのチェック項目が必要とされます。
言い換えるなら:
上位からの視点でのチェック項目が頭の中に整理されていて、然るべき時点で確認・対応ができる
か否かが、設計力の高低と言えるのではないでしょうか。
実装させる前に確認 ～ アーキテクチャ策定力の向上
ここまでは、「自分が実装」するケースについて徐々に対策実施契機を早める、個人としての改善でした。
これをさらに推し進めると、「自分以外も実装」するケースに備えた対策実施、いわば組織としての改善の段階へと進みます。
実装担当者の力量から見て、実装の段階で発生し得る失敗はどのようなものか？ それを防ぐにはどのような仕組みが必要か？
ということを先読みすることで、実装チーム全体としての改善が図られます。
但し、このレベルの改善には注意すべき点があります。
この「事前防止」が行き過ぎると、実装担当者が何も考えなくなってしまい、イレギュラーケースへの対処能力が低下してしまう、いわゆるマニュアル化の弊害に陥ってしまう可能性があります。
決して実装担当者の能力を侮っているのではありませんし、必ずそうなってしまうわけでもありませんが、
畑村氏の失敗学の活動でも、そのような傾向になりがちである事実は広く確認されていますので、注意が必要です。
参考資料
日々の地道な積み重ねに関しては、何も「失敗学」の専売特許ではありませんから、それらに関する方法論は他の書籍に譲るとして、失敗学的な考察力を高める上でお勧めの資料を紹介したいと思います。
「失敗学の法則」
『失敗学の法則』は、実際に起こった過去の失敗事例を紹介しつつ、そこに潜む本質的な問題に対する考察や教訓が記されています。
必ずしも読み手に近い事例が収録されているとは限りませんが、「自分ならこう考える（or こう考えるべき）」とか、「自分の状況で言うなら、これはこういう事態に相当する」などと、想像力を働かせて読むことができれば、失敗の疑似的な体験を得ることが可能な、非常に有益な書籍です。
