生産性を上げるとはどういうことなのか？

以下、答えなし、深掘りなし。そして進歩なし？

単位時間当りのステップ数とか、作業時間や人数を増やすとか
いまだにそういうことでプロジェクトの体制を考えたりしてるのが
すごくイケていない。かといって、周りを納得させる尺度や数値は何もない。
イライラ、する。

それから、「設計に時間をかければ」とかいうのも、少し違っているような気がしている。
確かに本番コードを書く以外に、調べたり試したりいろいろする時間は必要だ。
しかし、設計というのが、書類を書き、作業を誰でもわかるようにすること、のように
捉えられているような気がしてて、どうかと思う。
いくら書きものをそろえても、埋められない隙間があり、それが技術というもの、ではなかろうか。

生産性を上げろ、というなら、
集中させること、それ以外のことをさせないようにすること、作業を中断させないこと、休養をとらせること。
それで十分だろうに。

また、生産性いう言葉が「ひとを使って量を増やすこと」として使われ、
SEという言葉が「ひとを使うこと」と言われているところも、釈然としない*1。
エンジニア力とはそういうもんなんだろうか、と今さらながら言ってしまう。
それからマネジメント力とは何なのか、とも思う。

プログラマの思索
http://forza.cocolog-nifty.com/blog/2017/05/post-3793.htmlforza.cocolog-nifty.com

以下、引用のみ。

しかし、「過剰と破壊の経済学-「ムーアの法則」で何が変わるのか」の中に、「ソフトウェアの複雑性は本質的な性質であって偶有的なものではない」という言葉があって、すごくしびれた。

（引用開始）
ソフトウェアの複雑性は本質的な性質であって偶有的なものではない。
したがって、複雑性を取り去ったソフトウェアの実体の記述は、しばしばその本質も取り去ることになる。
数学や物理学は、複雑な現象を単純化したモデルを構成し、そのモデルからある性質を引き出し、実験的にその性質を証明することで、3世紀にわたって偉大な進歩を遂げた。
この方法でうまくいったのは、モデルで無視された複雑性が現象の本質的な性質ではなかったからだ。
複雑性が本質である場合には、この方法は使えない。
（引用終了）

上記の内容は、ブルックスの「人月の神話」の一節そのまま。
なぜ自分がすごく衝撃を受けたのか、考えてみると、ソフトウェア開発の本質に触れているものだから。
たぶん、僕の心のなかにある、ソフトウェアに対する楽しさだけでなく、ソフトウェアへの憎しみというか、なぜこう思い通りにソフトウェア開発をコントロール出来ないのか、という腹立たしさに触れている気がしたから。

なぜコードクローンは良くないのか？

（引用開始）
ソフトウェア実体は、どの2つの部分をとっても似ることがないので、大きさの割にはおそらく他のどの人工構造物よりも複雑なものだ。
似通っている部分があれば、2つの類似部分を1つにする。
この点において、ソフトウェアシステムは、重複要素(部品)が豊富なコンピュータやビルあるいは自動車などとは全く異なっている。
（引用終了）

その理由は、ソフトウェアの再利用が進まないからだ。
たとえば、自動車やパソコン、スマートフォンのような工業製品は、再利用可能な汎用部品を組み立てる手法と大量生産することを組合せることで、規模の経済を生かし、経験曲線効果を生かして、1個当りの製造コストを劇的に減らす。
しかし、この「規模の経済」「経験曲線効果」というコストメリットを享受しうる生産手法がソフトウェア開発には全くといっていいほど通用しない。

*1:というか、腹立つ、ムカつく