システム開発と業務改善／問題改善は考え方が同じ
技術的な差分はありますが、基本的にどのような技術を駆使するとしても、結局のところ、システム開発を突き詰めれば
現状の課題・問題をＩＴの力を利用して解決する
と言う命題自体は変わることはありません。そのため、「ＩＴの力を利用」するかしないかと言う差を除けば、そのプロセス自体は、私たちの日々の課題解決や業務改善などでも同じように活かせます。
このように物事を抽象化してわかりやすく表現するプロセスを、モデル化とも言います。
ちなみに、モデル化の"モデル"は、元々ファッションモデルのモデルから来ていて、自分ではない誰かを参考に模範、規範としてイメージしやすくすることを意味しています。
では、私たちの普段行っているシステム開発の中から、開発そのものを取り除いて、「問題解決」するためのアプローチのみを抽出すると、どのような仕組みになっているのでしょう？
そもそも、モノづくりやプログラミングと言った開発に特化した作業以外の、この問題解決／課題解決部分の業務について、明確に答えられない人は、トラブルを起こします。何故なら、お客さまが本当に望んでいる根底の問題／課題を解決できていない確度が非常に高くなるからです。
入試等のテストを思い起こしてください。
解き方もわからない数学のテストがマークシートでもない状態で出てきて、運任せで合格できる自信はありますか？
確率でいえば似たようなものです。
知らないまま着手して、成功する(合格する)確度が高いと思う方がどうかしています。では、順番に見ていきましょう。
1. まずはＩＴ化(システム化)する前の状態を把握する
兎にも角にも、ここからスタートです。
ＩＴ化(システム化)する前の状態、状況はそこにそのまま厳然として存在しています。これを"Observasion"(＝事象・現象)と呼びます。
既に存在しているObservasionに対して、私たちができることは大別して２つしかありません。
2. Observasionを強化する
１つは事象としてのObservasion、現象としてのObservasionから、情報を抽出します。この抽出された情報を"Fact"（＝事実・現実）と呼びます。行動、活動あるいはそこから生成される成果物等、活動の中で発生する『現象』を、より"業務（事実）"として明確にします。
たとえば「コンセントが切れた」と言うObservasion（事象）を知ったとします。その結果から、得られる事実は「電気がつかなくなる」と言うFact（事実）を知るわけです。
もちろんこれらの「事象・現象」と「事実・現実」の間には依存関係がありますが、１対１とは限りません。
3. Observasionを記録する
強化することによって、具体的にどのような事実に紐づくかは判明しました。
しかし、ものごとは実際に検証してみないことには『絵に描いた餅』となる可能性もあります。誰かのまた聞きばかり繰り返していると、本当のお事実からは遠のく情報になることがありますよね。だから、その事実を自分の目で確認するわけです。これを"Phenomena"（＝観測）と言います。
そこで、実際に『事実』として検知できたうえで、その通りであることを寸分たがわず監視、測定、時には問合せ等によって、実際の情報として収集（観測）します。
たとえば、新薬を開発するにあたって「現象はこうだったので、事実はこうなるはずだ！」と言われても、本当にそうなるのか確認してもらわないことには信用しようという気にはなれないでしょう。事象・現象によって得られる事実を、また聞きするだけでは信ぴょう性が低いのです。
当然、信用できなければ、服用しようという気にもならないはずです。何かの問題や課題を解決するにあたっては、システムも医薬も大差ありません。
それが業務なのか、製品なのか、それとも病気なのか、問題の対象となっているものが異なるだけで、本質は同じなのです。
これによって、Fact（事実・現実）として強化したことが、Phenomena（観測）によって裏付けがなされ、改めて正しいFact（事実）であったことが認識されました。
4. 意味や根拠を導出する（導出されるまで繰り返す）
ここで導出されるものを"Meaning"（＝意味・根拠）と言います。
事実が明確になった部分から、その意味と意義を導き出してモデル化するための根拠とします。焦って導き出せないうちから、勝手に判断して次の作業に移ってもいいことは何もありません。
先の説明のように、根拠があいまいなまま新薬を開発されても、服用したいとは思わないでしょう？
そのため、導き出すことと同時に、その間ここで待機が発生します。
私たちエンジニアが最も苦手とするのがこの部分です。
事実・現実として認識した内容に"意味"や"根拠"を一つひとつ見出すことが非常に不得手なのです。
「なぜそうしなければならないのか？」
「そうしなければならない理由は何だったのか？」
わざわざそんなことを考えることが"面倒"あるいは"煩わしい"と考えているエンジニアやマネージャーも少なくないでしょう。
しかし、それは本来、お客さまにとって非常に不誠実で、無責任な発想であることを忘れてはいけません。そもそも、これをしないから問題が根本から解決しない…と言われているからこそ、世界のトヨタなどでは"５回のなぜ"を徹底させているわけです。
意味、意義、根拠を明らかにしないまま、思い込みだけで結論を出してしまう人は、決して正解にたどり着けません。辿り着けたとしてもそれはただの運によるものです。再現性の低い方法であることに変わりはありません。
5. 文章として明確化する
ここで初めて成果物を作り出します。要件定義であれば、「要件定義書」を作る部分になるでしょう。会議であれば、「議事録」がこれに当たります。
Meaning（根拠）が伴ったFact（事実）を、明確な文書にするために言語を駆使します。これを"Language"（＝言語表現）と言います。当然、言語表現される形は１つだけとは限りません。複数の成果物によって、１つの事実、１つの意味が記載されるのは一般的によくあることです。
ここまでくるとかなりモデル化が進んできました。
実際に起きている事象や現象とは別に、それらを記録化し、文章または図として表現するのです。とはいえ、具体的にどのように表現すればよいかと言う部分が定義できていません。
6. 図表を使って描く
言語を駆使して表現していく中で、より視覚的に、よりモデルの理解度を向上するために図や絵を利用します。表現方法が１つでなければならない理由もありませんので、もちろん多様な文章表現を用いてもかまいません。
重要なことは、読み手にとってわかりやすい（可読性が高い）ことです。
こうして出来上がるものが"Diagram"（＝図表）となります。
ここまでくると、大抵の事象・現象は表現できたのではないでしょうか。
しかし、それと合わせて、このDiagramの書き方に一定の書式やルールがないと、当然ながら読む側が混乱することがあります。そこで、「読み手にとってわかりやすい」ことを目的として、書き方やルールを定義します。
7. ルールを定義する
わざわざDiagramを利用して表現する目的は、自身と他人との意思疎通を図りたいからです。意思疎通を図ることが目的である以上、意思疎通しやすい…言い換えるならば「読み手にとってわかりやすい」表現方法でなくてはなりません。
言語表現には一定のルールや規約を設けて、グループ、チーム、あるいはお客さまとの間に、画一的な意思疎通を図る統一感が求められるわけです。これを"Rule"（＝ルール・規約）と言います。
8. 規定し、構成する
記述されたルール・規約、基準、手順などを最終的なモデルに組み込むことで、『モデル』そのものの標準化を図り、"人"の能力に依存しない、より安定した品質を保証したDiagramを構成します。これによって出来上がった抽象化された事実・現実を、"Model"（＝モデル）と呼びます。
わかりやすいように「仕組み」と言い換えてもいいでしょう。
描画された図表を最終的なモデルに組み込むことで、モデルそのものの骨格・土台を組み上げ、またそのモデルを関係者全員が、同じ認識を共有しあえるようになります。
たとえば、次のDiagram（図表）を見てみたらどうでしょうか。
赤い×マークがついていると、「間違っている」「禁じられている」と言う認識になってしまうのは、一般的なRule（ルール）として定着しているからですよね。そして実際の車ではまったく同じ形のものは存在しないかもしれませんが、それを「車」であると認識してしまうのも、抽象的な表現が的を得ているからです。自転車も同様ですね。
さらに黄色い中央線は「追越しのための右側部分はみ出し通行禁止」と言うルールですから、これに黒い進行方向を示す矢印…このことからも、
「追越しのための右側部分はみ出し通行禁止」
を具体的な事例として表現したモデル
であることがわかります。ルールがしっかりしており、それらが描く側と見る側で共有できていれば、意思疎通が図れることの意味が分かりましたでしょうか。
こうしたモデル化／仕組み化が正しく行われると、現状（As-Is）もモデル化できますし、お客さまの要望を聞いて取り込めれば理想（To-Be）もモデル化できるようになります。そのうえで正しくモデル化の手順が踏まれていれば、お客さまとの間においても、チーム内／チーム間においても、意思疎通において何も弊害となるものはないはずです。
9. 具体的な解決実現の検討へ
こうしてモデル化が完了すれば、あとはAs-IsとTo-Beのギャップを埋めるために、持ちうる技術力を駆使して、どのように解決実現すればよいか、やっと『開発』に着手できます。
どのような開発手法でもかまいませんが、より効率よく、より品質の高い方法を選択することも忘れてはいけません。
しかし、残念なことに多くのＩＴ企業、エンジニアは、それがどういう意味を持つかも深く考えず、時には完全に思考停止して、どこかの誰かが考えた開発手法を形だけ真似て、Language（言語表現）しようと考えてしまいます。
さらに、そこに「なぜそのようなモデル表現にしたのか？」と聞かれても、
根拠が説明できず、挙句の果てに
「一般的にこの手法が妥当だから」
「いつもこれでやってるから」
「前はこのやり方で指摘されなかったから」
「大手ベンダーがこれでやれって言ったから」
と言ったような（「自分は悪くない」アピールが鼻につく）他責に逃げてしまいます。これでは、お客さまは何を信頼して開発を任せればいいのかわかりません。
開発方法論についても同様です。
「なぜ、その進め方でよいと判断したのか？」と聞かれても、やはり同じような答えを用意するエンジニアが多いことでしょう。これは、開発のみならず、普段の業務等で生じる問題や課題でも同様のことが言えます。
一般的に現代のサラリーマンの多くは、経営学の父と呼ばれる P.F.ドラッカーが言うところの"知識労働者"です。情報、知識あるいは知恵、知性を駆使して成果をあげる業界の人間なのですから、常に最良の選択を心がける手間を惜しむことが無いよう心掛けたいものですね。
いただいたサポートは、全額本noteへの執筆…記載活動、およびそのための情報収集活動に使わせていただきます。