Scrap and Buildもたいがいに

しろよな　＞自分
・・・と思うんだよね。毎回
(;^ω^)

研究者になればよかった。

凝り性の日本人は、だいたいみんな研究者か職人が向いてる。
なんだかんだ言いながら、自分は相当”日本人”だったんだな。

仕事ならこんなにつき詰めることはない・・・
というか許されない。
少なくとも末端エンジニアの立場では。

場当たり的な対応になるのは、エンジニアが悪いんじゃない。
”体制”がそうなんだから仕方ない。

―　安く早く良いものを　ー

この「システム」が標榜する目標。

「安い」「早い」に議論の必要はないだろうけど
良いプログラムとは？
ここは微妙なところかな。

当然「バグがない」。
それと「性能がいい」ーつまり「軽くて小さい」。

一回きりのシステム開発なら、これだけでいい。

プロジェクトをいくつも受託するシステム開発受託企業だったらどうだろう。

同じような案件を10件請けても利益率も工数も変わらない。

と聞いたら、ちょっと考えてもバカじゃないかと思わないかな。
いやエンジニアがではなく経営者が。

技術資産

「技術資産」を蓄積しないと
毎回ゼロからになる。

どこの会社も技術資産の蓄積という発想がない。
というか、
「うちの会社は人が資産」を地でいってる。

は？

その社員が辞めたり死んだりしたら、資産なくなるよ？

当たり前の話
「技術資産」は”安い”にも”早い”にもそして”良い”にも効果がある。

それがプログラムライブラリや生産管理装置だとかの「モノ」なら
効果は目に見えるものになる。

プロダクトの「クオリティ」はそれら資産の「クオリティ」を高めれば
自ずと高くなる。

技術資産の構築

プロジェクトのエンジニアに片手間にやらせようたって
できるわきゃない。

彼は”自分の”プロジェクトに忙しいんだから。
「資産作り」なんて余計な仕事。
そんな余裕も、ましてやメリットも何もない。
だいたい”自分の資産形成”だって考えてないんだし。

むしろ”やらせよう”と経営者が思ってるなら、いくらかはマシって話。
その”余計な仕事”のための余分な予算が取れるなら
専門部署を作ろう。
別に部署って言っても一人からでも始められる。

具体的な仕事は、プログラムモジュールのライブラリアン。
プロジェクトからオーダーを受けてサプライする。

一人なら、モジュールのDBを作って受身的に管理する。
プロジェクトからモジュールを拾ってタグ付けする作業。
自分で拾うのが大変なら、コンクールをやろう。
共通モジュールとしてエントリして採用されれば、何か特典が付くとか。

余力があれば、モジュールのレギュレーション。
他人のソースを読むことになるから、新人の修行にはいい。

例えば画面なら、リストとフォームをモジュールにすれば8割がたそれで済む。ナビとタブセットとツリーなんかあれば気が利いてる。
DBならRCUD。フレームワークごとのクエリービルダーをエッセンスでラッピングするとどうだろう。
ページングと認証処理もあるといいね。

アップデートのこと

アップデートのことを考えるなら
可読性も「良い」要素になるのかな。

それでもせいぜい
「コーディングルール」みたいなのを用意したり
PMやPLがコードをいちいち読み解いてレギュレーションする程度。
ちょっと目端が効けば、コード整形ツールも使ったり。

バカげてる。
残念ながらそれは生産性の足かせになるだけで、さほど効果はない。

そもそも”肝心の”アルゴリズムやロジックはそれではチェックできない。

モジュールの中を”開けて”いちいちチェックする暇があったら
モジュールテストをちゃんとしろよな。
いや、いちいち人がやるんじゃなくて、完全自動化。
テストコードを書かせるんじゃなくて、それも自動化。

一日の仕事を上がると、裏でボットが動いて容赦なくモジュールをテストする。朝出勤すると、問題点がビジュアルに見れる。
プログラムモジュールは、入力と出力でできてるんだから、自動化できるのが当たり前。
破壊テストまでやれば、バグもかなり減る。

テストについても本当なら専門部署を作るべきなんだよね。
システム開発は製造業。
品質管理をしないでまともな仕事とは言えないだろう。
その専門部署がない会社が果たして信用できるだろうか？