タイトルの言葉は私が高校生の時にクラス担任の先生から言われたことです。今となっては彼のいうことは間違っていなかったと思いますが、今から37年程前は勇気のいる言葉でした。
入学後に、テレアポの電話がかかってきて適当に流していたら『倍率7倍なんてすごいですね』と言われて自分の大学の倍率を知りました。ちなみに受かった理由は「運が良かった」で大学名は敢えて出しません。
その3年後になりますが、大学を辞めるときに当時のクラスメートから言われたことは「お前の人生終わるぞ」で、当時の一般的な感覚を示しています。まぁ、今となっては思い出の1つです。
やめた理由は、ここの「3.大学教育について」に書いてあるので、繰り返しませんが、私から見れば今の大学が置かれた状況を見ると「そうだろうな」という印象です。
あれから私も還暦を控えた身になりますが、少子化の影響で大学全入時代を迎え「Fラン大学」、「Fラン行くなら高卒」という言葉が出てきて隔世の感があります。
正直、大学に行くか行かないかは本人たちに任せればよいかと思いますし、Fラン大学が潰れようが残ろうが「それは社会（学生）からの選択の結果だろう」と思います。
強いて学生の方に補足すると、大学を出ていきなり数百万の借金（奨学金を含む）を背負うのはリスクがあるので、特にFラン大学へ借金してまで入学するのは個人的にはお勧めしないということと、今はSNSの時代なので、大学関係者の書き込みを見て、受験の判断をしてもよいかと思います。
あくまでも私の記憶ですが、奨学金って月に5万円程度しか借りられなく、あくまでも補助的なものでした。当時の多くの学生は無利子または低利息だったこともあり、小遣いを借りるという感覚だったかと思います。4年フルに借りても総額で240万円程度で、これなら車のローン程度になるかと思います。もちろん当時の経済状況（好景気）もあり決して返せない金額ではありません。
一方で今はもっと借りることができるようで、卒業後300万円とか400万円、多い人だと600万円を超える借金を背負うことになります。例えば消費者金融から借りるには年収の1/3という規制があるのですが、下手をすると年収以上の金額を借りることになります。
もちろん、奨学金と消費者金融では利息が違うので一概にNGとは言えませんが、それでも卒業後、キチンとしたところに勤められなければ借金が重荷になるでしょう。「結婚相手が奨学金を借りているので躊躇している」、「奨学金も借金」というSNSの書き込みも目にし、奨学金の負担が１つの社会問題になっているかと思っています。
社会のことを充分に理解していない学生に対して、経済状況を踏まえると返済できるかどうか分からない借金を背負わせるこのシステムには、問題があると言わざるを得ません。
高校生の方は『Fラン大学で奨学金を借りるということはリスクがある』ということは理解しておいた方がよいかと思います。
この記事の発端ですが、ある大学関係者の方の書き込みですが、特定して批判するのはあまりよくないかと思いますので濁しますと、
批判者：Fラン大学に行くなら高卒でよい
ある大学関係者：「大学は学問をやる場所（だからFラン大学は不要）」＝大学に対する解像度が低い
というコメントで、率直な意見を言うと「そんな認識でFラン大学を擁護しているのなら、そういう大学は要らないだろう」ということです。
ざっくり今の状況をいうと、「学生の数が減って大学が過剰になっている」ということで、処方箋としては「大学の数を減らす」というのが、まず第一に考えるべき点でしょう。
つまり、大学もリストラを受ける時代になったということで、これについては受け入れるというのが一つの回答になります。
ここで、Fラン大学の社会的な存在意義を唱えるのなら、
「大学は学問をやる場所（だからFラン大学は不要）」＝大学に対する解像度が低い
こういう風に批判者を批判するのではなく、キチンと、そのFラン大学の存在価値を示せばよいのです。まさに説明能力こそが高等教育の証ではないのか？と思います。
それを高等教育を行うものがステレオタイプ的（反射的）に批判者を批判すれば「あーこういう説明能力のない人が大学やっているのなら無くてもいいかな」と思ってしまいます。
ITエンジニアでしたら、コミュニケーション能力が求められます。例えば客から問題点を指摘されたときに「お前の意見の解像度は低い」と言えばそういうエンジニアは退場させられるでしょう。
通訳案内士にしても同じです。
ある程度ランクの高い職業や専門職（ITエンジニアもそうですし通訳案内士もそういう面はありますが）の方は議論になると相手が無知ということで論争に勝とうとする面がありますが、ここで問われているのは説明責任でしょう。
日本経済の30年にわたる停滞を踏まえると、高等教育が十分に機能してきたのかという点について、考えさせられる書き込みとも言えます。
この方のSNSを見たのですが、既に学部単位ではリストが始まっており「死活問題」と言っているのですが、これはあくまでも大学（教員・関係者）の立場からの意見であり、この方の大学もいわゆるFランで本人にとっても死活問題なのでしょう。もっともリストラというのは日本のビジネスパーソンにとっては避けて通れないので頑張っていただくしかないでしょう。
私としては、不要な大学は淘汰されて、無理をして借金をしてまで大学にいくより、高卒でもキチンと仕事ができる環境の方がより良いかとは思います。今の私の年代（還暦近く）の人の半数未満は高卒です。私は放送大学を卒業しており、働き出してからでもやる気があれば大卒の資格は取れるのでそういう努力が報われる社会になれば良いかと思います。
改めて「あの時は、大学をやめて正解だった」と個人としては思う日だった。
初心者の方は特に感じられることかと思いますが、さぁ、プログラミング言語を覚えた！プログラムをどうやって作成するのでしょうか？
例えば、ゲームのプログラムを作りたい！と思ったときに、手が勝手に動いて、気が付いたら思う通りのゲームを作れる人は多分、これ以降は読まなくてもよいかもしれません。
これは皮肉ではなく、私自身が本当にそう思っているということもありますし、一方で私には無い才能ということで憧れでもあります。
実は、ソフトウェアの開発環境はこのようなある種の、プロデューサーといいますか映画監督といいますが、要するに『何を作るかが分かっている人』が潜在的には求められており、AIがコーディングを助けるようになると、ますます重要なポジションになるかと思います。
これは、特にソフトウェアをある種の表現行為に使う（ゲームとかAI動画等）場合に必要な人材と言えるかもしれません。
一方で、ソフトウェア開発というのはもっと多種多様な世界ともいえます。こういうと大げさに聞こえますが、『どう作るかは分からないが、完成図が見えている人』と『完成図を貰えれば、あとは作れる人』と組み合わせると上手くいくケースもあります。大半のエンジニアが関わる業務アプリやらECサイト、その他、WEBアプリや組み込みアプリがありますが、『現場で使う人』と『現場の人が使えるツールを作る人』という組み合わせもあるでしょう。
このように作る人と作ってもらいたい人が別になる、つまり組織的にプログラムを作るようになると、作るものの合意をしたり役割分担をすることになり、『誰がいつ、何をするか？』というソフトウェアの開発手順が必要になってくるでしょう。
ソフトウェアの開発手順の古典的かつメジャーな方法が、「ウォーターフォール開発」ということになります。
段取りを踏んでプログラムを作りましょうということですが、『こういう面倒なことは知らなくてもよいのでは？』と思われる方も、自分が仕事としてプロジェクトに参加して、プログラムを組む場合は、つまり組織的に開発するということは何らかの開発手順を踏むことになりますので、勉強されることをお勧めします。
ウォーターフォール開発は、色々細かいところはありますが、概ね
・要求仕様（Requirements）
・設計（Design）
・実装、開発（Implementation）
・テスト（Verification）
・運用（Maintenance）
という風に工程を分けて、開発を行うということです。『要求仕様』というのは一言でいうと『何を作るのか？』を決める作業で、『設計』は『どう作るのか？』を決める作業、『実装』で実際にモノを作り、『テスト』で動作確認を行いバグをとりのぞき、『運用』では実際に使っていくということになるかと思います。
実装、テスト、運用についてはプログラマの方には分かりやすいかと思いますが、要求仕様や設計についてはピンと来ないかもしれません。いわゆる上流工程と言われている工程が要求仕様になるかと思います。具体的になにをするかは様々ですが、ここではお客さんと頻繁に打ち合わせを行うことになります。よく、オプションとして「AとBどちらにしますか？」というとお客さんから「どっちもできるように対応して」とか言われるところです。ここですかさずに「そうしますと工数が増えますね。あとで概算見積もりに入れます」と言えるかどうかが、その後の開発が修羅場になるかどうかを決めることになります。
設計作業は、名前ほどキチンとしておらず曖昧かもしれません。例えば、昔は「オブジェクト指向は大規模開発に向く」と喧伝され「UMLが・・・」とか「オブジェクト指向設計」やら「モデリング」やら言われた時代がありました。これらの声が下火になった、今、はたしてどこまで浸透しているかは謎ですが、批判を覚悟であえて言いますと、大規模開発において信頼性のあるアプローチ（設計手法）はトップダウンや分割統治かと思います。つまり機能ごとに分割してアプリケーションを定義するということになります。ECサイトなら「購入サイト」や「商品・その他マスター管理」、「顧客管理」、「注文管理」とかになるかと思います。機能分割に着目することは「オブジェクトがどうのこうの」というより、より上位の、つまり抽象度が高い操作と言え、分割にも適しているでしょう。
さて、以上は、『私のウォーターフォール開発』の理解です。日本でのソフトウェア開発の現場を見てきましたが、こういうことをキチンと分かっている人や出来ている人は経験上少なかったかと思います。
『お前はどうやねん』と言われそうなので、予め答えますと、プログラミングと同様に一通りの勉強はしました。また、キャリアのごく初期は幸運にもウォーターフォール開発を行っていた経験があり、理論と実践で学ぶことができました。
一方で、繰り返しになりますが、現場現場で、関わる人達の理解に差があったり、ケーススタディーがキチンとしていない面もあり、状況は「カオス」かと思います。
一時期、情報処理技術者試験の受験をやめたことがあるのですが、これは『あまりにもソフトウェア開発手順を無視したプロジェクトマネージャ』がいる現実に落胆して勉強するのが馬鹿らしくなって遠のいたことがあります。
以上、ざっとウォーターフォール開発を見ていきましたが、ウォーターフォール開発の批判の1つが、「各工程を厳密に区切る」ところにあり、Wikiにもあるとおり、「全工程に間違いがない」ことを前提にしている開発手順と指摘されています。
例えば、要求仕様の段階で、「そのままの要求仕様を満たすものは作れない」となると大問題ということになります。
これに近いものになりますが、私が気を付けているのは「プロジェクトメンバはどのタイミングで、作成するものを具体的にイメージ出来るか？」ということになります。言葉を変えると「この情報でプロジェクトメンバは開発が滞りなくできるか？」ということになります。
ソフトウェア開発の現場で、よくあるトラブルの１つは『プログラムを作れない』という状況になります。要求仕様の間違いもありますが、どうも一部のエンジニアは『出来ない』ということが言えなかったり、自分の能力不足を認めなかったりし、想定（報告）以上の時間を使って開発が遅延します。
次回では、ウォータフォール開発をもう少し突っ込みつつアジャイル開発についてみます。
最近、とあるAI絡みのプロジェクトでLLMを使ったシステムの研究開発をやっておるのですが、個人的に応用が利くものができつつあると実感しているのですが、一方で、今は広める訳にはいかないので、成果の一部を小出しにします。
ちなみに、「オブジェクト指向おじさん？」の記事については、「感情的である」というAIからのご指摘を受けてそのうち修正を行いたいと思います。
以下本題、下記の記事にコメントします。
・なぜ、「ウォーターフォールでソフトウェアを作れる」という嘘を信じる人が世の中にいるのか？
・ウォーターフォール開発がダメなのかは、弁護士が請負契約で仕事しないことでわかる？
あくまでも個人的な感想ですが、どうもAIを活用した論調の記事だとは思うのですが、私のAI分析が良い感じだったのでその成果ということであえてコメントします。
まず、結論ですが、ウォーターフォールだろうが、アジャイルだろうがその場にあった方法でどうぞとなります。
「プログラマ」ではなくある種のコンサルタント的な立場の人間（SEや営業、アーキテクトもその一人かもしれません）、つまり上司やプロジェクトリーダの元での作業ではなく、非エンジニアの顧客（情報システム部門の方でも、そうでない方でも）と直接話をする場合にわかるかと思いますが、おそらく99%の顧客の関心事項は
金をどぶに捨てることにならないか？（何らかの成果物が出てくるか？）
ということです。顧客目線に立てばウォーターフォールが良い場合もあればアジャイルが良い場合もありますし、ウォーターフォールだろうがアジャイルだろうが、最終的にモノが出来なければ「修羅場」になるということです。
まともな顧客は、RFP（Request for Proposal）を用意して提案書（見積）を求めてきます。
そうでなくても「こんなシステムを作りたいのだが・・・」からはじめに打合せを行ってから、ある程度「何を作るか？」を話し合ってからの見積となります。
この場合、ウォーターフォール開発が想定されるような「システム開発」の場合、ほぼ間違いなく
完成保証があります。
つまり請負契約になります。ここで『ウォーターフォール開発がダメなのかは、弁護士が請負契約で仕事しないことでわかる？』とありますが弁護士が請負契約をしない最大の理由は「原理的に完成保証ができない」からです。つまり裁判になったときには必ずどちらかが負けます。弁護士が仕事を受けるときには原理的に「勝ち」を保証できないことになります。
一方でソフトウェア開発の場合は、「不確実性」があったとしても顧客と開発者が成功に向けて協力すれば、「何を作るか？」ということに関しては何らかの合意ができることが多いです。また、記事にあるような『不確実性が高い』というのは、ソフトウェア開発が持つ「本質的不確実性」の他に、開発するエンジニアの技術不足や経験不足「技術的不確実性」ということもあります。もちろん顧客の都合で仕様が変わる場合「要求不確実性」もあり、これらをきちんと見極めないと、アジャイルといって何回も工程を繰り返しても「いつまでたってもできない」ということもあります。
つまり、ウォーターフォールかアジャイルかの問題ではなく、これら3つの不確実性のうちどれをどの時点で誰が負担するかの問題になります。
「完成保証なんて出来ない」と思っている人もいるかもしれません。当然ですが、ここは現状に合わせて適宜修正を行うことになります。「出来るかどうかわからない」という状態はウォーターフォール開発的に言えば「要件定義が終わっていない」ということになります。実はウォーターフォール開発でも現状分析や要件定義などのいわゆる上流工程は原理的に「完成保証」ができません（し実務上もしません）。要件定義がまとまっても技術的にできないことが後になって発覚する場合もあり得ます。そういうのを防ぐ為にも「プロトタイプ」を要件定義の間に行うこともあります。また、テスト工程では「要件定義のバグ」も考慮して期間や費用の見積もりを行った方がよいでしょう。
私の経験では、要件定義の段階で大体プロトタイプを作成しますしそれなりの費用をいただいております。
ウォーターフォール開発の利点の一つですが、「仕様を確定させる」というのがあります。これはお客からの理不尽な要求を抑止する効果があります。もっとも「全ての追加要求を突っぱねる」というのは営業的に問題がありますし、私も「当初の約束でないタスク」をしたこともありますが、一定の線引きがないと収拾がつかなくなります。
仕事というのは契約なので「何を何処まで、幾らでどの期間で」というのを確定させるには工程もある程度は確定している必要があります。ウォーターフォール開発というのは、一般的なビジネス習慣と親和性が高いということになります。
一方でアジャイルという言葉には曖昧性が含まれています。つまり誰にとってアジャイルか？ということです。顧客企業にしてみれば「仕様変更がアジャイル」というかもしれませんが、上記の筆者の言いたいことは「アジャイルは完成保証を前提としない」というこのように読み取れます。こういう認識の違いは、ウォーターフォール以上に、後工程でほぼ確実に契約上の衝突として顕在化します。避けたいところです。アジャイルと言って何でもかんでも「不確定」としてはいけません。
『『アジャイル開発の失敗率は268%も高い』のコメント欄が面白かったので紹介するよ』という記事もあるので、基本的に開発プロセスについてはそもそも比較自体が怪しいということは知っておいた方がよいかと思う。
また、アジャイル開発外部委託モデル契約についてを引用しますと『アジャイル開発においては、開発過程において仕様変更を柔軟に受け入れる場合や、そもそも仕様が明確でない場合等がある。しかし、こうしたアジャイル開発の特徴に対するユーザ企業側の理解が十分でない場合には、期間内に成果物が完成しない等により、ユーザ企業とベンダー企業の間でトラブルとなるケースも発生するとの指摘がある。』とあります。
つまり、ウォーターフォールでもアジャイルでも、モノができなければ揉めます。逆説的になりますが、経験上、信頼されている開発者（会社）は顧客からアジャイル（準委任）を要望され、信頼されない開発者（会社）は顧客からウォーターフォール（請負）を強制される傾向があります。
つまりプロセスは技術的な選択というよりも、信頼関係の結果として決まる側面もあり、あまり声高にアジャイル（準委任）を叫ぶと逆効果ということもあります。
ウォーターフォール vs アジャイルと見てきましたが、『信頼されている開発者（会社）は顧客からアジャイル（準委任）を要望され』ということで、私もアジャイル的に開発を進めたことがあります。つまり顧客と長い付き合いになり、いい意味でなし崩し的になると、開発スタイルとして「プロトタイプ１」、「プロトタイプ２」・・・「完成！」、みたいなことがありました。これはいちいち顧客の要望を細かく聞かなくても、モノを見せながら適宜（アジャイル的に）直していけばいいやという感じで成立していたこともあります。
その他の印象に残るアジャイル的な開発プロジェクトになりますが（まぁ時効ということで告白しますと）、ある意味ぶっ飛んだプロジェクトで、ソフトウェアのリリースが直前になって差し止められるという究極のアジャイル、を経験しました。これは笑い話のようでいて、「価値判断が最後まで確定しない」という意味では、現実に最も忠実な開発プロセスだったのかもしれません。数か月の努力が無になったのですが、お金をもらった以上こちらとしても問題なく、上記の例外の1%ということで、私の経験上これ以上のアジャイルはないかと思います。
東京都、内製AIプラットフォーム「A1」本格運用開始 職員がノーコードで業務アプリ開発・共有
今に始まったわけではないが、IT系の新しい技術が出てくると、まるで冷やし中華のように「○○始めました」という記事が出てきます。もちろん当人たちは真剣（？）にやっているかと思いますが、ただ流行りを追っかけているだけとうことであれば資源（この場合税金）の無駄遣いになります。
ということで、いち東京都民として、税金の無駄遣いにならないか検証するために、覚書ということでメモします。一年後ぐらいに検証できればと思います。
AIによって、プログラマーが淘汰されようかという今になって「次世代のプログラミング言語とは何を言っているのか？」と返されそうですが、今とあるプロジェクトをやっておりまして（具体的なことは控えます）、AI時代に必要なプログラミング言語についてより意識するようになってきました。
今までのプログラミングとは「人間からコンピューターへの指示」ということでした。ではAI時代になると何が変わるのでしょうか。
現状、AIを使ったプログラミングは次のような形になります。
人間 → [自然言語（プロンプト）] → AI → [プログラム] → コンピュータ
これについてまず考えられるのは、次のような形です。
人間 → [次世代言語] → AI → [プログラム] → コンピュータ
つまり、人間とAIの間に共通言語を持てないか、という発想です。
さらにいうと、
人間 → [次世代言語] → AI → [次世代言語] → コンピュータ
ここまで踏み込めれば、AIが生成した内容も（原理的に）人間が確認可能になります。
つまり、問題が発生したときに「何が意図されていたのか」を追跡できるようになります。
ここで当然、次のような批判が出てきます。
人間 → [次世代言語] → AI
AI → [次世代言語] → コンピュータ
同じ言語を使うのであれば、AIは人間が入力した内容をそのまま返すだけではないか、というものです。
実際に、そういうことは起こり得るでしょう。
ポイントは、人間・AI・コンピュータの間で共通言語を持つこと自体にあります。
自然言語ではなく、このような言語を想定する理由は以下のとおりです。
一方で、従来のプログラミング言語との違いは、
にあると考えています。
このアイデアは一見すると突飛に見えるかもしれませんが、実は全く新しいものではありません。
第5世代コンピュータで目指されていた、論理型言語の思想に近いものです。
論理型言語の代表格であるPrologは、当時日本でも注目されました。
また、このブログでたびたび触れているADPも、Prologをベースとしています。
また、Grokに言わせるとLLMとPrologをつなぐアイデアは既に研究対象となっているようです。AIに聞けば多数出てくるようです。下記面白そうなもの2点をピックアップします。
・Arithmetic Reasoning with LLM: Prolog Generation & Execution
LLMが自然言語の算術問題からPrologの述語・ルールを生成し、Prologインタプリタで実行。CoT（Chain-of-Thought）より精度が大幅に向上した実験。
・LLM and Prolog: the logical alternative to chain-of-thought reasoning (Medium, 2025)
金融領域での実践例。LLMが自然言語からPrologルールを抽出し、シンボリック推論エンジンで処理。非常に読みやすい解説。
そりゃPrologを知っている人なら絶対に考えるよなという話ですね。
Prologのような言語は「宣言的」と呼ばれます。
つまり、
という考え方です。
現在のAIによるコーディングもこれに近く、人間が「何を作るのか」をプロンプトで与え、「どう作るか」はAIが担っています。
この役割分担を前提とすると、
「AIは入力をそのまま返すだけではないか」
という批判にも、ある程度対応できます。
もう少し踏み込んだイメージとしては、
という形です。
ここでいう「述語」は論理型言語の用語で、「関数」に近い概念です。
処理手順ではなく「満たすべき条件」を中心に表現することで、結果の妥当性を人間が確認しやすくなります。
とはいえ、このような構想は「言うは簡単で実現は難しい」ものです。第5世代コンピュータプロジェクト自体が頓挫した経緯もあり、AIを使えば当時の問題は解決できるのか？という問いは依然として残ります。
具体的には、
・人間に読みやすいと言ってもPrologはコンピュータよりの言語である。
・宣言的といっても、それだけですべてが上手くいくわけではない。Prolog自体が流行っていない。
・現実案としては、コメントがAIに対する補足（プロンプト）になるが、そうすると自然言語が残ることになる。
というジレンマがあります。特に「宣言的プログラミング」とは当時一瞬流行ったパラダイムになりますが、純粋さを追求すると却ってコードを分かりにくくする側面があります。またAIの出力は手続き的にもなりえます。このあたりの折り合いをどうつけるのかというのが課題かと思います。
このような「純粋な理論」と「現実の泥臭さ」の板挟みを解決するために、私は一つのアプローチをとっています。例えば、ADPは、Prologをベースにマルチパラダイムを追求しています。つまり純粋な宣言的なパラダイムを捨てて、手続き的にも書けるようにしています。このあたりの落としどころが現実的ではあるかと思います。
もっとも、私自身も30年ほど前にこうしたアイデアの断片を考えたことがあります。
さらにいうと、ADPの機能として次世代言語に必要な要件を備えることができれば、ADPそのものが次世代言語になり得るのではないか、とも思っています。
夢は広がりますが、まずは時間を見つけて少しずつ形にしていきたいところです。