本質を無視する開発は高確率で失敗する
なんとなくですが、ソフトウェア開発において、ふわっとした「本質」部分を上流工程までですが、まとめてみました。
あくまでエンタープライズ向けをベースにしているので、ウォーターフォール主体の考え方になっているかもしれませんが、個人的にはアジャイルであっても原点は変わらないと思っています。
1. 顧客要求の抽出
「どんなシステムを作ってほしいのか？」と言う聞き方では、所詮”システム要件”の洗い出しでしかなく、顧客のニーズ（=要求）を洗い出すものではありません。顧客要求とは、
「現行業務(As-Is)を、どうしたい(To-Be)のか？」
と言う観点で詰めるものです。そのためには以下の作業が必要となってきます。
・現行の業務を把握する
・要求事項を抽出する(要”件”ではなく、要”求”)
たとえば、家を建てるとしたら…
（顧客要求）
①「今通っている通勤時間が１時間かかるので短縮したい」
②「トイレは各階にほしい」
③「二世帯で済むので、和洋部屋間で調和がとれ、
行き来しやすく実現してほしい」
（システム要件）
①’「通勤時間60分以内の土地を探す」
②’「トイレを１階と２階の○○に配置する」
③’「すべての部屋でバリアフリーにする」「色調を整える」
と言った違いが生じるわけです。お判りでしょうか。お客さまの要求を洗い出す作業をせずに、お客さま自身にシステム要件を提示するように求めるエンジニアのそこはかとなく場違い感が。
システム要件は、顧客要求を満たすことができる現実的な案として、エンジニア側が提案するものです。お客さまが要求するものではありません（ごくまれにしてくれるお客さまもいますが、たいてい中途半端なＩＴリテラシーで無理難題を言ってくるのが関の山です）。お客さまは、いくつかの案を提案されたうえで、どうするか／どれを選ぶかを選択するだけです。
特にエンタープライズ向けのソフトウェア開発の現場では、このことが理解できていないエンジニア（と言う名のプログラマー）がお客さまとの間で認識齟齬をよく起こして、トラブルプロジェクトを量産します。
2. システム要件の定義
お客さまの要求は、私たちに発注しようとする以上、最終的には「業務を改善してほしい」のではなく、「業務を改善する為のＩＴ資産を提供してほしい」ということになります。そのため、今の業務の何が不満なのか、何をどうしたいのか確認した後には、当然「どんなＩＴ資産(システム)が欲しいのか？」を確認し、定義化しなければなりません。
これこそが「システム要件」です。
一般的に、要件定義と言うプロセス名が使われやすいのは、そのためです。
そして、システム要件には以下の４種類が存在します。
①システム要件（要求を正確に実現する為に用意すべきＩＴ資産）
②機能要件（要求を実現する為のシステム機能）
③非機能要件（運用・保守の観点から実現すべき非システム制約）
④移行要件（現行運用に支障をきたさないシームレスな業務移行）
ここで忘れてはならないのは、私たちエンジニア側から見た場合は、システムの納品がイコール『プロジェクト活動の終了』『契約の完了』となることが多いと思いますが、お客さまにとって、あるいはシステムにとっては、納品は“終了”ではなく、そこからライフサイクルが“開始”することで、ずっと先の廃棄された時に”終了”となる…ということです。
納品する私たちは、そのお客さまにとっての"終了"までの期間を、論理的に保証しなくてはなりません。いわゆる「耐用年数」間の品質保証ということです。それができる仕組み、システム、プログラムが選択されていなければなりません。
たとえば、お客さまの償却期間（廃棄するまで固定資産として取り扱う期間）が７年だとすると、７年間運用に耐えられるハートウェア、ソフトウェア、パッケージ、ライセンス等、諸々が選択されていなければなりません。
オープンソースライセンスのプログラム言語を選定する場合、セキュリティホールなどが見つかった場合のサポート保証ができるのか？できなかった場合、私たちはどうやって保証すればいいのか？などが明確になっていますでしょうか。
単純に、「Java（OpenJDK）なら無償だから、イニシャルコストがかからないので、これで作っちゃおうぜー」とか、「Javaの開発技術者だったら集めやすいから、Javaにしよう」なんて軽いノリで開発されると困ります。
たしかに、Java9以降は無償版と有償版に分かれてしまいましたが、無償版はいわゆる開発版で、品質的に安定していないものでも、利用者のフィードバックが欲しいためにどんどん実装してきます。当然、バグやセキュリティホールなどのリスクも高まります。
また、６ヶ月に１度のメジャーバージョン更新なので、その内容次第では、お客さまにリリースしたものも更新しなければならない可能性も出てきます。その時、旧バージョンで動いていたプログラムが、新バージョンにした瞬間、動かなくなる可能性も出てきます（でも、更新しないとバグが…セキュリティホールが…となってしまうと八方塞がりです）。お客さまの運用によっては、２４時間３６５日ずっと稼働しているシステムかもしれません。そう簡単に「サーバー再起動しますねー」ってわけにもいかないケースだってあります。
そういったお客さまの顧客要求をしっかりと聞き取りしていれば、どんなシステム構成、どんな言語選定が理想的なのか、検討することもできたでしょう。
（移行要件について）
発注する顧客の”企業”は、昨日・今日あたらしくできたわけではなく、システム化対象業務も新規であることは滅多にありません。
既に世の中のビジネスでは、システムであれ、ツールであれ、紙運用であれ、既存の運用情報、あるいは仕掛中の情報に対して
「どのように次のシステムに引き継ぐべきなのか？」あるいは
「現行の業務との切替タイミングは？」
と言う観点は必ず検討が必要になってきます。この観点がきちんと検討できずに作られたシステムは、概ね現場運用担当者に見限られ、利用されなくなっていきます。
お客さまにとってＩＴ投資をするうえで重要となるのは、たいていの場合「従来業務の効率化」です。従来業務がこれ以上パフォーマンスを落とすのであれば、そんなシステムは必要ありません。そして、『従来の業務』が運用できることが大前提なのですから、
その業務の中で、過去データを用いる場合
その業務途中で、システムが切り替わる場合
に、過去データや仕掛中データが使えなくなってしまうのは困るわけです。もう一度、新システムに対して「１から入力しなおせ」なんて言われたら、むしろ業務効率が落ちます。
エンジニアの仕事は、たしかに「システムを作る」ことなのかもしれませんが、それがすべてではありません。全体の中で多くを占めているかもしれませんが、あくまで一部でしかないのです。
それを無視して、データを含む既存資産の移行要件をハッキリさせないまま、プロジェクトを進めようとすると、間違いなくお客さまと揉めることになるでしょう。
（超上流の勘所）
大前提は
「顧客はシステム（≒ＩＴ）の素人である」可能性が高い
と言うことです。ゆえにお客さまが提示する要求事項は、重要度が低い割に、考えているよりもはるかに難易度が高く、コストが増加することも珍しくありません。
お客さまを神のように扱う必要も、お客さまの要求が絶対的なもののように扱うことも原則として誤りです。少なくとも私たちは、お客さまがどのように業務することが最も効率的なのかを理解し、お客さまがそもそも求めている課題解決に対して要求内容が誤っている場合は、改善提案を行う必要があります。
ゆえに「超上流」と呼ばれるプロセスは、自信を持って提案、定義に取り組める限られた上級エンジニアが少数精鋭で行うことが一般化しています。
ここで重要なスキルは、必要な情報を『収集する』能力、そしてその情報を『理解する』能力と、理解したうえで分類し、『再整理する』能力と、整理された各要件パーツを『最適化する』能力であり、その根幹を為すのは、お客さまに対して誤りを誤りであると言える、職務に対する『誠実さ』であると言えるのではないでしょうか（コミュニケーションやドキュメンテーションももちろん必要になってきますが、あくまでも“重要な”サブスキルにとどまる）。
3. 機能要件の実現方法の定義
いわゆる『設計』プロセスでは、システムを機能に落とし込んで検討した時、具体的に
「どのように実現するのか？」
「それは実現できるのか？」
「具体的実現方法は？」
等については、必ずハッキリさせておかなくてはなりません。実現性のない取り組みほど無駄なことはありませんし、ただ実現すればいいってわけでもないからです。同時に、お客さまとも再度合意形成が必要となってくることでしょう。ここで行うべき合意事項は
「実現された機能を用いた業務の運用イメージができるかどうか」
です。このイメージがお客さまの中で容易にできないようであれば、それはおそらくUI/UXとして及第点ではない…ということです。あるいは、それで強硬したところで、スイッチングコスト（新しいシステムに慣れるまでの負担）が大きく、現場の利用者たちに過度なストレスを与えるようなものにしかなりません。
ゆえに、このプロセスは、システムの境界線を挟んで、外側（お客さま側）との関係や関連を決定・設計する活動となることから、外部設計とも呼称されています。
『お客さまにイメージしてもらうための設計』ということはつまり、
「顧客 ⇔ システム」
の接点についての仕様をシステムの観点から決定するということでもあります。そのため、外部設計のことをユーザインタフェース設計（UI）と呼ぶこともあります。UIには、たとえば以下のようなものがあります。
システム機能
画面デザイン/入出力項目
システム操作毎の挙動
帳票デザイン/出力項目
ファイルデザイン/入出力項目
他システム連携/入出力項目
データベースデザイン/入出力項目
データベースやファイルをシステムの一部と勘違いしている人もいるが、その中に格納されているデータ群はすべてお客さまの所有物であって、記録媒体がＩＴ化されているだけでしかありません。
「システム」とは、プログラムとそのプログラムを動作させるためハードウェアやネットワーク、ミドルウェアを含む環境群のことです。お客さまが持っている情報群は、システムとは呼びません。
情報資産（データ）としての姿形や構成はエンジニアの好きにしていいものではなく、お客さまにとって最も使いやすいインタフェースとして検討、設計しなければならないのはそのためです。
仮に既存システムがあったとして、その構成から変更を加える際も、必ずお客さまにとって迷惑にならないか確認し、合意が必要になるのです（←これが判ってないエンジニアが非常に多い！！）。
4. 非機能要件の実現方法の定義
非機能要件と言うと、真っ先に”性能”のことかと考えてしまう人も多いとおもいますが、「性能」も観点としては含まれているものの、実際にはそう言った名前の要件はありません。必要な検討事項は以下の通り。
これらは、日本情報システムユーザー協会(JUAS)の発行している、『非機能要件要求仕様定義ガイドライン』を参考にしています。
左６項は、少し古いですが ISO 9126/JIS X 0129-1 『ソフトウェア品質特性』でも定義されている内容ですね。
5. 内部機能の分割
機能の動作やインタフェースと言った、利用者（ユーザー）目線での設計は外部設計で概ね終了します。いわゆる「お客さま」にとって決めなければならない仕様はすべてここまでの間にきめるからこそ、このプロセスまでを『外部設計』と呼ぶのです。
それらの機能を具体的あるいは物理的に実装するためには、どのような機能分割（オブジェクト分割）にすべきか、一度整理する必要があります。
古き良き時代の縦割り工法による属人的な進め方では、担当間の引継ぎや調整負担が低減するものの、以下のようなデメリットを招くことがわかっています。
・冗長性が高く、あちこちに似たような機能・処理が多数組み込まれる
→コスト増
・保守性・移植性・障害抑制性が低下
→改修・障害発生時、コスト大幅増またはトラブル化するリスク増
・ルールや規約による開発活動の抑制が困難
→属人化
→属人化したシステムは、そのままエンジニアが定着することで、
“つぶしがきかない”環境が出来上がり、中長期的に見れば
企業の損失につながる。
こうしたことに注意しながら、変更容易性（いざとなって変更依頼があった時に、無駄に慌てなくていいよう、変更しやすい形を考慮しながら設計しておく）の高い設計観点が必要になってきます。
お客さまがＩＴに精通していないからこそ、お客さま自身がシステムの最終的に利用されるシーンをイメージできるようになるまでに時間がかかることを忘れてはいけません。そしてイメージできるようになってから、ニーズ…仕様が大きく変わることは珍しい話ではないのです（てか、日常茶飯事）。
いただいたサポートは、全額本noteへの執筆…記載活動、およびそのための情報収集活動に使わせていただきます。