【開発哲学3_27】〜『CODE COMPLETE第２版　第27章(下巻)』の感想〜プログラムサイズが及ぼす影響

いよいよ
第６部システムの考察✨✨

感想

冒頭のコミュニケーションパスの話は、プロジェクト管理者には必読かなあ。

人数を単純に10倍に増やせば、それだけ生産性が10倍に増える

と考えるのは大間違い。
システム規模と工数は単純比例しないからねえ。

むしろ、

人数が増えればそれだけコミュニケーションパスが増えるから、その分、元々業務や会社で働いたことがない人が増えると、やり取りの数も増えて、むしろ生産性は落ちるんだよねえ。

コミュニケーションって要は、

作業するにあたって必要な情報をやり取りすること

だから、（これまでの記事でも書いたけど、）コミュニケーションツール導入すれば、円滑なコミュニケーションで、情報が共有できるみたいな単純な話ではないんだよねえ。
（特定のひとつのパスの中でしかやり取りしていない話を、双方だけわかったけど、実は、他のパスの人には全く共有してないのに、他の人全員も知っている前提で話してくる管理者なんてよくいるし💦💦）

なので、

何かのプロジェクトで社内コミュニケーションツールがあっても、

コミュニケーションツールには情報をひとつにまとめる力がない

から、Q＆A表みたいな情報一元化を作るか作るように提案してる。

工数も、

システムの規模がn倍になるなら少なくとも、

工数　=  n x 1.5

で計算するようにしてる。
（例）システム規模が2倍ならば、工数は3倍以上。10倍ならば、15倍。

詳細

見出しとしては、

1. コミュニケーションとチームに人数

2. プログラムの規模の範囲

3. プログラムの規模がエラーに及ぼす影響

4. プログラムの規模が生産性に及ぼす影響

5. プログラムの規模が開発作業に及ぼす影響

6. 参考資料

7. まとめ

てな感じ。

日本プログラマ業界を渡り歩いてると、

モラルライセンシングに陥って、仕事やプロジェクトの本質を見誤ったまま、人数を増やせば、増やした分、生産性が上がる
👉納期をさらに短縮しても問題ない。
と見積もりが甘い管理者や経営者が多い。

そういう会社ほど人材会社なんかを通じて、

安易に、今回使うプログラミング言語の専門を集めようとする。

＜プログラミングの専門で業務知識がない人と業務知識はあってもプログラミングの専門知識がない人が集まったらどうなるか＞

一歩立ち止まって考えればわかると思うんだけど、そういう会社や管理者ほど、

社内での研修制度や文書、資料の作成もしっかりしてない
↓
コミュニケーションのやり取りに忙殺される
↓
予定にない文書や資料作成、会議が必要になる（作業が幾何級数的に増加）
👉パーキンソンの法則：「与えられた時間の最大まで、作業は膨張する」
↓
（プロジェクトが進まず、納期しか意識しないから）
コンストラクションと品質で必須な設計思想（コンセプトの完全性）、テスト、デバッグ、リファクタリングといったものから削る
↓
リリースして障害が起きる
↓
顧客からの信頼を失い、大惨事
↓
評判が広まり、ますます優秀なエンジニアほど集まらない
↓
さらに、人材を集める会社に高いコストを払わざるを得なくなる
↓
高コストな経営

のパターンが多い。
さらに、今までのやり方を現在の開発環境に合わせて変われる企業は少なく、

で書いた【開発すごろく】を辿り、
いつだって納期ギリギリなパンク寸前かパンクしてる作業量になっていく。
（これが組織やプロジェクトがデカければデカいほど、イノベーションのジレンマを産む要因でもあるんだけど。）

結局、長い目で見れば、

どこかの会社に外注したり、人材派遣会社を通じて必要な時だけ人を連れてくるよりも、

業務も理解させながら、プログラミングもできる正社員を育成して増やす
その中で優秀な人を管理者として経験を積ませる

方が、効率的で賢いんだよねえ（言われりゃ当たり前なんだけど）。
（最近はどうか知らないけど、大規模なプロジェクトのマネージャーさんを、派遣社員で時給で雇うみたいな求人も結構、数年前はちらほらみてたなあ。）

とあるコンビニの決済アプリで数年前に起きた事件でも、

当初は、すでにリリースされてたアプリと別に、決済アプリを作る計画
↓
納期を設定。
↓
人を集める、発注する。
↓
計画がスタート
↓
デジタルをよく知らない経営陣の鶴の一声
↓
元々のアプリに決済機能を追加する計画に変更
納期はそのまま
↓
納期どおりに決済アプリをリリース。
↓
セキュリティ検証が十分ではなく、
利用者が不正に出金されるトラブルが多発
↓
社会問題化
↓
決済アプリ事業から一時的に撤退。
↓
見込んでいた売り上げの消失

過去には他にも、

セカンドシステム症候群

使い勝手が良くて普及してたシステム
↓
普及した結果、顧客から様々な要望が増える
↓
次のシステム改修（＝バージョンアップ。セカンドシステム）でなるべく要望を盛り込もう。＝売り上げがさらに上がると見込む。
↓
全体像が崩れるからと既存の開発者が反対
↓
経営者が既存の開発者を解雇し、他から開発者を連れてくる
↓
自意識過剰で、業務をわかってない開発者ばかりでプロジェクト進まない
↓
規模が大きくなりすぎ、納期もギリギリ
↓
設計も練れておらず、機能が矛盾だらけで、システム全体が崩壊
👉ゲシュタルト崩壊
↓
かえって使い勝手が悪くなる
↓
誰も使わなくなる
↓
いつの間にかサービスが終了する

も良くある話。
（確か、何かの本にNetscape 【ネットスケープ】

か何かのブラウザシステムがまさにその歴史を辿ったて書いていたなあ。）

ゼロから何かを作るより、

元々あるサービスに機能を追加（＝決済アプリの例）、バージョンアップさせる（＝セカンドシステム症候群の例）の方が、簡単そうに見えて、

⑴　既存のコードを読み込む。
⑵　機能的なつながりを理解する。
⑶ 　⑴、⑵をした後で、新たな機能を追加する。
⑷ 　⑶の作業中に発見したバグやエラーの原因を改修する

などの作業が増える分、余程時間がかかるし、慎重にやらないと元々の機能自体を壊すか改悪する羽目になるんだけどね。

まとめ

💃頭の中だけの単純計算は、物事を複雑にしかしない
安易に人だけ増やして、生産性は落ちるだけ
しっかりした見積もりと管理が重要🕺

参考文献

セカンドシステム症候群、コンセプトの完全性

についてはこちら

モラルライセンシング

についてはこちら

イノベーションのジレンマ（経営者向け）

については、こちら

イノベーションのジレンマに対する熱烈なラブレター的な本（経営者向け）
も次いでに、、、

プロジェクト管理者向け

はこちら

さてと、

💃週末はゆっくり休む〜〜〜🕺