リハーサルの重要性
プレゼンテーションの前にはやはりリハーサルが欠かせません。
音楽の世界もそうでしょうし、芸能界でもそうですよね。スタントマンの仕事だってそうでしょう。特定の仕事だけが特別で、リハーサルをしなくていいなんてことはほぼあり得ません。当然、プレゼンテーションにおいても同様です。
誰も聞き手がいないのに独りで話すのは慣れないと奇妙に感じるかもしれません。また同僚や先輩など身内の人を前にリハーサルするのも、照れくさくてやりにくいかもしれません。
しかし、ある程度大きな会場で聴衆が多い場合や、客先で行う重要な会議でのプレゼンテーションの場合、リハーサルは必須だと感じます。いや、そもそも人見知りだし赤面症でもあるので、あまり人前で話すのは好きじゃないんですけどね。でもだからこそ過度に緊張しないよう本番を強くイメージしたリハーサルには何度も助けられてきました。
エンジニアの方でしたらシステム移行を行う際には、必ずリハーサルを実施するでしょう。サーバーやデータベースのバックアップ／リカバリー機能の実装でも障害が発生するリスクを想定して、事前に必ずリカバリー処理のシミュレーション（＝リハーサル）を行います。
失敗が許されない仕事に「出たとこ勝負」などという考え方は厳禁です。
そういった仕事に対してはリハーサルを怠った時点で、目の前の仕事にも不誠実であると言えるでしょう。
まったく本番と同じ時間や同じ環境（機器など）を揃える必要はありませんが、
「段取り八分」
という言葉を思い出してください。
「段取り」は、もともと歌舞伎の構成や展開のことを示す言葉だったといわれています。今ではもっと広く、さまざまな分野で物事を行う順序や手順、準備のことを指す言葉として使われています。
よく「準備８割（成功するかどうかの80%は準備で決まる）」と言いますが、同じ意味で「段取り八分・仕上げ二分」という言い方もあります。段取りという言葉も「わかったつもり」になりやすい言葉です。もう大丈夫と思っていても、いざ個別の作業にとりかかってみるとまだまだ段取りが不十分だったというケースは頻繁に起こります。
たとえば、ソフトウェア開発の現場ではまだまだウォーターフォール型と呼ばれる開発手法が数多く占めています。
水が高いところから低い所へと流れていき、その逆になることはない…というところから名づけられた開発手法で、基本的に一度前に進んでしまうと後戻りすることはありません。
そしてこのウォーターフォール開発手法はとても成功率が低い方法としても有名です。
そのために、昨今ではアジャイル…イテレーション型と呼ばれる開発手法がだいぶ定着してきました。90年代～2013年くらいまではソフトウェア開発プロジェクトの成功率は安定して３割前後と言われてきました。他業界から見てもとても異質な成功率の低さです。そしてその成功率の低さをけん引していたのがウォーターフォール型と言われています。
その原因の特定を各々がするでもなく、多くの企業やエンジニア、はたまた国までがアジャイルに傾倒していきました。その甲斐あってか、2018年にはソフトウェア開発プロジェクトの成功率は52.8%にまで向上したといわれています。
一方で、アジャイル開発の成功率は70%以上なんて数字もあるほどですから、これが本当ならウォーターフォール型の成功率は20年以上前からほとんど向上していないことになります。だってアジャイルの成功率が７割、ウォーターフォールが３割で、最近は徐々にアジャイルの占める割合が増えてきているというのですから、仮に半々だと仮定すると
（７割前後 ＋ ３割前後）÷ ２ ＝ ５割前後
という成功率になるのも頷けます。
…さて、段取りの話からとんでもなく脱線したかのように見えますが、このことから何を言いたいかというと
ウォーターフォールの本当の欠点を特定しようともしないで
アジャイルに走って何となく成功率をあげたところで
「ウォーターフォールはオワコン」とか宣うのはちゃんちゃらおかしい
ということです。
そして冒頭の「段取り」に戻ります。
私は、ソフトウェア開発における「本番」とは実装以降の工程のことを指しているのだと解釈しています。そして、設計工程とはいわば「段取り」です。本番をイメージして実際にプログラムにする、あるいはテスト工程で実行する前にありとあらゆる業務パターン、操作シミュレーションを行い、どのアクションに対しても処理できるプログラムを作るための準備だと考えています。
だから、仕様や設計工程こそが最も重要で、ここを疎かにするからこそテスト時に
設計解釈誤り
設計検討漏れ
設計記載漏れ
仕様ミス
仕様解釈誤り etc.…
という比較的規模の多いミスを連発し、テスト工程になってから炎上するプロジェクトが絶えないのです。
エンジニアの多くは「プログラミング」が好きです。
プログラミングがしたくてたまりません。
一方でドキュメンテーションが嫌いです。
嫌いだからいつまで経っても成長しないし、苦手です。
そしてそのような意気込みでプロジェクトに参加することを企業が許可しています。仕事ですから設計もさせるし、ドキュメントも作成させるでしょうが、もともと苦手意識がある上にさっさとプログラミングがしたいという欲望を抑制もできないので、どうしても設計の質が悪くなります。
「段取８分」
を理解していれば、そんな個人レベルの欲求よりも、ビジネスの一環として従事していることの責任感を優先させるはずです。
口では何とでも言えますが、そのことを理解していないプロジェクトは要員計画を見ればすぐにわかります。
どこに工数の重きを置いていますでしょうか。
設計工程ですか？
それとも実装／テスト工程ですか？
段取りに80%…とまでいかなくても大きなウェイトを占めるような計画ができていますでしょうか。それができていないからウォーターフォール型の開発で失敗するのです。
一般的には「要件定義」に原因が集中しているといわれていますが、それは視野が少々狭すぎます。実際には『仕様』のコミットメントが不十分なために起きているのです。
そして、仕様とはなにも要件定義工程ですべてが決まるものではありません。
業務仕様やシステム仕様、非機能仕様の多くは決定できるかもしれませんが、機能単位に定められる機能仕様は基本設計工程でなくては検討しないことが一般です。経産省（現IPA）の定める契約モデルのなかで、準委任契約と請負契約を切り替えるタイミング例が２種類記載されているのはそのせいです。
要件定義でコミットメントした内容をベースラインとするのであれば基本設計から請負にすればいいし、機能仕様までコミットメントしたうえでベースラインを定めたいのであれば詳細設計から請負契約とする…としていますしね。
プロジェクトマネージャー自身、または一緒に作業しているメンバーが「これで段取りは十分。不足は一切ない」と証明できるレベルまで到達しなければ、本番（プログラミングやテスト）での成功率は低くなるのは当然です。
そしてさらに冒頭に戻りますと、プレゼンテーションにおいても全く同じことが言えるわけです。シナリオができただけではまだ60%くらいしかできていません。
「インプットした（理解した）」こと
「アウトプットできる（表現できる）」こと
この２つには月とスッポンほどの差があります。
たとえばプレス向けの発表を何度も経験して十分慣れている大手メーカーの取締役でも、株主総会の前はスタッフとともにリハーサルを入念に行う…なんてことも往々にしてあります。
自分で作成したピラミッドストラクチャをリハーサルのときに何度も見ることで、自分の頭の中にピラミッドストラクチャがきれいに納まるはずです。本番では、手元に置いたピラミッドストラクチャは自分を安心させるためだけのもの。
紙を見なくても自信を持ってプレゼンテーションに臨めるはずです。
ちなみに、私は教育やセミナーの講師をしたり、経営発表の場などでたまに話すことがありましたし、トラブルプロジェクトで「助けてくれ」と言われてお客さまに説明しに伺う場合など、「説明」「証明」によって相手に一定の"納得"をしていただく必要があるシーンでは、かならず事前に10回前後は
リハーサル
を家で行います。
まず、頭の中でできるだけ実践を想定しながら読み上げ、次に声に出しながら読み上げ、最後に目を閉じながら実際に壇上や相手の前で話すことを鮮明にイメージしながら実戦さながらに読み上げます。「こんなこともあるかも」なんて気づいた失敗シーンなども脳内でできるだけリアルに再現して、それをリカバリーする練習をしたりもします。もちろん、想定できる質疑応答などもすべてリハーサル対象です。
家で１人で行っている姿を客観視すると確かに滑稽ですが、その努力が１つの成功を生みだすのであれば体裁など気になりません。体裁などとくだらないものよりも責任のほうが何百倍も重要です。体裁を気にして、失敗しかできないような人間にはなりたくありません。
とはいえ、実際にはリハーサル通りにすることもあまりありません。
本番前や本番中に思い立ったかのようにフレーズが浮かんできて、ついついプレゼンの中に加えることもしばしばですし、質疑応答にしても必ずしも想定通りの質問しか来ないわけでもありません。
ですが、リハーサルをするとしないとでは明らかに腑に落ちた自信のほどが異なります。覚悟の差が違います。肝の座り方が違います。
自信がいくらかついていれば、不必要に頭が真っ白になることもありません。
それだけでも、よほど失敗確率が下がるというものです。
逆に、多忙が理由でリハーサルができなかったときはだいたい惨憺たるありさまです。
ビジネスを含め、どんなことでも「本番」になる前までが重要で、「本番」になってから慌てようとするのは下策なのだということを覚えておきましょう。これは孫子の兵法書でもいわれていたことです。
いただいたサポートは、全額本noteへの執筆…記載活動、およびそのための情報収集活動に使わせていただきます。