2,3年目の開発者向けに考えてみた。
エンタープライズシステム開発において、各人に作業上問題になっていることを聞くと、必ず出てくる単語が「仕様」であることは間違いない。
PGの視点
- 仕様(設計)が全然決まっていなくて、仕様変更が多い。。。
ウォーターフォールを「ちゃんと」やっているプロジェクトでない限り、仕様は決まらないものである
上のことは、「仕様はきちんと決められるもの」という前提があるから不満に思うことだ。
でも、そもそも仕様の凍結に折衷点を見出したり、変更に対応する基準や工数なんかをマネジメントしてくれるプロジェクトは絶対数として少ない。
(数えてないけど、多ければこんなに失敗プロジェクトが多いはずがない。)
逆転の発想をする
つまり、「仕様はきちんと決められるもの」ではない。「仕様は決まらないもの」と考えて、思考の出発点にしなければならない。
プロセスの問題じゃない
よくここで論点になるのがプロセス(ウォーターフォール vs アジャイル)だけど、それはまだだ。
単にプロセスを変えるだけでプロジェクトが成功するなら、やっぱり世の中のプロジェクトはほとんど成功しているはずだ。
「仕様」という単語を超越する
仕様を誰かが決めてくれるものという考えを捨てる。
仕様は決まらないものであるという考えを出発点にする。
決まらないものであるならば、自分自身が仕様を決めるプロセスに参入していくしかない。
デスマーチから自分自身の身を守るためにも、SEだろうがPGだろうが、仕様を決めるプロセスに参入していく。お客さんとも話す。要件定義もする。
仕様を決める部分で自分の意見を反映できれば、設計やプログラミングにおける作業の障害は少なくなっていく。
2つに1つ
他者に決めてもらって自分が作業する限り、冒頭の不満は永久になくならない。
ある種押し付けられる部分があるので、勤務時間は長くなるかもしれない。そういう部分のコントロールも他者に依存することになる。
ただし、責任範囲は明確であり、学習の必要性は低い。
もう1つは、決定プロセスに参入していくため、冒頭の不満は少しは少なくなる。
責任範囲が広範囲におよぶため、学習の必要性は高い。
自分の作業を自分で定義できるところにおもしろみもある。
僕の場合
僕自身、設計や製造と同時にプロジェクトに対して助言するという立場を得られるときがあって、そのときは「仕様の決定」に対する不満は少ない。
こういう2つに1つしかないんじゃないか。
エンタープライズシステムの開発においては。
仕様の不満をなくすには、今の自分を超越して決定プロセスに参入していくしかない。
参入できるように力をつけていくしかない。
何と何をやればいい、という王道はない。僕もわからない。
ただ、言えるのは「時間とお金を自己投資する」だけは必須であるということ。
不満に思うだけでは何も解決しないということ。
インプットとアウトプット
学ぶとはインプットして、アウトプットすること。
インプットは本かもしれないし、資格かもしれないし、blogやWebサイトかもしれないし、先輩や上司の話かもしれない。
学んだことをアウトプットする。アウトプットは必ず誰かの目に触れるところにする。
逆に先輩や上司に話してみることかもしれないし、blogに書いてみることかもしれないし、会社の掲示板のようなインフラに書いてみることかもしれないし、自分で学んだことをWebの記事や本にしてしまうことかもしれない。
誰かの目に触れることで、次への指針が見える。
