今日学んだこと

分かっていることは書かない。分かっていないから書いて学ぶ。だから「今日学んだこと」なのです。

その仕事の背景や目的、具体的な仕事の成果のイメージ、クオリティ、優先順位・緊急度

(写真:古木のさくら その1)

できる仕事術、できない仕事術

「仕事ができるやつ」
それは職業人にとって、何よりも欲しい称号です。
でも、なかなかそう言われるのは簡単ではありません。
日々発生するタスクやハプニング、それに追い回されているうちに矢のように毎日が過ぎて行きます。
厳しい上司や後輩の視線にさらされながら、なんとかできる自分になりたいと思いますが、失敗ばかりで理想の自分からは遠そうです。
でも、仕事のできる人は何が違うのでしょうね。いつも気がつくのは、できる人は仕事をする上で、自分なりの型がしっかりしていることです。それをよくビジネス書ではフレームワークと言います。
そんな仕事のフレームワークを自分も学びたいと思います。

まず、本質を考える

まず、お題の『その仕事の背景や目的、具体的な仕事の成果のイメージ、クオリティ、優先順位・緊急度』は、仕事の精度を上げるためのフレームワークとして、どこからかコピペしたものです。
これを自分なりに以下のように解釈しました。
1.その仕事の背景や目的・・・本質
2.具体的な仕事の成果のイメージ、クオリティ・・・ゴール
3.優先順位、緊急度・・・制約
一番目の『本質』について。
その仕事をする背景は何か、そして何を目指して行うのか。
例えば、今流行りのIOTを例にして、うちの工場にもIOTを導入したいと要請があったとします。
でも、IOTと言っても、今はすっかり言葉だけが先行している感があり、まずどこから手を付ければ良いか困ってしまいます。
そこでまず確認しなければならないのは、お客さんなり社長なりの依頼者がどんな課題を感じてIOT導入を考えたかです。
ひょっとしたら仲間内の会合であまり言われるものだから触発されたかも知れませんし、ドイツ発の「インダストリー4.0」に興味をひかれたかも知れません。
あるいは、工場の設備にあまりに故障が多く、その度に保守員が走ります。すると、その人件費は馬鹿になりませんし、また生産もストップして多くの逸失利益が発生します。
ならば、壊れる前に故障の検知ができれば、長年の課題も解消します。
つまり、これがIOT導入の背景であり、目的です。
後の組み立ては、この仕事の目的、本質に基づいて行うことになります。

そして、ゴール

ゴール、つまり具体的にどこにたどり着けば仕事が完成するのか。
そのイメージなり、クオリティを依頼者と共有しなければなりません。
私もつい先走って、お客さんの望むイメージやクオリティを考慮せず失敗したことがあります。
前段の仕事の本質に従えば、IOTで求められる必要なクオリティは、365日24時間の機械の監視です。しかも、工場やライン全体の監視をするならばそれなりの数のセンサーを用意しなければなりません。そして、センサーが検知するのは異音なのか、振動なのか、温度なのか、対象の機械によって選定をする必要があります。
オンラインで常に振動なり、異音なりを送信して、コンピューターで分析をします。そして、事前に学習した故障のパターンに当てはまったら保守員の携帯にアラートを送信します。
そうすると、実際に故障を起こす前に保守員が対処できるので、機械の稼働停止を最小限に抑えられますし、保守員がかける手間もかなり削減できます。
このように、人手をかけずに常時監視を実現し、実際に故障を起こす割合を大幅に削減できる仕組みが、この工場におけるIOTのゴールであり、目指すべきクオリティです。

制約は何か

しかし、そこに何時もついて回るのは、制約です。
一番問題になるのは予算、つまりお金です。
依頼者としても、ゴールの効果に対して出して良いお金の上限は考えているでしょう。
そして、与えられた予算の中で全てが難しければ、後は予算に合うように提案を変えなくてはなりません。
その中で、依頼者の優先順位を知る必要があります。
工場の機械の中でも、おそらくよく壊れる機械と壊れない機械があるでしょう。
また、壊れた時の影響の大小もあるでしょう。
そこから、早急に手当てすべき範囲を割り出して、対象を限定しつつコストパフォーマンスが一番良い提案に練り込むのです。
そうして、IOTが現実のものとして動き始めます。
偉そうに書きましたが、これはかつてマイクロソフトが実現したIOTと機械学習の実例をもじったものです。
しかし、本質→ゴール→制約のフレームワークはなかなか良いと思います。
このように書いているのは、頭で覚えるだけでなく、なんらかのアウトプットをすれば身につくのではないかと思ってのことです。
果たして現実での成果は如何に、と言ったところですね。