本質を理解することだけに注力しよう
いきなりですが。
たとえば、ソフトウェア開発の世界では、"要件定義"と言う言葉があって、一番最初に「現状の把握」「要求の整理」「制約事項の確認」「システム化領域の特定」「対効果の分析」などを行いますが、この"要件定義"工程が無いと、システムは開発できないのか？と言うと、疑問が残ります（いや、大抵必要ではあるんですけど）。もう少し厳密にいうと、必要性をきちんと確認せずに、もしも
「とにかく要件定義工程は絶対に必要だ！」
と言う人がいたら、少し注意した方がいいでしょう。
システム開発を含む製造作業にとって本質的に重要なのは、"要件定義工程の有無"ではなく、"顧客要求事項をシステム要件として定義した書類を残すこと"です。必ずしも"要件定義"と言う工程が無ければならないわけではありません。
要件定義工程で何をすべきかを明確にできないまま、盲目的に「要件定義工程が必要だ」と言う人は、運が悪ければ失敗します。そういう人は大抵、「やり始めてから考える」から必ず計画外の不測の事態が待っています。
さらに具体的に言えば、
"業務要求"→"業務要件"→"システム要件"
と落とし込んでいくために最も有効な方法、有効な記録フォーマット、有効な手順とは何なのでしょう。それがわかっていなければ、どんなに「要件定義って必要だよね」と言っていても、何もわかっていないのと同じなのです。その必要な内容ができているかどうか、本人には理解できていないことでしょう。
つまり、端的に言えば「要件定義工程が必要かどうか」という論点は重要では無く、最も重要なことは「設計する前に何をしていなければならないのかを明確にしておく」ことであるということなんです。こう言った本質を見て見ぬふりして、上辺だけの解釈や、個人の都合のいい進め方をしようとする技術者は意外なほど多いのです。
「○○さんに言われたから」
「こうすることって決まっているから」
と、思考することすらやめて活動する人も少なくありませんが、もしもプロジェクトマネジメントでこれをやられてしまうと、下に就くメンバーたちに大きなしわ寄せが来ます。仮に一旦は言われたとおりに、ルール通りに進めてみても、そこに本質的な問題があったならば改善を促すべきなのです。
こうした本質から外れた活動は
本質 > 活動（不足している場合）
確実に問題が起きる。
たとえば、切開手術で輸血しなければ死んでしまうのと同じで、本質的に 必要なモノと言うのは、必要最低限なものであり、その最低限必要なモノ が不足していたら、当然問題となってしまう。
本質 < 活動（冗長が多い場合）
コストやスケジュールに問題が起きる。
見積り（計画）の範囲内であれば問題は無いのかもしれないが、無駄が多 ければ多いほど周囲を混乱させてしまう。迷走させない様にするためには 、本質のベクトルからブレないことと、可能な限り過不足を無くすことが 重要。
と言う事態に発展しかねません。これらを無視して、「そう決まってるから」やると言う盲目的な進め方に固執したり、あるいは我流に固執したり、その結果として失敗やトラブルを起こすと言うのは、つまるところ「失敗することが最初から分かっていて、失敗させてしまう人」であり、言い換えれば"確信犯"であると言えるでしょう。
マネジメントを正しく理解するのであれば、"プロセスアプローチ"の考え方は絶対に外せません。
プロセスアプローチとは、ひとつひとつの作業（プロセス）が
「本当に必要なプロセスに基づいて行われているか」
「作業工程の中にムダな手順などはないか」
を見直す考え方のことです。こういう考え方が無くても開発そのものはできますが、無いまま開発を進めた場合、根拠や証明を求められた際に答えることができず、お客さまの信用を得ることができなくなることを覚えておきましょう。
プロセスには、そのプロセスを実行するための「インプット」「アウトプット」が一本の線のようにつながっていることが大切です（あ、全部プロセスＡになっちゃった…作り直すの面倒なのでＡＢＣと読み替えてください）。
インプット ...前の段階（工程）から入ってくる情報・材料
アウトプット...後の段階（工程）へ渡す、業務の情報・材料（結果）
単なるプロセスの効率化だけでなく、組織全体で見たときに、プロセスのムリ、ムダ、ムラがない仕組みを作らなくてはなりません。
『プロセスアプローチ』をマネジメントシステムに組み込むには、次のような方法が有効です。
プロセスの明確化と抽出を行う
まずは『自分たちが何をやっているのか（プロセス）』をはっきりさせます。そのために、自分の作業の中でどれが『インプット（どんな情報を受け取るか）』で、どれが『アウトプット（どんな成果を出すか）』をひとつずつ洗い出さなくてはなりません。
インプット・プロセス・アウトプットの頭文字をとって「ＩＰＯ」と呼ばれることもありますが、普通にググると「株式上場」のサイトが先に来てしまうので、調べる場合は「インプット・プロセス・アウトプット IPO」などと検索してみてください。
通常、どのような仕事であっても、かならずトリガーがあります。プログラムの「関数」で言うところの呼出元（親関数）みたいなものですね。そして、仕事にはインプット、関数でいうところの「引数」があります。もちろん無い場合もありますが、「引数」の有無や型の定義は必ず必要です。定義されるからこそ、必要/不要が第三者から見ても理解できるのです。
最後に仕事にはアウトプット（成果）があります。関数でいうところの「復帰値」です。稀にvoid型となることもあるでしょうし、ポインタ上を変更していて、そちらを参照してもらえばいいだけかも知れません。ですが、プロセスもプログラムも、その結果が何かに活かされているはずです。必ず、その結果を受けて行動を起こす先を見据えるようにしましょう。
プログラムの構造は、人が作っただけあって、「仕事」の依頼から報告までの流れととてもよく似ています。ですから、関数が
「どれだけしっかりした引数でないと、エラーを起こすのか」
「どれだけしっかりした復帰値でないと、呼出元は困るのか」
が理解できていれば、プロセスの重要性も見えてくるのではないかと思います。
プロセスの監視とコントロールも忘れずに
プロセスを明確化し抽出するだけでなく、『監視』まで行ってこそのプロセスアプローチです。
プロセスの監視とは、「これを踏み外せば顧客に満足してもらえない」「このまま進めるとアウトプットが期待した通りにならない」というものを『管理基準』と定め、手戻り（作業の巻き戻し）が極力発生しないタイミングで定期的にチェックすることです。
監視によって、「顧客の望むものを提供する」だけでなく、「顧客の望まないものは提供しない」という仕組みづくりの基礎が行えます。プロセスに任せっきりになるのではなく、そのプロセスが例外を起こさなくてもいいように、あるいは例外を起こした後固まって止まってしまったりしないように、常に監視（モニタリング）をおこない、必要があれば調整（コントロール）してあげる必要があります。
監視のポイントは
・「（進捗が）計画通りであるか」
・「（プロセスが）ルール通りであるか」
・「（成果が）定められた基準通りであるか」
です。これらのうち、１つでも乖離し始めたら、
・「（進捗が）計画通りになるように」
・「（プロセスが）ルール通りとなるように」
・「（成果が）定められた基準通りとなるように」
調整してあげるのです。調整には「実績」側への調整と、「予定」側への調整の２種類があります。進捗であれば、実態の遅れを取り戻すような調整のほかに、スケジュールそのものを調整するという方法がありますよね。
同じように、プロセスについても、実態を修正するのか、ルールそのものを修正するのか、その時々で正しさを見極める必要があります。成果についても、あらかじめ決めておいた基準と比較し、より良い方を採用した方が良いでしょう。
いただいたサポートは、全額本noteへの執筆…記載活動、およびそのための情報収集活動に使わせていただきます。