いよいよ、下巻🕺

ここからはより深く、

• コードの改良（第５部）

• システムの考察（第６部）

• ソフトウェア職人気質（第７部）

といった

コンストラクション　＝　コードだけ勉強すればいいではない

を学べる〜〜〜〜✨

感想

エンジニアとして現役だったときは、品質を誰よりも重視して管理職になったのに、コードの現場から離れて数年もすると、収益やコスト優先で、机上デバッグのみでテストすら不要と端折り始める（＝コンピテンシートラップ）にハマる管理者、経営者多いからなあ（アドバース・セレクション）。

優秀なエンジニア　＝　優秀な管理者

とは限らない。

詳細

見出しとしては、

1. ソフトウェアの品質特性

2. ソフトウェアの品質改善技術

3. ソフトウェアの品質改善技術の相対的な効果

4. 品質保証はいつ行うのか

5. ソフトウェア品質の原則

6. 参考資料

7. まとめ

外部特性と内部特性をきちんと理解しておくことは大切。
品質と一言に言っても、要は、

開発者とユーザーでは、求めている品質に違いがあるよ！

ってこと。

インストラクター経験を通じて、

お客さんは研修で、操作がわかりにくいとか資料が読みにくいとか色々と持ち替える要望を出してくれて、開発部門とかに上申しても、

「使いにくいとかどうすればいいかわからないなら、自分達でコードを見ればいい。資料が見にくくてもコードを見ればわかるだろ！」

とキレ気味に言ってくる開発者が結構いた。

で、いざ開発部門から異動してきた人と飲み会で話して、コードを理解云々以前に、殆どのユーザーさんがコード自体を見ることすらできないことを飲み会で初めて知る

って結構あったもんなあ。

自分の見（扱）える情報がいつも相手も見（扱）えるとは限らない。
思い込まずに確認すること。

他にも、

現地でカスタマイズして、

パッケージの不具合を目先で改修するエンジニアさんもいたんだけど、そんな人ほど、

「お客さんの目先の要求に迅速に対応できるのがエンジニア」

と考えてるようで、
システム全体の統合を意識せず、
文書とかコメントなどでなぜそのカスタマイズをしたかすら残さず、
「コードを読めばわかる」で勝手に改修を行なってた。

それを本社の開発部門も把握しておらず、いざ新バージョンをリリースする段になって、
現地で勝手なカスタマイズだけが数十万件単位にまで積もって、新パッケージに盛り込まないと行けなくなって…

って感じで、
カスタマイズした情報資産の洗い出しだけで数年とかかけざるを得なくなっていた。
👉リリースの遅延　＝　見込み（＝機会的利益）の損失

• 機械に疎い　＝　非エンジニアなんだから当たり前

• 生真面目　＝　目先の問題が解決すればいい

• 全体を見ようとしない　＝　ソースなんて読めないからわからない

ユーザーさんが多いから、現地のエンジニア対応がそうならざるを得ないのもわからなくはないけど、
現地の身勝手な信念とべき論、「俺たちの時代はこうやってきた」は、
結果、品質が保てない。

別に良い悪いの話ではなく、

システムって裏と表が全て繋がっている（フィードバックとフィードフォワード）から、きちんと管理できず、「目先だけで動けばいい」でカスタマイズばかりやっていると結局、システム全体の品質が維持できなくなる。

管理を意識しないと品質は保てない

ってだけの話。

良いシステムは大体、

ひとつの小さなコードが、システム全体で影響し合ってる　＝　色即是空

「経験から学んでるから、そんなことは言われなくても当たり前。」

と言って、自分の経験から学べてないからこそ注意される人ほど、
言われても素直に聞かずに、今日も同じようなボロボロなコードを量産したり、テストを行わなかったり、勝手にカスタマイズしてたなあ。

自分のやり方　＝　正解

と思っているようで、、、（そもそも正解なんざない世界なのに）。

まとめ

コンセプトの完全性　＝　システムの目的

をしっかり携わる人全てに共有できてないと、
好き勝手なコードとそれぞれの手前勝手なべき論の押し付けで、
ソフトウェアがゲシュタルト崩壊する！

目先を優先しても良いことばかりではない。

本章以外の参考文献

⒈コンセプトの完全性

については、こちら。

ひとつ目は捨て石にしろ
とか、CODECOMPLETEでも結構、引き合いに出すくらい読まれない名著。

⒉コンピテンシートラップやアドバース・セレクション

については、こちら。

経営学の本で、一見コードとかプログラミングの話からは逸れるけど、

プロジェクト管理　＝　マネジメント

だから経営学に触れておいて損はないかな。
（プログラミング教育だけで、マネジメント教育を受けてない管理者がどこの現場でも苦労してる、、、プログラミングの専門ではあっても管理の専門ではないからね。。。）

⒊フィードバックフィードフォワード

については、こちら。

脳科学を通じたデザインの本だけど、
外部特性と内部特性から一歩進めてユーザーインターフェースと裏側のシステムが統合出来てるとはどういうことかなども参考になる。