技術をコントロールの配下に置く

牛尾さんの記事を読んだ感想をラフなメモ書き。
論理的でないラフなメモ書き。

【参考】
技術者には試行錯誤は圧倒的に悪であると腹落ちした話｜牛尾　剛｜note

クネビンフレームワークについて講演してきました | サーバントワークス株式会社

カネビン・フレームワークで問題解決策を見極める

問題解決アプローチを見極める『クネビンフレームワーク』のメモ: プログラマの思索

【1】クネビンフレームワークのうち、煩雑系の問題には、パターンに基づいて専門知識を使って分析すれば解ける。
つまり、試行錯誤しても解決できる。

しかし、複雑系の問題では、因果関係がすぐには分からない。
しかも、初めて経験した結果、その因果関係が分かる時も多い。

つまり、複雑系の問題では、既存の知識だけで試行錯誤しても無意味。
むしろ、新たな知識や技術を事前にインプットしておき、問題に対処しながら、その適用場面を探っていく。

記事では「技術をコントロールの配下に置く」の重要性を語っているが、同感する。
ソフトウェア開発では、そもそもゴールはあっても、その道筋が明確ではない場面が多い。
手探りでやるしかないのだが、経験値を貯めていくには、関連する技術をすべて自力でコントロールできるようにしておくべき。
そうすれば、経験しながら、自分なりに検査・適応して、成長できる。

【2】そんなことを連想していると、ソフトウェア開発は従来の製造業の生産管理とは別次元の仕事だと思う。
生産管理では、試作できた製品を高品質で大量生産するための量産プロセスの確立に力点を置く。
製造プロセスを標準化する点が重要。

しかし、ソフトウェア開発では、常に新しい技術が出てきて問題の次元そのものが変わってくる。
問題領域が、決められた要件からいかにQCDを守りながらリリースするか、から、コロコロ変わるマーケットに対してタイミングよくどのように開発してリリースしていくか、に変わってきた。
すると、それをコントロールできる技術やプロセスが必要になってくる。

アジャイル開発は必ず2度失敗する～「正しいものを正しくつくる」の感想: プログラマの思索でも、「アジャイル開発は必ず2度失敗する」という話があった。
ここでも、高速にリリースできる開発プロセスを持っていたとしても、「正しいものを作る」という要件定義、要求開発の部分をコントロールできていないと問題解決できない。

日本の設計者の一部では、その問題をデータモデリングとして解決しようとしてきた。
アジャイル開発では、ユーザーストーリーマッピングなど、各種の技法を生み出して対応しようとしている。

【3】ソフトウェア技術者は、技術をコントロールの配下に置く必要性があるので、常に最新技術を習得しようと務める。
すると、彼らは、手段の目的化、という罠に陥りやすい。
新技術を追いかけること、そのものが目的になってしまったり、問題解決よりも、身につけた道具が活用できる問題領域だけに特化しようとしてしまう。

たぶん、日本人特有の病気なのかもしれない。

手段を目的化するのは日本人の病: プログラマの思索

増刷記念「ここはウォーターフォール市、アジャイル町」の裏話の感想～日本人はフレームワークが苦手でいつも振り回されている: プログラマの思索