■

旧体然としたところに今いてる。

いわゆる「SE」がハバを効かせている世の中に多く見られる体制である。
個人的には「プログラマ無くしてシステム開発の成功などない」と思っているので、
営業と要求定義とドキュメント作成以外は口を出すな挟むな管理の真似事もするなといいたい主張を抱えていたりする。

旧体制を考えたときに、
かつては「ロジック考案者」と「Coder」の2種類であった時までさかのぼる必要がある。
この頃、コンピュータシステムにおいて、知識が深く、経験も豊富なのは間違いなく「ロジック考案者」にあった。
当時の「SE」である。
ロジックを紙に書いて考えても、コンパイル速度のほうが遅いから何度でも考えに考え抜いても、
思考の繰り返しに掛かる時間は、コンパイル回数を積み重ねることよりも多くなる事は無かった。
ドキュメントを丁寧に作っても、なんとかなったというよりも、
ドキュメントを綿密に作るほうが開発がスムーズに行ったと思われる時代である。
コードをいじくるよりは、ドキュメントをいじっていたほうが効率的であったのだ。

最近では。
思考の繰り返しに掛かる時間を、コンパイル速度が追い越して久しい。
考え抜くくらいなら、ブレイクポイントを置いて何度でも実行するほうが時間が短く済む時代である。
ドキュメントを作成する１時間という時間でコンパイルは数千、数万回行えるのが現代である。*1
ドキュメントを作るよりはコードをいじくるほうが比べるのもアホらしいほど差がつくように変わったのだ。
ドキュメントなんぞ形骸化して久しい。
必要とされるのは要求定義のメモと、まだまだ未熟なプログラマたちのための指標くらいなもんだ。

ここで整理。
SEとPGという記述を用いるとして、
技術者としてのレベルが「SE ＞ PG」の場合には「SE」が舵を取るほうがよい。
よかった。よい結果を生み出した過去もあるし、現代においてもある程度は効果がある。
システム開発において「PG ＞ SE」となった場合はどうだろう。
それでもある程度の力量をもっているのなら「SE」でよい気もする。
しかし、現実は開発経験のないプロマネだの、
IT業界所属のSEとは名ばかりの人買い商人とかがシステムの基幹を決める場合がある。
技術者がいない場での夢見るシステム創造会。
体制も開発方針もみんなそいつらが決めて遂行される場合がある。

いろんな意味で無駄でしかない。

技術者は不必要に重い負荷を背負い、
マネージャは逃げる算段を余儀なくされ、
プロジェクトは成功には程遠く、闇に包まれていき、
超過費は増え、顧客は怒り、争いは絶えず、疲弊と泥沼ばかりが広がっていく。
こんな状況を誰が望むのだろうか。

この絶対数が増えたとき、常に「SE」が舵を取る必要がどこにあるだろうかと疑問を持ってよいはずだ。
失敗の要因は分析し、解析し、改善の1手を考え出さねば繰り返される。
学ぶべきときに学び、認めたくなくても認めるところは認めて改善せねば
よりよい状況などこない。
改善する気がないやつらをのさばらせておく必要がどこにあるのだろう。いやない。

そーゆーのはえてして己の権益を守る事のみに執着する。
わしにとっちゃたいてい邪魔でしかない。

いろんな思いと、現実を改めて見直して見たときに、
プログラマが仕切ってもよい場面があるはずだ。
開発者をサポートすることにみんなが全力をあげる事が最善の1手である環境があるはずだ。
レベルの低い「SE」だらけで「PG」たる開発者のレベルが高い場合とか。

優れた技術者たるもの、ドキュメント書いてもテストしても設計を行っても何をしても
平均値以上に作業はこなせるもの。
しかしてリソースの無駄遣いでしかないことなど山ほどある。
組織の体制が整っていないときに、体制を作れる力量をもったのがいてるのに、
それをやらずに使いつぶしの作業に割り当てるとか、スゲー無駄。

結論としては。
「レベルの高いのに取らせろ」
コレに尽きる。
リスクを負えないマネージャとか、
目先の作業しか見えないSEとか体制の中枢にはいらない。
それがリスク回避の方法だと思うのだがどうだろう。

*1:最も数万回なんてやれなできるの範疇であって、現実問題そんなにしないだろう。ってかやる必要が無い。