プログラミングの清掃・清潔・躾

引き続き5Sとプログラミングの話。

③清掃
5Sの定義=「常に綺麗な状態を保ち、汚れや故障がないか点検すること」
→
何も変更する必要が無ければ最初に作ったプログラムのままですから、初期状態を維持できるので”綺麗”な状態は保てますが、変更が入るとだんだん汚くなってきます。これって定義にある”汚れ”ですね。
また、潜在しているバグはほぼ100％存在しますので（対象やサイズにもよりますが、私の経験した分野では100％です）、これが顕在化したら”故障”になります。
でも、プログラム単体では一度運用開始するとなかなか”点検”する余裕は無いので、実際の点検はプログラムが実装されている対象物（自動車とかシステム全体とか）単位でやっていくしかありません。
ただしプログラマーは
・故障が発生したら修正
・外部要因で変更する必要が発生したら変更
などの機会で、いつでも簡単に修正できるように（保守性の重要性は以前書きました）と、修正後も綺麗な状態にしておくことを心がけたいですね。

④清潔
5Sの定義=「整理・整頓・清潔が徹底されている状態を維持すること」
→
職場改善の5Sでは、具体策として典型的なパターンがチェックシートなのですが、これも清掃と同様で一度運用開始してしまうとチェックする機会がありません。
ただし開発中は別で、デザインレビュー、テストスクリプトによる検査、などにより必死に整理・整頓・清潔を維持する努力を続ける必要があります。
作り方も個人任せ、品質担保も個人任せ、ではこれらの維持が絶対できませんから、人と人とのコミュニケーションの善し悪しがここでは相当重要です。

⑤躾
5Sの定義=「守るべきものが守られる状態を習慣化すること」
→
デザインプロセス、コード記述規定、コード修正プロセス規約、などなど、”守るべきもの”はいろいろありますし、現場によって多種多様だと思います。
”習慣化”ですから、いつもやっていなくてはいけないということですね。
経験上、大きなトラブルが発生してその原因をなぜなぜ分析すると、大抵はここに行き着きます、「やるべきことをやってませんでした」というやつ。
じゃあなんでやらなかったの？　という問いには、
・時間がなかった
・ちょっとした変更なので大したことないと思ってしまった
・自分の内部だけの問題なので誰にも言わなくても大丈夫だと思った
みたいな感じです。
プログラムは変更の影響がどこまで及ぶか怪しいから、よほど慎重に修正しないとなりません。
プログラマーは”臆病”であってほしいと切に思います。
実際に私も実装担当している時は、お風呂に入っている時とか、ベッドに入って眠りにつくまでとかで、
「今日作ったあの関数・・何か怪しい、明日もう一回調べてみよう」
「昨日出たあの現象の原因・・・・よくわからん・・・・・あっあれだ！」
みたいなことがよくありました。
デバッガーを使っても原因が特定できなくても、いつも気にかけていると（臆病）、何かわかっちゃたりするんですよね。
なので、「臆病なプログラマーが思っている品質に対する自信」って結構信憑性が高いのです。

（次回に続く）