■
実装を知るというのはツメがきっちり出来るかどうかにかかってくる。
ウォーターフォール的に言えば設計時に製造のコストを下げる共通化が効果的に行えるかどうかにかかってくる。
烏合の衆が集まってもダメね。
できやしねぇ。
効果がどのくらい見込めるという話はできるやつは出来るのだが、
開発作業を「製造」とひとくくりに捉えて、「設計書どおりに動いたらいい」なんて夢物語を信じている人々には
実装時のクラス構成や設計や効果的なテストやデバッグしやすい形式など、
少しずつ地道に工数削る行為の成果とそれをベースに次に打てる手などは想像もできやしない。
その他大勢に「動けばいい」で作成依頼をかけたなら、それは大方正常系だけ動くかなって代物が帰ってくる。
後のメンテナンス性など絶望的なのだ。
稀に綺麗なソースコードにであるのだが、物量の前にはやはりかなわない。
なんでこいつにソースの取りまとめさせなかったんだって、物量を目の当たりにしたものならわかるはずだ。
ゆえに。
今。
それを考慮し、その他大勢が「製造」ってゆー無茶を行う前に、出来るだけ閾値を下げておきたい。
下げるために手立てを打てるのはその時々のメンツの力量と経験による。
裏を返せばそれらがそろわなければ手は打てない。*1
でも世の中「共通化」と「コストダウン」の単語は好まれるので、ウォーターフォールの中でも行われる。
けどね。
集められる人員と、割り当てられる期間ってたいがいあれじゃない。
ないじゃない。っつか余分がいたりするじゃない。
目的を達するためのリソースは障害ごと割り当てられるという事態。
目的を達するためになにしてもいいかというとそんなことはなくて、
障害となる人員にも成果をださせてみせろってゆー無理難題ごとやってくる。
目的を達したいのか邪魔したいのかよく理解できないポイントがそこにある。
そこで思った。
力量と経験はその人が何をしてきたかってのを知るのが手っ取り早い。
手っ取り早いのは業務経歴書をみることなのだが、現場では行われない。
今だれかが面接をし、業務に適していると判断された結果目の前にいる人物が、
何が得意で何が未経験なのか知る術がない。*2
このへん明らかになればもちこっと効率化はかれるんでないかなーっと。
簡易スキルシートってなもんじゃないけれど、
やはり誰が何をできるかってのはわかったほうが効率的だ。
そのためにレベル差を明確にすることはひとつの手じゃないかな。
それを差別と呼ぶか区別と呼ぶか、必要な措置と呼ぶかはひとそれぞれだが、
自分は必要な区別だと認識している。
だってそのために毎度毎度不具合や不都合があって、結果「できません」ってことのほうが多いのだから。
