ソフトウェア開発の真の問題点は、コードを書くことではなく、問題の複雑さの管理にある - YAMDAS現更新履歴

www.oreilly.com オライリー・メディアのコンテンツ戦略部門のバイスプレジデントであるマイク・ルキダスの文章だが、彼が数週間前、「コードを書くことが問題なのではない。複雑さをコントロールすることが問題なのだ」というツイートを見かけた話から始まる。彼はこれに感心したようで、これから何度も引用すると思うので、誰のツイートか思い出せればいいのにと書いている（ご存じの方は彼にご一報を）。 件のツイートは、プログラミング言語の構文の詳細や API が持つ多くの関数を覚えることは重要じゃなくて、解決しようとしている問題の複雑さを理解し、管理することこそが重要だと言ってるわけですね。 これは皆、覚えがある話だろう。アプリケーションやツールの多くは、最初はシンプルである。しかも、それでやりたいことの80％、いやもしかしたら90％をやれている。でも、それじゃ十分ではないと、バージョン1.1でいく

[t-wada]

"解決しようとしている問題の複雑さを理解し、管理することこそが重要" "大規模で複雑になるにつれ、ソフトウェア・アーキテクチャの重要性は増す" "自動生成にとらわれ過ぎて、複雑さをコントロールするのを忘れない"

[so-apps]

今でも発注側は複雑な問題を理解できていないから大丈夫。

[hi-hats]

これ本当そうで、平均的な人間の学習能力より複雑さの増加スピードのほうが上回っていることから、問題の複雑さを管理するための技術が今後出てこない限りは式年遷宮できるもののみが生き残っていくだろうと思う。

[aike]

広辞苑とRuby on Railsの文字数は大体一緒と言って説明することある。

[Peophrun]

これはどの職種にも当てはまっていて、仕事の最初のほうでイキって管理も考えずにパラメータ増やすと後で地獄を見ることになる。修正とか変更とか

[j1nsuke]

これはちょっとでも仕事をしたことのあるプログラマならよく分かると思う。

[stealthinu]

『そのうち最終的な目標をプロンプトとして与えれば複雑さを管理しながらエンタープライズの規模まで自己増殖のように規模を増していくプログラムを書けるようになる生成AIが登場』当然そうなるさ

[sa-yama321]

複雑さとの戦いに勝つのは、愚直に継続したリファクタリング。しかし、この愚直に継続したことをやれる人はごくわずかかなと。

[ducktoon]

エンジニアでない人がプロジェクトの進行を急かすことで複雑さが増加、放置されてしまうケースはよく見てきた

[shogochiba]

典型的な文科系だった私でも少し前から理系の本を買って読んでみたりと徐々に理系に興味を持つようになっていたので、大変貴重な記事を有り難う御座います。✨👼😺👨😊

[mnoguti]

複雑さ・・・いかに簡潔な構造に構成し直すかということかな。

[efcl]

“Writing code isn’t the problem. Controlling complexity is.”

[nabinno]

今こそエンタープライズアーキテクチャ (EA) の出番では?

[shichimin]

まさに。プログラミングに限らないよね。＞”プログラミング言語の構文の詳細や API が持つ多くの関数を覚えることは重要じゃなくて、解決しようとしている問題の複雑さを理解し、管理することこそが重要”

[OrientHistory]

生成AIによるコーディングって、建築で言えば大工とか現場作業を楽にするだけだよね。複雑さの問題は設計工程、それも特に増改築の場合なので、そこへのAI活用はまだ困難、だと捉えた。

[yujimi-daifuku-2222]

まあ難しいよね。その複雑性はしばしば人間も扱いきれていないわけで。/システム定義をユーザ側でしろとは言わない。それはエンジニアの領域だから。とは言え自社の業務システムの要件くらいは整理して欲しい。

[hiroomi]

”解決しようとしている問題の複雑さを理解し、管理することこそが重要"書く、パッケージ買う、コピペで解決が付けばよいけど。複雑さはそうじゃない。

[sawat]

要件定義から保守運用まで全てに立ち合い、ずっと一貫した記憶を持ち、全ての仕様と実装を把握してくれるAIが作れれば何とかならないかな…？無理か？

[dot]

ソフトウェア開発はその過程で複雑な業務のなかから価値のあるモノを整理し、時には取捨選択してそぎ落とすことに価値があるので、既存の業務を全部そのままシステム化するようなソフトウェア開発は早晩自滅する。

[mohno]

将来はAIに頼めば開発者（エンジニア）なしで望んだアプリができるようになる、という気はまるでしない。というか、それで済んだら要件定義がコロコロ変わって揉めたりしないよね。

[nerikara4chimi]

あとで読む

[tybalt]

複雑な問題を複雑なまま扱えないのは人間の特性に依拠した限界。機械が全てのコードを生成するなら、一つの巨大なモジュールで全ての問題を解決するようなプログラムが生み出される可能性もありそう。

[koKekkoh]

悩ましい問題。出来上がったシステムを前に、それを一から作ることは忘れて、今あるところからの手間だけを見るからそうなる。

[ponkiti_toya]

最後の問いはシンギュラリティに繋がっていくものだと思う

[sezemi]

だからシニアエンジニアが必要なんだよな

[matsui]

素人ですが未来はそのへんも普通にAIがやってくれると思ってました→“それを行う人間は、問題の複雑さを理解し、それを管理するというプログラミングの宿命といえる問題に直面することになると締めくくっている”

[yarumato]

“生成AIツールで書かれたコードは複雑さを気にしない。複雑さを軽減する役目は、まだ生成AIに耐えられるものではなく、人の仕事である。結局は人がそのコードを理解する必要がある。”

[ghostbass]

B/Sとか渡せば経営上の問題を判定して解決してくれるようなAI…できるかなあ/今のところ「AIに推測推論は無理」と思っているのでまあ当分無理なんじゃあないかな、とも思うわけ。

[uynyannaylalswww]

色々考えさせられる内容だった。

[tekmak]

色々な要望を入れても複雑にならない土作りが米作り

[tpircs]

昔のシステムは四則演算に毛が生えた程度のものだったのに今は証明問題とかパズルやってる感じ。証明問題を納期決められて解かさせられるって出来ない人には地獄の職業だよなってたまに思う。生産性差100倍も普通。

[iwtn]

現実や社会は複雑だから、そこから生まれる問題もまた複雑になる。テンプレみたいなコードを書く速度を上げるよりは、複雑さを解消することが重要と。

[nunulk]

必ずしもそうとはいえない気がする / "多くの開発者は、コード行数を最小限にすることが単純化の鍵だと思っているが、それには一つの行に複数のアイデアを詰め込んだ複雑な呪文になり、コードの読みやすさを損なう..."

[hatebnewone]

自動生成されたコードをうまいこと組合せて利用するために、デザインパターンとアーキテクチャの本読め！ これが結論ではないか？

[natu3kan]

出来ることが増えると管理するパラメータも増えるからなあ。