シンプルなことほど難しい、それはなぜか？
はじめに
こんばんは、ひょっとこです。
今日は新年二日目ということで、初売りとかを楽しんだりしていました。
そして、珈琲屋の開店時間が7:00からの通常営業に戻ったので、珈琲屋で朝活をしていました（笑）
相変わらずの生活習慣で、我ながらサイボーグみたいだなと思っていたり、いなかったりします（苦笑）
さて、本日はシンプルとは何なのかということを考えたので、自分なりの考えを記事にして投稿しようと思います。
シンプルとは
そもそも、シンプルという言葉を使う方は多いと思うのですが、シンプルの定義って何なのか、みなさまはわかりますでしょうか？
私はわからなかったので、辞書を調べてみました。
わかるようで、具体的にはどんなことなのかわからないですね（笑）
自分なりにシンプルってどんな状態のことを言うのか理解しようと、あれこれ考えてみたので以下に記載してみます。
シンプルの定義
シンプルの定義を自分なりにしてみた結果、以下のような定義になりした。
ある特定のプロセスを実現する手順の中で、最もステップ数が少ない手順のこと
はい、何を言っているか意味不明な方も多いと思うので定義の内容を図にして説明してみます。
例えば何かしらのプロセスAがあったとして、それを実現するための手順を1〜３まで検討したとします。
手順の具体的な中身がステップとした場合に、以下のような図の状態になることはイメージできますでしょうか？
プロセスAを実現する上で、最小のステップ数となるのは手順１となるので、この３つの手順だと手順１が最もシンプルということになります。
シンプルということを判断するためには、比較対象と比べて判断する相対評価を行う必要があるので、手順１〜３を例としてあげております。
シンプルなことを実施するためにやるべきこと
さて、シンプルの定義については記載してみたの、次にシンプルな状態がどんな状態なのか認識するためにシンプルを判断するための前提条件を考えてみようと思います。
■シンプルを実現するための前提条件
1. プロセスが実現できたか定性的、定量的評価できる状態であること
2. プロセスを実現するため手順を、全パターン網羅して検討できていること
3. 各手順を実行するためのステップが検討できていること
4. ステップが実現できたかを定性的、定量的に評価できる状態であること
前提条件の１、４については、言わずともがなプロセスとステップの評価を行うために明確にすることが必要ですよ〜ということを記載しております。
前提条件の２、３については、どの手順が最もシンプルと言えるか相対的に評価するために手順のパターンとステップ数を網羅・検討することが必要だと記載しております。
難しそうなことを記載しておりますが、簡単にまとめるとプロセスの定義と評価基準、達成基準、手順の全パターン網羅、ステップを明確にして検討することが必要だということです。
シンプルなことの難しさ
さて、ここまでシンプルとはどんなことなのかを記載してきたのですが、シンプルなことって実際にやってみると難しいと思いませんか？
私は仕事をしてきた中で、シンプルなことを実現するのが非常に難しいと感じています。
シンプルなことを実現しようと考えたきっかけとしては、コンサル時代に無駄なことに時間をかけている暇がなかったなので、極限まで無駄を省いてみようと考えたことがきっかけでした。
実際に自分で考えて実行する中で、シンプルなことほど実現することが難しかったのです。
では、何に難しさを感じていたのかというと、「シンプルなことほど、ミスをした時に避けるリカバリーの時間が短い」ということに難しさを感じていたのです。
先ほどの図で説明すると、ステップ２で何かしらのミスが発生してリカバリーが必要な状況になったと仮定します。
ミスが発生したシチュエーションについて、締切が決められておりプロセスAを完了させるまでのタイムリミットを変更できない状況だとします。
タイムリミットを変更しないでプロセスAを実現するためには、ステップ３以降でリカバリーをしつつプロセスAを完了させることが必要になりますよね。
そうなった際に、手順１〜３のうち最もリカバリーが難しいのはどれでしょうか？
そう、手順１です。
というのも、手順１は最もステップ数が少ないので、リカバリーに使えるステップが残り１つしかありません。
後続のステップ数が少ないということは、言い換えるとリカバリーに使える時間が短いため手順２、手順３と比べるとリカバリーの難易度が相対的に難しいということです。
手順２、手順３は後続のステップ数が手順１と比べると多いため、リカバリーに使える時間が手順１と比べて長いので想定的にリカバリーが容易だといえます。
シンプルなことほど、プロセスを実現するためのステップ数が少ないので、ミスが致命傷になりやすく、リカバリーに使える時間が短いためプロセスを実現するための難易度が高い。
そのため、シンプルなことほど実現することが難しいのです。
ここまでのことを踏まえて、シンプルなことを実現するためには、以下の条件を満たしている必要があるのではと考えました。
■シンプルなことを実現するための必要条件
1. ミスをしない or ミスを最小限で抑えることができること
2. ミスをした際のリカバリー速度が速いこと
１については、ミスが発生する前の状況で実施する内容となります。
ミスをしなければ、リカバリーをする状況が発生しないので理論上のステップ数でいける確率が高くなるため１の条件が必要だと考えております。
ミスをしなければより少ないステップ数でプロセスを実現することができるので、各ステップを改善しながらより少ないステップで実現するには、どうすればいいかを常に振り返りの中で考えていく必要があるのではないでしょうか。
２については、ミスが発生した後の状況で実施する内容となります。
ミスが発生した後に迅速なリカバリーが出来なれければ、タイムリミットに間に合わせることができなくなるため２の条件が必要だと考えております。
そミスが発生する前からミスが発生した場合の対処法を常に考えつつ、発生したミスを迅速にリカバリーするようにしていく必要なのではないでしょうか。
こうして、言葉や図にして自分なりにシンプルとは何かを考えたことで、「シンプル is difficult」ということがわかってきました（苦笑）
ただ、シンプルな方が無駄な時間を使う必要がないので、シンプルにするにはどうすればいいかを常に考えていきたいですね。
おわりに
「シンプルとは？」と何気ない疑問について、自分なりの考えをまとめてみたのですがいかがだったでしょうか？
コンサル時代に学んだことなのですが、「あっているか」、「あっていないか」ではなく、自分なりの考え方を持つことがまずは大事だと学びました。
コンサル時代に学んだことを試すいい機会だと考えて、自分なりの考えを記事として投稿してみました。
自分なりの考え方を持つことで、他の人と議論ができますし、自身の考え方で至らなかった部分が明確になってくるので、些細なことでも疑問に思っは自分の頭で考えて自分なりの解を持つようにしたいですね。
（「あっている」、「あっていない」はスコープや制約条件によって変わってくる部分なので、状況に合わせて最適な解を選んでいくだけなので、「あっている」、「あっていない」を考える前にまずは自分なりの解を考える習慣を持ちましょう！！ 私も頑張ります（笑））
本日のところは、こんな感じで終わろうかなと思います。
私は明日で正月休みが終わりとなりますが、明後日からの業務に備えてリハビリしないと考えていたりいなかったり…（明日のことは明日考えよう）
では、また〜