■

部屋を片付けようと思ったら、まず何をするのが効率的か。
収納計画を立て、実行可能かどうか検証してみるのがよい。

ってなことをどこかで聞いたか読んだかしたおぼえがうっすらとある。
昨日今日とギリギリになってようやく確定申告の準備をしてたのだが、
これに基づいて作業をしてみた。
大量の領収書という名のカミキレをまとめる掃除のような作業だ。

まず計画。
そして事前準備。
そしてひたすら実行。
疲れる。
そしてまた実行
疲れる。
この繰り返し。

なんだろ。
あれだ。

プログラム作りも掃除の延長線上の作業だな〜とふと思った。
掃除なら、
片付ける場所を選定して、必要な道具そろえて、あとはひたすら実行。
終わったらゴミ袋をまとめてゴミの日にポイ。
プログラミングなら
要件聞いて、実装計画立てて、技術検証して、ひたすらテスト＆コーディング。

実装計画を立てないうちに作り始めたプログラムはつぎはぎだらけの醜いものになるし、
技術検証してない場合には、根本的にロジックが覆ることもあり、パッチが山ほど出来る。
整然として片付かない上に、あれやこれやで迷っている時間は結構かかるもんだ。
掃除で言うとこの、荷物が移動しただけで「片付いちゃいねぇ」って状況になってそうだ。

計画性って大事やね。ヽ(´ー`)ノ

そうおもうと、プログラムにおける言語知識ってのはどんな位置付けになるんだろうと思えてくる。
「計画」に必要なもの？
「実行」に必要なもの？
ん〜
「計画」に必要なのはソフトウェア工学であると思えば、
どちらかといえば「実行」なんじゃないかと思えてくる。*1

計画に従い、実行力をもって作業にあたる。
仕様に従い、言語知識をもってプログラムソースをつくる。

工学という学術的知識だけをもったやつでも、
言語知識を持っているけれども計画がたてれないやつ。
この対比を思った。

実装計画が立てられないままつくられたプログラム。
なし崩し的にコーディングする方が早くできる！
っと思っていた頃はあったけれども。
よくよく振り返れば、計画が立てれなくて、事前に考える行為が出来てなくて、
それでも作業にあたろうとした時の「とりあえず試してみる」っというだけの行動であったと思う。
先の言葉では「技術検証」である。
比較対象が「終われない」か「終われる可能性があるかも」っという2択なのだから、
可能性があるかもしれないほうの行動をとることは間違ってはいない。
が、しかし。
が、しかし。
100回やったら100回望みの結果が返ってくるようなロジックを作ることが使命である者が
一縷の望みに託したロジックでいいはずがない。
なし崩し的に作成が開始されたコーディングはまず良い結果を生まない。
これは経験論であるが、
人的要素を考慮した場合、よくわからない状況に陥ったときに一度立ち止まり、
計画を練り直すことが出来るものと、やれないもの。
成果の質を考えたときに、後者がいいとは思い難い。

こんなことに思い至ったときに、
やっぱり現状、まだまだはびこるウォーターフォールモデル開発における言葉、
「人月(ニンゲツ)」の計算は的を得てないと思え、
ビギナー育成機関も制度も評価体制もない業種はまだまだやりたい放題だな〜とも思え、
さて、じゃ〜どうするか？
っと悩めるのである。

いや、一応こたえは出ているんだ。
端的な言葉でいうと「徒弟制度の復活」
あとはどうやって現状でそれを試すか。
っと、これでまた悩めてしまうのである。

やれやれ。

*1:細かい部分では言語知識も計画に必要な要素ではあるけれども。今回あえて無視。