"見るべきもの"、"見せるべきもの"を決める

見える化。可視化。

何事に関してもそうですが、

　「情報」が必要十分揃っていなければ、

正しい判断はできませんし、判断できなければ行動を開始することもできません。かくいう私も、大抵のことは何でもできる自信がありますが、それもこれも、

　「行動開始するために十分な情報が与えられている場合に限る」

と言う条件が付いて回ります。もちろん、すべての情報が必要なわけではありません。ほとんどは第一歩を踏み出すための情報だけあれば十分です。

ゲームなどのマッピング機能のようなものをイメージしてください。

進まなければ、先の地図は見えてきませんが、進みさえすれば、目の届く範囲のほんの少しだけ先の地図情報が手に入ります。進みだしさえすれば、得られる情報から予測し、ある程度仮説を立てて、行動を開始することができます。

しかし、第一歩を踏み出す瞬間だけは、踏み出してもいいと言う確信が得られるだけの情報が欲しいところです。ゲームで言えば、

　このステージの敵は強いのか？
　今のレベルで太刀打ちできるのか？

等と言った疑念を晴らしたいと言ったところでしょうか。

これは仕事でもプライベートでも同じことです。やり始めてしまえばなんてことなかったものでも、やり始める前は妙に慎重だったり、億劫だったりしたことはないでしょうか。それは始めるために必要十分な条件がそろっていないからです。
　
だからこそ、多くの判断、多くの行動には

　情報の見える化

が重要になってくるのです。基本的に、『行動』が変われば、仕事の『スタイル』が変わり、仕事のスタイルが変われば、『結果』が変わって、新しい『成果』が出ます。

ただし、これは正しい方向に行動が変わった時の場合に限ります。もし間違った方向に行動を変えてしまった場合は、期待した成果が出ないのはもちろんのこと、障害が発生したり、収拾がつかなくなったりしてしまいます。行動してすぐにその行動が「良かったのか？悪かったのか？」、明確な結果が現れればいいのですが、なかなかそうはいきません。

そこで、結果が出る前に、良い結果に向かって行動がなされているのか、その判断や行動に対する"適切性"を見極める必要があります。

適切な行動がとられているかを判断するために何を見れば良いのかを考え、その見るべきものを決めます。ソフトウェア開発におけるプロジェクト活動だけでなく、１日、１週間、１ヶ月、１年…と、一定の期間を設ける業務であれば、営業業務であっても、総合業務であっても、同じことが可能です。

みなさんも、どんな仕事でも「失敗」したくはないから、ほんの少しずつ進めながら上司や周囲に確認を取ったり、前回の反省を活かして、次につなげるような取り組みはしていることでしょう。そして、その殆どが、自らの経験の（記憶の）中から引用して「このくらいのタイミングで確認しよう」と思った時に行われていると思います。

それでもわからない場合は、他人に助けを求めていることでしょう。

ですが、もしも、それらの経験や知見が「見える」状態であったらどうでしょう。みなさんがしている業務は、決して世界中の誰もが、日本中の誰もが、社内中の誰もが、過去１度も経験したことの無い新しい仕事と言うわけではないはずです。99%、必ず誰かが似たようなことを経験している業務のはずです。

けれども、初めて実行する人は、常に五里霧中の状態で始めることになります。だから、誤った判断を勝手にしてしまったり、素直に行動に移せなかったりするわけです。

見える化できれば、世の中が変わる

ここまで言えばわかると思いますが、だからこそ知識、経験、考え方、基準、判断等、ビジネスで必要なモノはすべて「見せる」必要があります。経験が多い人であればあるほど、本来はそういったものを

　「見える化」

しなければなりません。事業や業務の「後継」や「継承」はそうすることでしか為しえないからです。ですが、自らの経験則だけに頼って、他人や部下の育成を疎かにしてきた人たちは、そもそも、経験則を論理的に言語化することが苦手です。そう言う人には傾向があって、

　①あらかじめ説明しない
　②あらかじめ答えを用意しない
　③後になって「なんでこんなことしたんだ」
　　　　　　　「なんで事前に聞かなかったんだ」と他責にする

実際には聞こうとしても「忙しい」等、適当な言い訳をするだけで、たいして説明してくれるわけでもないので、より質が悪い人に多く見受けられます。
　
日常業務の大半は、「答え合わせ」です。

まず先に答えがあって、答えに沿うように指示を出したり、進めたり、そして最後には答え合わせをするものです。レビューもそう、テストもそう、すべて答え合わせが用意されています。

上司から、指示、依頼された時、その指示内容や依頼内容から、アウトプットや完了条件が見えてくるでしょう。それが「答え」です。

やり方に条件やルールがつくことはありますが、細かいことは自由に進めていいことになっている場合が多いでしょう。最後に、報告や提出をすると、上司の確認・レビューが行われます。

これが「答え合わせ」です。

正答率が低ければ怒られるかもしれませんし、評価を下げられるかもしれません。しかし本当の問題は、上司（指示者／依頼者）がちゃんと「答え」を提示していない、すなわち

　仕事に求める全体像を見える化していない

と言うことに問題があることが多いのです。
そこには

　「これくらい、わかってて当然だろう」
　「忙しいんだから、これくらいは自学でやって欲しい」

と言った思い込みや期待があって、指示者側が手を抜いているケースも多いことでしょう。

人間、最初から「完璧」や「的確」なものを選ぶことはなかなかできません。まずはやってみて、見るべきものからのデータと結果を照合して、見るべきものが妥当なのかを何度も見直していきます。

この経験を積み重ねていくことによって、自分たちの行動の適切性をはかるための見るべきものを見抜く力が備わっていきます。その間、何度も失敗を繰り返しても我慢できるのであれば、代わりに責任が取れると言うのであれば、答えを「見える化」しなくてもいいかも知れません。

しかし、もしそうでないのであれば、常日頃から「見える化」する努力を怠らないようにするべきです。

"見るべきもの"／"見せるべきもの"

…と言ってもそうしない人たちばかりではないかと思います。

ところが、"見るべきもの"／"見せるべきもの"というのは、得てして簡単に見ることができないものです。

たとえば、非常な手間をかけて"見るべきもの"のデータをとったのでは、時間もコストも相当な負担ががかかってしまいます。そしてついに見えた時にはすでに結果が出ていて、もうそのデータは必要ないということもよくあります。

"見るべきもの"／"見せるべきもの"を「明確にすること」は、長い時間をかけて積み重ねていくことによってできるようになります。

しかし、その"見るべきもの"／"見せるべきもの"を、時間もコストもかけず、すぐにその場で見えるようにするのは、経験だけでは解決できません。
たまに私のところにも「お客さまから、『御社には品質の基準値とかないの？』と言われたんだけど、何かないですか？」という問い合わせが来ることがあります。

結論から言うと『ありません』。

その基準値を作るためには、

　・様々なソフトウェア開発プロジェクトの進め方に統一感を持たせる
　・その統一感の中で指摘や不良に対するすべての不良情報をデータ化する

ことが必要になってきます。しかも、１つや２つのプロジェクトだけでなく、何十、何百と収集し、頒布評価しなければなりません。

プロジェクトチームの多くのメンバー、多くのエンジニアの方々が、そうした"今までやってこなかった取組み"を協力してくだされば、基準値を作ることも可能でしょう。しかし、現実的には難しいのです。

いままでのやり方に固執することなく、知恵と工夫を駆使して、改善を繰り返していくことが、唯一の道です。「見える化」ができない組織のほとんどは、この"日常的に「見える」工夫"をしていません。

　手間がかかるからデータが集まらない
　見るべきものと結果の関係がいつまでも学習されていかない

的外れなものをいつも一生懸命に見ていることになってしまい、「見える化」によって仕事は良くなっていかないという、悪いサイクルに入ってしまっています。

ＡＩのプロジェクトに携わった方や、ＡＩを少しでも勉強した型はご存知だと思いますが、ＡＩに正しい判断をさせようと思ったら、適切な量と質のアノテーションデータを必要とします。データを用意できないのであれば、ＡＩは絶対に成功しません。

それと同じことです。

データを蓄積することを良しとしないのであれば、いつまでたっても正しい判断ができず、仕事が良くなっていくこともないのです。