人月から印税へ

みずほ銀行がまたシステム障害を起こしたことで、かつて

システム障害はなぜ二度起きたか　みずほ、12年の教訓
https://shop.nikkeibp.co.jp/front/commodity/0000/193570/

を出した日経コンピュータさんがウォーミングアップを始めたんじゃないかと思いましたが、どうやらシステム障害というよりも業務運用上の失敗によるクラッシュだったようです。

システム刷新自体はほぼ問題なく出来ていたはずで、それはこちらの書籍にも書かれていましたので、先日のニュースを聞いたときにちょっと驚いたのですが、運用での問題と聞いたことで理解は出来ました。

みずほ銀行システム統合、苦闘の19年史　史上最大のITプロジェクト「3度目の正直」
https://www.nikkeibp.co.jp/atclpubmkt/book/20/277410/

ただ、まあなんといってもシステム開発は現代企業のほぼ全てにとって共通する難しい課題です。

「人月の神話」という読まれない名著が生まれたのは45年も前ですが、まだまだシステム開発・プログラミングプロジェクトは人月のルールに縛られています。

そもそもソースコードを書くという作業は、長く書けば良いというわけではありません。不具合無く同じ機能を実現出来るのであれば、短い方が良いのです。長いソースコードは、ロードにも送信にも時間とコストがかかってしまいます。ですので、ソースコードを書く作業そのものも、長く時間をかければ良いというわけでもありません。求められたものを正確かつ短期間かつ出来れば短いソースコードで実現出来るかどうかが、その作業の成果として評価されます。

しかし、プログラムのコードを短く書き、しかも短時間で作成し、機能を満たしたシステムやソフトウェアを正しく業務評価出来る企業ばかりでもありません。結局は人月で見積もりし、人件費も時間ベースで計算する慣習は残っています。

システムやアプリの性能機能を正確に評価し、成果給や機能ベースの見積もりを出せるようにはならないものでしょうか？

あるいは、そのような機能や成果の評価を行うのが難しいのであれば、いっそのことクライアント側でSAPやノーコードのシステムを使って作る方が一般的な時代になるかも知れません。

もちろん、そのノーコードのシステムを組むクライアント企業内でも人件費は必要で、結局この作業自体も時間をかけた方が評価（あるいは残業代）を得かねないという同じ問題に直面します。

さらに、その元になるシステム自体を作る人だって必要ですが、そのシステムを作成するのに必要な人件費の算定は、社内にて能力給として支払うしかないでしょうか。

ソースコードと違う、いわゆる文系的な原稿にもお金の問題はあります。

小説やノンフィクションとかコラムとかにも原稿料という長さに応じた、人月的な、時間給的な報酬が存在します。

原稿の長さによって支払われる原稿料の他に、それが本となって売れたら印税という成果給も存在します。

ソースコードを書く業務にも印税的なものがあれば、その業界でも変わってくるでしょうか？