他人の書いたものについて堂々と書くのは気が引けたもの。でも、書いてしまう。。。しかもかなりどうでもいい内容で。。。とはいえメモなので許して欲しい。
LLMで実現されたデザインパターンの夢 - きしだのHatena
デザパタで紹介されているバターンは粒度が大きいので簡単に適用できないし、ましてソフト全体をパターンで組み上げるなんて無理だよね、でも、LLMがやっていることって既存のコードを学習してパターン化（トークン化）して組み上げているんだから、それってデザパタ本が目指したゴールに近いのでは？という内容とお見受けしました。なるほど！と思ったわけです。人から見ればパターンと名付けるほどではないコードのパターンを見つけ出し組み合わせているわけですよね。デザパタを人が抽出する時代は終わった。。。のかも知れませんね。
KKDのDを読経としているのがとてもカッコいいです。で、元ネタが何かは特定できませんでしたが、恐らく、様々な体験と読経から得た要件定義に関する知見をまとめられているのだと思いました。誤読していたらごめんなさい。
ざーっと読みました。このエントリーの冒頭に２つ関連エントリーのリンクが示されていましたのでそれも読みました。
すべてアグリーです。どの視点かは置いておいてください。恥ずかしいので。でも、僕もそれなりにこういった本は読んできたつもりですので、書かれていることはその中からクリティカルなものをあぶり出してくれているのだと感じました。
このエントリーには直接関係ないのですが、これを読んでふと思ったことを書きます。
最近、思うのです。結局、ソフトウェアエンジニアが要件定義でやっていること（特に受託開発の場合）は、 聞いたことを自分の知っているソフトウェアアーキテクチャへマッピングしている作業に過ぎない んだろうなということです。いや、もちろんそうじゃないという人もいるんでしょうけど、僕はそう思うのです。
ビジネスは価値と効率を最大化する仕事だと思います。組織を存続させるためです。構成員であるエンジニアもできるだけ無駄なことはせずにゴールを目指して効率的に作業を進めることを目指すはずです。無駄な作業を排除して作業を効率化する方法の１つは ゴールありきにする 、 ゴールから逆算して作業する だと思うのです。ソフトウェア開発におけるゴールとは何か？コードですよね？コードの集合体であるモジュールや機能やコンポーネントやアーキテクチャ。そんなに単純ではありませんが、エンジニアの頭の中にはそうしたテンプレートがあって、そのテンプレートの空欄を埋めていく作業をしているのだろう。。。と思うわけです。極論をすればですが。でも、そういう面ってあると思うんですね。だからこそ、要件の抽出漏れや誤解が発生してしまうんだろうな、ということです。
でも、これって別にエンジニアが悪いっていうわけではなく何かしらの専門家になるとそういう思考をするものだと思うんです。医者だって専門家の思考パターンや知識があってそれに当てはめようとして診断するわけですよね。
何となく思うのですが、そういうゴールに向かって最大スピードで進める思考と、その作業を俯瞰してプロジェクトトータルの視点で価値・品質・納期を監視する思考の２つを思考を明確にわけて意識して作業するとうまくいくんじゃないかなぁと思うのでした。絵にすると以下のような感じです（揺れてる電車でトラパで描いたので...ごめんなさい）。
最近、以下の本を読んでみたんです。PMBOK7にも対応した一般向けの薄い本です。１つ１つは納得いくものですが、何も経験がない状態でこれを読んでどう活かせばいいのだろう。。。と思いました。
ソフトウェア工学やプロジェクトマネジメント関係の本の多くは実務家が書いた本になります。そこでは様々な有益なノウハウやプラクティスやTIPSが紹介されています。
ただ、こういう超蒸留された知識ってバラバラになっているし理解しにくい。とはいえ知らないよりは知っている方がいつか役立つかも知れない。鶏と卵なんですが。
色々な意味で難しいなぁ。。。と思うものでした。
ただ、DFDが４つの記号ゆえに生き残ったように、使える知識になる知識というのは、最初に知るべき要素って少ない方がいいだろうと思うし、そのときにどこが重要なのか？を考える地図があったらいいのかな。。。と思っています。
実践的なノウハウはそこにマッピングしていく作業になるのかな。。。と。必要に応じてですね。
ふとそんなことを行きの電車で考えました。おしまい。
