システム開発とは、「仕事」の一部をコンピュータのロジックとしてソフトウェア化するということです。ソフトウェア化とはコンピュータが動くようにプログラムを書くと言うことでプログラマの仕事になります。勿論、プログラマは「仕事」がどう言うものかは知りません。仕様書に書かれた指図に従ってプログラム・コードを書くだけです。システム開発とは、つまり、仕事を段階的に構造化し、そのシステム化する部分につき、最終的に言語・図表等によりプログラマに指図をしてプログラム・コードに変換する行為です。
仕事を構造化する行為は、仕事を「知っている人間」にしかできません。当然ですが、一番仕事を知っているのは、その仕事をしている社員です。しかし、「社員」と言っても誰でもという訳には行きません。例えば、販売管理システムについて考えると・・・まず、顧客からの発注書を受け取り、販売管理システムに受注データを入力することが最初の仕事ですが、多分、この仕事をしている社員は発注書の読み方と、どこのデータをシステム端末のどこに入力したら良いのか・・・と言う、「操作」しか知らないかもしれません。このケースで、真の意味で「仕事」を知っている社員とは「受注」から「販売」に至る全工程（プロセス）を知っている社員になります。（しかし、「全工程を知っている」社員が一人である必要はなく、販売業務工程を何人かが分担して「知っていても」いいのですが・・・）知っていると言っても、端末機器の操作や、データの転記などの「手の動かし方」を知っているだけでは足りず、販売業工程を構成する各「仕事」（工程、またはプロセス）がなぜ必要なのか・・・まで理解していることが必要です。
別の言い方をすると・・・、上記の「仕事を知っている人」ならば、仕事を構造化する手法さえ身につければプログラマへの指図をすることが出来ると言うことになります。
筆者も30数年前、ある大型システム開発の要件定義を担当した時に、10人ほどのプログラマを預けられて（SEではありません）、要件定義書（実際はプログラム仕様書）を書いたことがありますが、筆者は対象だった「業務」を手作業でこなしていた経験を持っていたので、当該業務の「全工程」と「なぜ」を知っていたので何とか出来たのだと思います。
横山芳成氏（ウルシステムズ取締役）によると・・・
「筆者は事業会社の情報システム部門を対象としたシステム開発のトレーニングを開催している。受講者は部長クラスから現場の担当者まで職位も年代もさまざまだ。ただ、一つだけ共通していることがある。それは「皆、要件定義に悩んでいる」ということだ。筆者はトレーニング後に自部門の課題を問うアンケートを必ず実施する。その回答で、「要件定義スキルの不足」が常に突出しているのだ。アンケートを取り始めて7年以上たつが、この結果には変化がない。要件定義がいかに難しい問題であるかが分かる。」
と、指摘しておられますが、「要件定義スキルの不足」という言葉の解釈は2通り出来ます。
1.
一つは、社員の業務知識の低下です。
30年前、それ以前は多くの仕事が「手作業」で行われていたため、各個人は意味を理解しながら「仕事」をしていたが、情報システムが導入され社員は「操作」を覚えれば「仕事」をこなせるようになり、仕事の意味を深く考えなくなり、業務全体を俯瞰して構造化できる人材が減った。
2. もう一つは、システム開発を要件定義も含めてＩＴベンダーに丸投げする日本での風潮により、社員は自ら要件定義をせずＩＴベンダーのシステム・エンジニア（以下ＳＥ）に任せてしまい、要件定義が社員本来の業務である・・・と言う意識が薄れてしまった結果、社員が自ら業務設計を行う技量が失われてしまった。
これには経営者の責任も重大です。
ZDNet Japanサイトの記事『ITベンダーに依存するユーザー企業の理由--「丸投げ」「責任転嫁」が上位に』（國谷武史 （編集部） 2021-11-25）をご覧ください。
https://japan.zdnet.com/article/35179937/
その中に・・・【あなたはベンダーとお付き合いする上で得したことはあるか】という設問の回答1位が「基本的にすべてお任せで仕事を進められるので、仕事が楽だ」とあります。これでは経営者失格と言わざるを得ないと思います。
昨今、デジタル・トランスフォーメーション（以下ＤＸ）という言葉がいろいろな場所で語られるようになりました。
経済産業省では、「デジタル・トランスフォーメーションを推進するためのガイドライン（DX推進ガイドライン）」において、以下のようにDXを解釈しています。
「企業がビジネス環境の激しい変化に対応し、データとデジタル技術を活用して、顧客や社会のニーズを基に、製品やサービス、ビジネスモデルを変革するとともに、業務そのものや、組織、プロセス、企業文化・風土を変革し、競争上の優位性を確立すること」
社会が大きくＤＸに向かって舵を切ろうとしている中で、ＩＴベンダーに要件定義も含めて「すべてお任せ」では、早晩、峻烈な競争から脱落してしまうでしょう。
システム開発を行うにあたって、システム開発が単独で行われることは稀です。ほとんどの場合、業務設計が行われ、業務設計の結果として要求されるシステム機能についてシステム開発が行われます。要件定義とは業務設計の一部として策定されシステム機能を定義します。重要なのはこの部分です。ＩＴベンダーに依存している多くの企業は業務設計まで丸投げしてしまっています。それ故に、楽はできますが、社員の業務能力は低下してしまい、上で述べた「要件定義スキルの不足」に陥ってしまいます。以前のブログで『「システム開発内製化の動き」と「ユーザ主導の要件定義」』を採り上げましたが、業務設計と要件定義が自社で出来る（要件定義の内製化の）力量を有していれば、「システム開発内製化」までしなくても問題はなくＩＴベンダーに頼るべき部分（要件定義から仕様書への変換、システム基盤の設計、コンティンジェンシー・プランの策定など）に絞って外注出来るようになれば良いのです。
経営者は、自社の社員が「顧客サービスの最大化」のために「自社の業務プロセスの最適化」を設計できるように教育・訓練する必要があるのですが、その成果の一つが「要件定義の内製化」です。要件定義の内製化が出来るようになれば、開発コスト１／２、開発期間１／２、開発リスク１／２も夢ではありませんし、この教育・訓練を通じて、社員の自社業務への理解が深まるとともに、社内コミュニケーションも高まり、結果として自社の業績アップにつながって行くのです。