私のソフトウェアの開発手順とその進化(1)
初心者の方は特に感じられることかと思いますが、さぁ、プログラミング言語を覚えた！プログラムをどうやって作成するのでしょうか？
例えば、ゲームのプログラムを作りたい！と思ったときに、手が勝手に動いて、気が付いたら思う通りのゲームを作れる人は多分、これ以降は読まなくてもよいかもしれません。
これは皮肉ではなく、私自身が本当にそう思っているということもありますし、一方で私には無い才能ということで憧れでもあります。
実は、ソフトウェアの開発環境はこのようなある種の、プロデューサーといいますか映画監督といいますが、要するに『何を作るかが分かっている人』が潜在的には求められており、AIがコーディングを助けるようになると、ますます重要なポジションになるかと思います。
これは、特にソフトウェアをある種の表現行為に使う（ゲームとかAI動画等）場合に必要な人材と言えるかもしれません。
一方で、ソフトウェア開発というのはもっと多種多様な世界ともいえます。こういうと大げさに聞こえますが、『どう作るかは分からないが、完成図が見えている人』と『完成図を貰えれば、あとは作れる人』と組み合わせると上手くいくケースもあります。大半のエンジニアが関わる業務アプリやらECサイト、その他、WEBアプリや組み込みアプリがありますが、『現場で使う人』と『現場の人が使えるツールを作る人』という組み合わせもあるでしょう。
このように作る人と作ってもらいたい人が別になる、つまり組織的にプログラムを作るようになると、作るものの合意をしたり役割分担をすることになり、『誰がいつ、何をするか？』というソフトウェアの開発手順が必要になってくるでしょう。
ソフトウェアの開発手順の古典的かつメジャーな方法が、「ウォーターフォール開発」ということになります。
段取りを踏んでプログラムを作りましょうということですが、『こういう面倒なことは知らなくてもよいのでは？』と思われる方も、自分が仕事としてプロジェクトに参加して、プログラムを組む場合は、つまり組織的に開発するということは何らかの開発手順を踏むことになりますので、勉強されることをお勧めします。
ウォーターフォール開発は、色々細かいところはありますが、概ね
・要求仕様（Requirements）
・設計（Design）
・実装、開発（Implementation）
・テスト（Verification）
・運用（Maintenance）
という風に工程を分けて、開発を行うということです。『要求仕様』というのは一言でいうと『何を作るのか？』を決める作業で、『設計』は『どう作るのか？』を決める作業、『実装』で実際にモノを作り、『テスト』で動作確認を行いバグをとりのぞき、『運用』では実際に使っていくということになるかと思います。
実装、テスト、運用についてはプログラマの方には分かりやすいかと思いますが、要求仕様や設計についてはピンと来ないかもしれません。いわゆる上流工程と言われている工程が要求仕様になるかと思います。具体的になにをするかは様々ですが、ここではお客さんと頻繁に打ち合わせを行うことになります。よく、オプションとして「AとBどちらにしますか？」というとお客さんから「どっちもできるように対応して」とか言われるところです。ここですかさずに「そうしますと工数が増えますね。あとで概算見積もりに入れます」と言えるかどうかが、その後の開発が修羅場になるかどうかを決めることになります。
設計作業は、名前ほどキチンとしておらず曖昧かもしれません。例えば、昔は「オブジェクト指向は大規模開発に向く」と喧伝され「UMLが・・・」とか「オブジェクト指向設計」やら「モデリング」やら言われた時代がありました。これらの声が下火になった、今、はたしてどこまで浸透しているかは謎ですが、批判を覚悟であえて言いますと、大規模開発において信頼性のあるアプローチ（設計手法）はトップダウンや分割統治かと思います。つまり機能ごとに分割してアプリケーションを定義するということになります。ECサイトなら「購入サイト」や「商品・その他マスター管理」、「顧客管理」、「注文管理」とかになるかと思います。機能分割に着目することは「オブジェクトがどうのこうの」というより、より上位の、つまり抽象度が高い操作と言え、分割にも適しているでしょう。
さて、以上は、『私のウォーターフォール開発』の理解です。日本でのソフトウェア開発の現場を見てきましたが、こういうことをキチンと分かっている人や出来ている人は経験上少なかったかと思います。
『お前はどうやねん』と言われそうなので、予め答えますと、プログラミングと同様に一通りの勉強はしました。また、キャリアのごく初期は幸運にもウォーターフォール開発を行っていた経験があり、理論と実践で学ぶことができました。
一方で、繰り返しになりますが、現場現場で、関わる人達の理解に差があったり、ケーススタディーがキチンとしていない面もあり、状況は「カオス」かと思います。
一時期、情報処理技術者試験の受験をやめたことがあるのですが、これは『あまりにもソフトウェア開発手順を無視したプロジェクトマネージャ』がいる現実に落胆して勉強するのが馬鹿らしくなって遠のいたことがあります。
以上、ざっとウォーターフォール開発を見ていきましたが、ウォーターフォール開発の批判の1つが、「各工程を厳密に区切る」ところにあり、Wikiにもあるとおり、「全工程に間違いがない」ことを前提にしている開発手順と指摘されています。
例えば、要求仕様の段階で、「そのままの要求仕様を満たすものは作れない」となると大問題ということになります。
これに近いものになりますが、私が気を付けているのは「プロジェクトメンバはどのタイミングで、作成するものを具体的にイメージ出来るか？」ということになります。言葉を変えると「この情報でプロジェクトメンバは開発が滞りなくできるか？」ということになります。
ソフトウェア開発の現場で、よくあるトラブルの１つは『プログラムを作れない』という状況になります。要求仕様の間違いもありますが、どうも一部のエンジニアは『出来ない』ということが言えなかったり、自分の能力不足を認めなかったりし、想定（報告）以上の時間を使って開発が遅延します。
次回では、ウォータフォール開発をもう少し突っ込みつつアジャイル開発についてみます。
ウォーターフォール vs アジャイル論争の誤解
最近、とあるAI絡みのプロジェクトでLLMを使ったシステムの研究開発をやっておるのですが、個人的に応用が利くものができつつあると実感しているのですが、一方で、今は広める訳にはいかないので、成果の一部を小出しにします。
ちなみに、「オブジェクト指向おじさん？」の記事については、「感情的である」というAIからのご指摘を受けてそのうち修正を行いたいと思います。
以下本題、下記の記事にコメントします。
・なぜ、「ウォーターフォールでソフトウェアを作れる」という嘘を信じる人が世の中にいるのか？
・ウォーターフォール開発がダメなのかは、弁護士が請負契約で仕事しないことでわかる？
あくまでも個人的な感想ですが、どうもAIを活用した論調の記事だとは思うのですが、私のAI分析が良い感じだったのでその成果ということであえてコメントします。
１．はじめに：プロセス論争の空虚さと顧客の関心
まず、結論ですが、ウォーターフォールだろうが、アジャイルだろうがその場にあった方法でどうぞとなります。
「プログラマ」ではなくある種のコンサルタント的な立場の人間（SEや営業、アーキテクトもその一人かもしれません）、つまり上司やプロジェクトリーダの元での作業ではなく、非エンジニアの顧客（情報システム部門の方でも、そうでない方でも）と直接話をする場合にわかるかと思いますが、おそらく99%の顧客の関心事項は
金をどぶに捨てることにならないか？（何らかの成果物が出てくるか？）
ということです。顧客目線に立てばウォーターフォールが良い場合もあればアジャイルが良い場合もありますし、ウォーターフォールだろうがアジャイルだろうが、最終的にモノが出来なければ「修羅場」になるということです。
２．契約形態がプロセスを決める
まともな顧客は、RFP（Request for Proposal）を用意して提案書（見積）を求めてきます。
そうでなくても「こんなシステムを作りたいのだが・・・」からはじめに打合せを行ってから、ある程度「何を作るか？」を話し合ってからの見積となります。
この場合、ウォーターフォール開発が想定されるような「システム開発」の場合、ほぼ間違いなく
完成保証があります。
つまり請負契約になります。ここで『ウォーターフォール開発がダメなのかは、弁護士が請負契約で仕事しないことでわかる？』とありますが弁護士が請負契約をしない最大の理由は「原理的に完成保証ができない」からです。つまり裁判になったときには必ずどちらかが負けます。弁護士が仕事を受けるときには原理的に「勝ち」を保証できないことになります。
３．不確実性の正体：本質・要求・技量の3層構造
一方でソフトウェア開発の場合は、「不確実性」があったとしても顧客と開発者が成功に向けて協力すれば、「何を作るか？」ということに関しては何らかの合意ができることが多いです。また、記事にあるような『不確実性が高い』というのは、ソフトウェア開発が持つ「本質的不確実性」の他に、開発するエンジニアの技術不足や経験不足「技術的不確実性」ということもあります。もちろん顧客の都合で仕様が変わる場合「要求不確実性」もあり、これらをきちんと見極めないと、アジャイルといって何回も工程を繰り返しても「いつまでたってもできない」ということもあります。
つまり、ウォーターフォールかアジャイルかの問題ではなく、これら3つの不確実性のうちどれをどの時点で誰が負担するかの問題になります。
「完成保証なんて出来ない」と思っている人もいるかもしれません。当然ですが、ここは現状に合わせて適宜修正を行うことになります。「出来るかどうかわからない」という状態はウォーターフォール開発的に言えば「要件定義が終わっていない」ということになります。実はウォーターフォール開発でも現状分析や要件定義などのいわゆる上流工程は原理的に「完成保証」ができません（し実務上もしません）。要件定義がまとまっても技術的にできないことが後になって発覚する場合もあり得ます。そういうのを防ぐ為にも「プロトタイプ」を要件定義の間に行うこともあります。また、テスト工程では「要件定義のバグ」も考慮して期間や費用の見積もりを行った方がよいでしょう。
私の経験では、要件定義の段階で大体プロトタイプを作成しますしそれなりの費用をいただいております。
４．ウォーターフォールの利点：仕様確定による“境界の明確化”
ウォーターフォール開発の利点の一つですが、「仕様を確定させる」というのがあります。これはお客からの理不尽な要求を抑止する効果があります。もっとも「全ての追加要求を突っぱねる」というのは営業的に問題がありますし、私も「当初の約束でないタスク」をしたこともありますが、一定の線引きがないと収拾がつかなくなります。
仕事というのは契約なので「何を何処まで、幾らでどの期間で」というのを確定させるには工程もある程度は確定している必要があります。ウォーターフォール開発というのは、一般的なビジネス習慣と親和性が高いということになります。
５．アジャイルの曖昧性：誰にとってアジャイルなのか？
一方でアジャイルという言葉には曖昧性が含まれています。つまり誰にとってアジャイルか？ということです。顧客企業にしてみれば「仕様変更がアジャイル」というかもしれませんが、上記の筆者の言いたいことは「アジャイルは完成保証を前提としない」というこのように読み取れます。こういう認識の違いは、ウォーターフォール以上に、後工程でほぼ確実に契約上の衝突として顕在化します。避けたいところです。アジャイルと言って何でもかんでも「不確定」としてはいけません。
『『アジャイル開発の失敗率は268%も高い』のコメント欄が面白かったので紹介するよ』という記事もあるので、基本的に開発プロセスについてはそもそも比較自体が怪しいということは知っておいた方がよいかと思う。
６．信頼関係がプロセスを決める
また、アジャイル開発外部委託モデル契約についてを引用しますと『アジャイル開発においては、開発過程において仕様変更を柔軟に受け入れる場合や、そもそも仕様が明確でない場合等がある。しかし、こうしたアジャイル開発の特徴に対するユーザ企業側の理解が十分でない場合には、期間内に成果物が完成しない等により、ユーザ企業とベンダー企業の間でトラブルとなるケースも発生するとの指摘がある。』とあります。
つまり、ウォーターフォールでもアジャイルでも、モノができなければ揉めます。逆説的になりますが、経験上、信頼されている開発者（会社）は顧客からアジャイル（準委任）を要望され、信頼されない開発者（会社）は顧客からウォーターフォール（請負）を強制される傾向があります。
つまりプロセスは技術的な選択というよりも、信頼関係の結果として決まる側面もあり、あまり声高にアジャイル（準委任）を叫ぶと逆効果ということもあります。
７．経験談１：信頼関係が育んだ自然なアジャイル
ウォーターフォール vs アジャイルと見てきましたが、『信頼されている開発者（会社）は顧客からアジャイル（準委任）を要望され』ということで、私もアジャイル的に開発を進めたことがあります。つまり顧客と長い付き合いになり、いい意味でなし崩し的になると、開発スタイルとして「プロトタイプ１」、「プロトタイプ２」・・・「完成！」、みたいなことがありました。これはいちいち顧客の要望を細かく聞かなくても、モノを見せながら適宜（アジャイル的に）直していけばいいやという感じで成立していたこともあります。
８．経験談２：究極のアジャイル
その他の印象に残るアジャイル的な開発プロジェクトになりますが（まぁ時効ということで告白しますと）、ある意味ぶっ飛んだプロジェクトで、ソフトウェアのリリースが直前になって差し止められるという究極のアジャイル、を経験しました。これは笑い話のようでいて、「価値判断が最後まで確定しない」という意味では、現実に最も忠実な開発プロセスだったのかもしれません。数か月の努力が無になったのですが、お金をもらった以上こちらとしても問題なく、上記の例外の1%ということで、私の経験上これ以上のアジャイルはないかと思います。
東京都がAIを使って、業務アプリを開発・共有するらしい
東京都、内製AIプラットフォーム「A1」本格運用開始 職員がノーコードで業務アプリ開発・共有
今に始まったわけではないが、IT系の新しい技術が出てくると、まるで冷やし中華のように「○○始めました」という記事が出てきます。もちろん当人たちは真剣（？）にやっているかと思いますが、ただ流行りを追っかけているだけとうことであれば資源（この場合税金）の無駄遣いになります。
ということで、いち東京都民として、税金の無駄遣いにならないか検証するために、覚書ということでメモします。一年後ぐらいに検証できればと思います。
ADSL終了を惜しむ
昔話をするのは年寄りの悪いところと言われますが、一説によると「老けない」とも言われているらしい。というわけで前向きに昔話を。
ちょっと時間が空きましたが、長らく移行期間があったADSLが今年の1月31日に完全終了したとのことです。
ADSLと言えば、私は今から26年前に契約をしましたが、その前は28,800bpsのモデムを使用しており、それまではWEBページを見るにしても「画像を表示しない」というオプションをONしており、「何が表示されているかよくわからん」状態だったのですが、もっともWEBと言えば2chのような掲示板を文字で見ていました。
で、ADSLというのが出るらしいという話が出て、住んでいるところでサービス開始早々、電話で契約をしました。オペレーターの方が「ベストエフォートなんで・・・1.5Mbpsの速度は保証しません。」と言っていたのを思い出します。もっとも実測でほぼ1Mbps以上出ておりかなり快適になりました。まさにブロードバンドの幕開けを感じました。当然このころからIEの「画像を表示しない」オプションを外しました。
26年前（2000年）といえば、今は完全に忘れられた感のあるインパク（インターネット博覧会）も思い出されます。もっとも見に行きましたが何が何だか分からなかった記憶があります。
PCでいうと、IntelとAthlonがGHz競争を行っていました。WindowsXPが出る前で、 IEのバージョンは5とか5.5でした。Dual Pentium IIIのマシンにWindows 2000を入れて、K6-IIIのマシンにWindows MEを入れました。K6-IIIは前のメインマシンでこの年にDual PentiumIIIのマシンを組み立てました。マザーボードが840のものでE-ATXだったのでフルタワーのケースを担いで帰ったのが懐かしいです。当時はパソコンと言えばネットをやるというよりプログラミングが主で、K6-IIIやPentium IIIのマシンでTSPSolverのアルゴリズムの改善に取り組んでいたのを思い出しました。当時、K6-IIIとPentium IIIはクロックは違うものの、同一クロックならほぼ同じ性能で、TSPSolverの実行速度もクロックに比例していました。
各PCは、TCP/IPではなく、NetBEUIでつないでいたのを思い出します。ADSLの最初期はPCにADSLモデムを直結していました。さすがに「大丈夫か？」ということで、セキュリティを考えてこのような構成にした記憶があります。Windowsのファイル共有をインターネット側に出さない措置になります。もっとも当時はウイルスもあるにはありましたが、今から思えば牧歌的ではありました。
その後、引っ越し時に8Mbpsのものに契約変更し、下記のブロードバンドルータ付きのモデムを購入し使っていました。2005年頃ですが、8Mbpsといっても実測で2,3Mbpsだったのを記憶しています。Wi-Fiも設置していましたが、SSIDをみると家だけだったのを思い出します。
その後、2008年に、キャンペーンをやっておったので光回線に変更しました。ので私のADSL歴は8年で幕を下ろしました。またこのADSLモデムも3年程しか使っていませんでした。
光の方は2012年に一度200Mbpsに変えてそのまま使っていたのですが、昨年（2025年）に1Gbpsに変更しました。もっとも体感ではスピードは変わりません。実測では200Mbpsの時代はほぼ200Mbpsの上限が出ており、1Gbpsに変更後は400Mbps程度です。
これは、ご近所さんが光を契約して使うようになったのでそことの共有とのことで、もちろんですが、Wi-FiのSSIDも今では自分のものを見つけるのにも一苦労です。
とまぁ、ADSLを使わなくなって18年になるのですが、それでもいつか使うかもと思ってモデムの方は予備機と合わせて2台残しておりました。ADSLサービスが終了するというニュースを聞いてオークションに出していましたが、大量に出品されており、売り時を逃してしまいました。
ADSLの普及に合わせてサーバーの運用を開始し、Windowsは怖いからLinuxでメールサーバー、WEBサーバーを公開したり、そのノリで本を出したりと、当時を思い出すとなつかしい思いがします。今なら当たり前のように電車でネットをしていますが、当時は何も無かったところからインターネットが出現し様々な進化をリアルタイムで体感できたことはそれはそれで幸せかもしれません。
ありがとうADSL！
兵どもが夢の跡
私自身は2月～4月ぐらいが1年で一番忙しい中で今年は特に忙しく、いまだに確定申告を終えていないという状況なのですが、覚書ということで最近行った某AI見本市に行ってきた感想を書きます。
（何故某見本市とぼかすのかというと、これからネガティブなことを書くので・・・）。
一年半程前にCEATEC 2024にPasocomMini PC-8801mkⅡSRの実機を見てきたときについでに色々見て回りまして、それはそれで興味深いのですが、皆さん熱心にAIをやっておられるという印象でした。プラスして『それはChatGPTで出来るのでは？』という感想もありました。
そこからの進歩は激しく、さらに某見本市はAIと銘打っているだけあって、会計ソフトやら様々のものにAIが組み込まれていて何とも刺激的でした。と同時に呼び込みがうざくじっくり見て回れなかったのが残念でした。なので結局良く分からんところで帰りました。私自身登録を「クライアント関係」で行ったので「開発者関係」でやればよかったと後悔しました。
呼び込みで飲み物やらスイーツを渡しながら「よろしく！」とか言っていたのですが、硬派な私は「いらん！」と断っていました。まぁ最後に「もらってもらわないと私が怒られるんです」みたいなことを言われて「じゃがりこ」をもらったのですが、帰って嫁に顛末を話すと「相変わらず若いねいちゃんに弱いな」と言われる始末でした（もっとも、その前に10人ぐらい若いねいちゃんをかわしたんだが・・・）。
とまぁ、収穫がない時間を過ごしたのですが、ちなみに私が若い時は『そんなもん見るまでもない』と思っていたので、見本市に行ったのは5回もないかもしれません。うち2回が最近ということになります。ので、実はあまりこういう場には慣れていない面もあったりしました。
前に行った見本市がもう30年程前になりまして、データベースソフトのデモを見たり、MCの方が『プロトコル』を『プラタコル』と言い間違える度にニヤっと笑ったりしていたことを思い出しました。
30年前と言えばなんといってもインターネットバブルがありました。まだブロードバンドもなくインターネット黎明期ともいえる時代で当時勤めていた会社の上司は良く『ECサイト』とか『電子商取引がどうした』とか言っていました。私の方はその後、結局そこの会社では勉強できなかったので、数回転職をしてインターネット関連技術を習得した記憶があります。特に思い出すのが、ベンチャー企業に勤めていたときで、色々勉強はできたのですが、ビジネスとしては全く成果が上がらず、少々苦い思い出になります。
某見本市でもベンチャー企業が色々サービスを紹介しているのですが、「それは○○で出来ないか？」というAIあるあるだったり、『AIシステムを月額○○円から』と言われると30年前に流行ったHP制作会社を思い出したり、結局その後の電話攻勢を鑑みると、昔と変わらないことをしているなと思うと同時に「安易にマネタイズをする方向にもっていくと、成功するものも成功しないのでは？」と思いました（Facebookは、2004年から出ておりその後2010年代に花開いた）。
その時に幕張に行けるかどうかは分かりませんが、30年後に見本市をみたら、表面上は今とはまったく違うことをやっているが、実は昔ながらの営業をやっており、年寄よろしく過去を思い出して『兵どもが夢の跡』となるのか？という気もします。まぁ、たかがいちエンジニアの戯言ですね。
要は不完全燃焼だったのですが、私自身はビジネス関係は疎く、今でも真剣にSNSって面白いか？と疑問に思っているぐらいなのでそもそも素養がないので、どうしたものかと思ったら、以前にAIをビジネスに適用させようという強者を思い出したので連絡をしてみました。
中々精力的に活動されている方で、EUがやっているFuturiumというコミュニティサイトで投稿されたりしています。
Toward Semantic Governance: A Structural Proposal to Support the AI Act Implementation
バックグラウンドとしてAI時代の意味インフラ（フレームワーク）を構築しようというアイデアを持った方ですが、私のレベルではピンとは来ない面があるのですが、インターネット時代のSNSと同様に、AI時代のキラーコンテンツになりえるものを感じてはいます。
私自身は、あくまでも開発者としてAIと付き合いたいのですが、そうは言っても『どういった応用があるのか？』を知らないで勉強しても意味がなく情報収集も励んでいる次第です。
ちなみにマカロンは奥さんが嫌いなので徹底的に断って、妙に昔を思い出しながら、じゃがりこを奥さんと食べました。