The Dragon Scroll

Be just and fear not.

やり方を改善する。

極力、お客様やパートナさんのところに乗り込むことにしている。
現場の雰囲気が好きというのもありますが、やはり、最前線で
得られる情報量と質が違うというのが、その理由。
そこでは、表情を見ることができる


例えば、週一回程度の進捗会議で、数字を追うことに注力するよりも
現場に出て、現場の人が語る言葉を聞きたいと思う
(勿論、マネージャからの進捗報告は、それはそれで必要)。
そこには、最前線の生の、事実がある。


かつて、とあるプロジェクトで、こんなことがあった。
ふろ同じ開発者の顔を見ると、殆どの人が、疲れきっているのがわかる。
机の上には、栄養ドリンクが並ぶ。
リーダは既に徹夜明けで蒼白となっている。
若い私は戦慄の思いだった。
なんとか、この場を切り抜けたい。
自分のダメージは少なくして。そんな思いに駆られていた。


そんな状況は、今現在も変わっていないのではないだろうか。


短納期案件だろうが、仕様が決まらない案件だろうが、
大抵のSIerは、他の方法論が使いこなせないから、どんなタイプの
案件でもウォーターフォールに押し込めることになる。
それは、マネジメント層だけでなく、エンジニア層の問題でもある。


我々はいつまで、こんな開発をするつもりなんだ?


とにかく作れば良いんでしょ?では焼畑農業みたいなものではないか。
何故、SIerは手がける案件を高確率でデスマにしてしまうのか。
そのツケを顧客や、パートナ、現場エンジニアに払わせるようなことが
あってはならない。


過去の政治的な事情を今、持ち込むのはやめよう。
相手と自分の間に線を引くことに熱をあげるのを止めよう。
顧客にいいわけするのを止めよう。
価値を生み出すことに集中しよう。


ここで間違ってはいけないのが、プロジェクトの目的だ。
我々は、デスマにならないようにするためにプロジェクトを
運営しているのではない。
お客様が投資をして、その対価として得る、新しい価値を
生み出すシステムを提供するためにプロジェクトはある。
そのことを考えたときに、プロジェクトはデスマになって
いるはずがない。
デスマでは、そんなシステムを提供することはできないからだ。
納期の面でも、品質の面でも、コストの面でも。


では、プロジェクトをどのように運営すればよいのか?
その方法論とは何なのか?
それを考えることが、今の私の宿題。
大それたことは言えない。少しでも、プロセスを改善する方向を
考えたいと思う。
どんな小さなことでも良い、考え、実践していきたい。
昨日よりも、今日。
今日よりも、明日。