問題は自然に解決しない
問題は一度起きてしまうと、そのまま放置しておいて解決するものと、解決しないものとがあります。では、どういうものが解決するのか。それは、
時間進行とともに（なにかしらの）変化が随時行われている
場合です。たとえば、「自然」や「人間関係」と言ったものは、時間の進行とともに、常に環境や条件の変化が行われています。
もしも、「良い方向への変化」と「悪い方向への変化」がそれぞれ起きていたとしても、
良い ＞ 悪い
となっていたならば、緩やかに良い方向へと解決されていくでしょう。しかし、そうなることばかりではありません。特に人工物はそうです。
たとえば、家電や自動車などの調子が悪いとします。これは、原因の大半は「ランダムハードウェア故障」と言って、経年劣化や摩耗などが原因で起こる不良／欠陥です。これは、時間の経過こそが問題の根源にあり、これ以上時間をかけても、悪化することしかありません。
そして、ソフトウェアも人工物です。しかも、経年劣化の心配がありません。こうしたものは時間進行によって変化しません。そのため、「時間が解決してくれる」とか「自然と解決されている」と言うことは、絶対に起こりえないのです。「いやでも、ワンチャｎありえません！
問題意識から比較がなされ、問題点が認識され、
変化の行動がとられて初めて問題は解決される
これは、少なくとも決定論的故障（システマティック故障）と呼ばれる、ソフトウェア開発上で起こる問題のすべてが該当します。
問題解決後の状態をイメージをしてみよう
たとえば、県道から約70m上った小高い山の中腹に、ある老夫婦が住んでいるとします。県道から家までは「けもの道」のような人がやっと通ることのできる小道があるだけでした。
「このままでは老夫婦が不便だろう」と、自治体は車の通れる車道を敷設しました。
その結果、この老夫婦は喜んだでしょうか？
もちろん、喜びはしました。ですが、それは自治体が想定していたようなものではありませんでした。車の通れる道を敷設した途端、この老夫婦は街に住む子供を頼って、家財道具をまとめて移転してしまったのです。
これは実際にあった話です。
つまり、「道路の敷設」と言う手段にこだわるのではなく、道路が完成した後、この老夫婦はどのような暮らしをしているのかをイメージすることが重要だったのです。
もしも、あらかじめしっかりと話を聞いて、彼らが将来街に出ることを本音では願っているというのであれば、自治体が取るべき問題解決策は、道路を敷設することではなく、『引っ越し費用を補助する』ことだったということになります。
「そうしていれば、建設費数億円が、数十万円で済んだはずだった」
というのが県職員の話です。つまり、何一つ”問題解決していなかった”のです。
「ビジョン」とは到達地点のこと
前回説明したように、
象限３「潜在未知」や象限４「潜在既知」の設定型問題を解いていこうと思った時には、
「問題を放置し続けた際のイメージ」と「問題解決後のイメージ」
を明確に持てるかどうかがカギとなってきます。状態表現は、「到達地点」…すなわち「ゴール」と考えてもいいでしょう。問題を解決した後、どのような状態になっていることが良いのか、あるいは最も望ましいのかを言語化したり、絵や図示できるかどうかが問われているのです。
このイメージがまったく行われずに、ただただ経験則だけで思い込みのままに行動してしまうと、たいがい失敗します。
とりあえずの結論でお茶を濁さない
お茶を濁すだけのような問題解決パターンは、決して現状を打開させることができず、むしろ余分な負担や費用の追加投資だけに終わります。
もちろん、そこから一つの選択肢が「使えない」と言う知見を得ることにはつながるのですが、なにぶん費用対効果が著しく悪く、「スケジュールのさらなる逼迫」「予算の無駄遣い」「メンバーの疲弊、信頼感の喪失」などと天秤にかけてもやる価値があると言うのであれば、やってみてもいいでしょう。
あるべき姿の設定とは、「ビジョン作り」と言い換えることができます。
ビジョンを描いて、その状態の実現のために、障害となる問題の解決策を考えるのが正しい問題解決のあり方となるのです。そして、これはそのまま『プロジェクトマネジメント』の計画に当てはまっていきます。
問題を解決するには、問題解決の仕組みを作って、あらかじめ準備していくのと同じように、問題解決にあたる要員をつくる（人材育成をする）ことが重要になってきます。
どんなに仕組みができても、知識もない、経験もない、知性も養われていないというのでは、正しく実行することも叶いません。ある意味で、仕組みや制度（システム）の作成は短時間で可能ですが、人材育成には相応の時間が絶対に必要になってくるので、ここを軽視する組織は大成できません。
せっかく完成した仕組みも制度であっても、
「人」に問題があり、動かないと言う愚に陥らない
ようにしなくてはならないのです。それができていない組織でよく起こるのが形骸化です。形骸化する組織では、かならず次のような状態になっています。
問題が解決しないのは、問題解決の仕組み、あるいはシステムの欠陥だけが原因ではありません。むしろ、問題解決する人材と人材の意識の欠如の方がよほど大きな原因となることが多いのです。「仕組み作り」と「人づくり」のバランスが取れていないことが、問題解決を阻む大きな理由となっています。
言うまでもなく、問題解決の仕組みは、実際には「人」によってつくられ、「人」によって実行されます。そのため、人が仕組みのレベルに合わない限り、仕組みは正しく動きません。それは、もう
条件に合わない武器を装備したため、
本来の能力を発揮できない某ゲーム
みたいになります。
問題解決には仕組み作りと人づくりを連携させる
問題解決の仕組みとは
・問題の定義に始まり
・問題解決のステップを明確にし
・問題を設定するために仕事のあるべき姿とは何かを定め
・問題解決のためのポイント・コツはどこにあるのか具体化し
・解決策(代替案)をどのように創出するのか吟味する
にいたるまでの一連の流れを整備することです。それも個人のペースではなく、組織すなわち複数の人間による集団的な問題解決の仕組みになっていることが求められます。
問題解決というプロセスを通じて、何をつぎ込み、何を産み出すのかと言う視点を絶えず頭に置く必要があります。そしてその両側面から評価し続けなくてはなりません。ただ目の前の問題を解決するだけでは、定められた期限内に完了できないかもしれないからです。
同時に、インプット／アウトプットは「効率」指標となり得ます。業務や作業の効率を高めるためには、問題を起こさない（起こす回数を減らす）ことはもちろん、
「インプットが一定ならばアウトプットを高める」
「アウトプットが一定ならばインプットを下げる」
などの方策も同時に考えていかないといけません。一般的にＱＡなどが陥りやすいのは、「品質」という側面だけしか見ようとせずに、エンジニアリング上の課題や条件、マネジメント上の都合や状況を鑑みようとしない点です。そのせいで、本質的な問題解決からどんどん遠ざかっていくのです。
いびつな形になっていませんか？
仕組みや処遇だけを重視しても、人づくりがついていきません。そうすると、「成果を出さなくても、成果があるように見せかける」と言う無駄な努力を進める人が必ず出てきます。そうしないと評価されないからです。
たとえば、安直に導入された疑似「成果主義」制度は、目先の利益配分を中心として焦点が合わせられ、人材育成と言う側面に大きな停滞を招いてしまったのは、歴史が物語っています。
「人づくり」なしには"問題"や"課題"を解決することはできません。
バブル崩壊以降、長いデフレ期の余波で、ＩＴ投資や採用だけでなく、人材の育成や活用にも長い停滞が生じました。結果、人材の育成や活用のできない中堅層が現在の企業の中核を担っています。
実際、私もきちんとした教育なんて、新人教育以外受けていません。後はすべて独学です。しっかりとＯＪＴをしてくれた先輩なんてのもいません。それを反面教師にしたから、私は実施しているだけです。
必要な人材を作るには、
「人材像の明確化を図り」
「その採用・確保から期待する能力を明確化し」
「課題を与え」
「適正な評価」をしつつ
「育成方法までを体系的かつ具体的な展開」
が図られるようにしなければなりません。
どのレベルの問題なのか
「個人レベル」の小さな問題なら、問題解決に必要な能力は、個人の問題解決能力に限定されます。個々人が問題を設定し、きちんとあるべき姿と対比でき、問題の背景となる原因を追究し、解決策を導くような能力が本人に備わっていることが必要となるのは自明と言えるでしょう。
けれども、「グループレベル」や「組織全体レベル」の問題解決に必要なものは、それぞれの構成員の能力だけが重要となるわけではありません。それ以上に、複数による組織的な対応ができるかどうかが重要となってきます。個々人の能力は高くても、複数による組織的な問題解決が下手な企業は結構多いものです。
全社的な問題解決には、全社的な対応をすることが必要です。
ですが、全社的な問題解決を推進する事務局組織を作ってもうまく機能しないと言ったことは多いものです。ただ事務局を設置すればよいと言うものではないからです。
ＴＱＣ、ＴＱＭ（全社的な経営あるいは品質管理活動）に代表される1980年代までの諸活動が上手くいったのは、その推進体制に一工夫あったからです。それは、
ある部署で成功した問題解決を
他部署に展開する（これを横展開と言う）
と言ったことが率先して行われてきたからです。そのためには個人の能力以上に、組織内のコミュニケーション、そして組織間のコミュニケーションが必要とされたのです。
ですが、昨今の組織間の壁は、どの企業においても非常に分厚いのが一般的です。その多くは利益中心主義で部署間ごとに競わせてきたことが大きかったのでしょう。そのせいで、競争力の強化はできましたが、結果的に発生する「問題」の解決力は地の底に沈んでしまいました。
まぁ、どちらが悪いとも言い難いんですけどね。一長一短、トレードオフの問題です。
二律背反から「両立」「共存」を模索する時代へ
「善」と「悪」、「勝ち」と「負け」に二分したりするのは、一見わかりやすいでしょうけど、実態をサマリーしてぼかしているにすぎません。現実はもっとグレーなものが多々存在します。
たとえば、現在の「勝ち」が10年後も「勝ち」であり続けられる保証はどこにもないのと同様、むしろ「善」と「悪」が両立・共存するような世界においてのみ、問題解決が決着するようなケースも少なくないのです。
「両立」「共存」とは要するにウェイトの問題です。
他の完全否定ではなく、ある程度までを認め「折り合える」部分を探るような論理のあり方と姿勢が問われているのです。そうして融合させることで、より複雑な問題に対する解決も成功するようになっていくでしょう。
検討①リスクから問題を明らかにする
リスクが大きくなるのは、資産価値が大きく、発生可能性が高く、危機管理策が取られていない場合です。逆にリスクが小さくなるのは、資産価値が小さく、発生可能性が低く、危機管理策が十分に取られている場合になります。
図にするとこんな感じ。
現在の環境状況を勘案すれば、問題解決において、リスク管理あるいはセキュリティの面を避けて通ることはできないでしょう。すなわち、リスクの発生を見越した『リスク分散』と『リスクの発生予防』と言う視点から考えるのです。
少なくとも企業をはじめとする各種の組織において、情報漏えいなどのリスク管理やリスク分散の「問題」の解決は、今日日大きな課題の一つであるはずです。よく言われるように、リスクを逆に読めば「クスリ（＝薬）」となるのであり、決してリスクを忌み嫌う必要もないですよね。
あらかじめリスクの評価をきちんとおこなって、リスク管理に対応することが、問題解決の一部分として必要になりつつあります。要は、「リスクは決して起きない」ではなく、発生してもおかしくないとの状況を見越して、「リスクによる被害を一定のものとする」ことがポイントとなってくるのです。
このあたりは、普通にソフトウェア開発におけるリスクマネジメントそのものと変わりはありませんね。問題を起こさないための対策と言うのは、得てしてどこでも同じと言うことの現れです。
当然、リスクの前にはどのようなリスクが想定されるか、つまり起きうるのか棚卸する必要があります。予測せずに難局にぶつかれば、当然その対応も後手に回り、不十分なものとなります。問題解決が下手な人によくある例です。かと言って昨今の地震対策のように、対策に追われ続けるのはスケジュール的にも資金的にも、そして心理的にも困りものです。
検討②ルールから問題を明らかにする
仕事にはルールがあります。一般的な企業でいえば、次のような形を成しているのではないでしょうか。
社員、あるいはメンバーはそのルールに則って、業務を遂行することになります。ルールのない業務などありえません。言い換えると、業務とルールは不即不離の関係で成り立っているということです。業務が独り歩きすることはないし、ルールだけが先行することもない。ちょうど、「人間」と「影」のようなものです。
けれども、実体としての業務は存在していても、仕事のルールが不明確のままで遂行させるリーダーやマネージャーは存外多いのではないでしょうか。
そういう組織では、決まって問題ごとが起きているはずです。
ルールとは、各種の行動の決まり事です。業務遂行にあたっては、様々な決まりごとに従うことになるでしょう。業務遂行者は、その決まりを守らなければ、あるべき姿で業務が為されるはずがありません。
そのルールを共有し、遂行するためには、可能な限り文書化されていることが必要です。そうされていなければ、ルールに従って行動していることを、他者が判断できないからです。特定の人の頭の中だけにあるルールや口頭による指示などの決まりは十分／不十分に関係なく、他からは完璧に記憶、把握、理解することはできません。ですから、文書化されていない時点で、成功は限りなく遠くになると思っておいた方がいいでしょう。
文書化されたルールは、上図にあるように４つの階層に分けられます。
最上位は、「方針」に関するルール。組織全体のあり方を示すような社是、社訓、行動指針、また年度方針のようなものです。プロジェクトであれば、「プロジェクト憲章」「プロジェクト方針・目的」などがこれに相当するのではないでしょうか。
ついで、各種の「規程類」です。これは、形態として条文形式になっていて、また改定履歴が明記されているものと考えると分かりやすいかもしれません。
その下に位置付けられるのが、各種の「基準」「規格」や「細則」、そして「マニュアル」の類です。これは内容が具体的となるぶん、現実の状況や課題にあわせて、頻繁に改定を要することが多かったりします。また、規程類の附則や一部だったりすることもあります。
最後に、ルールの階層の底辺に位置するのが、「雛形」や「記録」の類となります。これらが「ルール」と言うのは違和感があるかも知れませんが、雛形には一定の記入方法や記入項目が決まっていたり、記録（データ）にもその並び方などがあるため、ルールの一種と言う扱いになります。
なぜ、何度も同じ問題が再発するのか
このことは、「問題解決」においても同様に誤解されることが多いのではないでしょうか。
私たちは、よく問題を「解決した」、「解決できた」ふりをしがちです。表面を取り繕ったり、今を何とかしのぐことができれば、それで問題解決したと思って、安心してしまうのです。実際には「後で何とかしよう」と思っていても、次の作業に追われて、なかなかできなかったりします。
そうして時間が経つと、一旦解決したつもりの問題が、すぐに再発したり、別の形態の問題となって表面化するわけです。
この場合、問題の「核」であったり、本質・底流レベルでは、結局のところ何も解決できていなかったと言うことになります。解決したのは、問題の一側面や末端、表層だけだったと言うことになります。
だから、また同じ問題が起きるのです。
定期的に「振り返り」を実施しろと言われるのはそのためです。ですが、日本人、日本文化は比較的ＰＤＣＡの考え方と親和性が低いため、どうしても多くの日本人には受け入れられません。
特にありがちなのは、
・「嫌なことは忘れたい」という考え方が容認される
・ダメなところも「受け入れてもらいたい」という甘えがある
・振り返りを「非難」の場と捉え、「人」を責める人が必ず出てくる
・仕組みを嫌い、自由であることが良いことだと勘違いしている
・「罪を憎んで人を憎まず」と言って、仕組みを無視したままにする
といった風潮です。これも人材を育成していないことによる影響なのかもしれませんが、こうした風土・文化が根強く残る組織では、いつまで経っても、問題の再発防止は進みません。
いただいたサポートは、全額本noteへの執筆…記載活動、およびそのための情報収集活動に使わせていただきます。