どーしたらいいんだろうね
トラックバック「技術的老化というSIerの持病」をいただいたので、いくつか。といっても突っ込みばかりで何の問題提起も解決もできないのであるが。あと、9末のレポート提出を控えて脳味噌が発酵気味。意味不明になるけどご勘弁を。
老化が問題なのではない
正直な所SIerの中にいて思うのは、特にシステム構築という工程がもっとオートメーション化されない限り、絶対変わらない構図だと思う。良い悪いは別にして、システム構築という作業は前近代的でありカタコト機織機を動かしているのとあまり変わらない。
構築(build)という工程はしっかりオートメーション化されていて、そのコストも劇的に安いのがソフトウェアというもの。→名文「ソフトウェア設計とは何か?」を参考にされたし。
id:gothedistanceさんが「カタコト機織機を動かしている」と表現しているのは下記3つのことと思われる。
- その構築工程に渡す設計書(ソース)の作成コスト
- 構築工程からあがってきた「実行可能プログラム」の検証コスト
- 検証の結果発覚した問題の原因を特定・修正するコスト
1で作成する設計書(ソース)がダメなら、2と3のコストは大幅に膨れ上がるのだけど、1の設計書(ソース)を作るための設計(それは概要設計→外部設計→内部設計という一方向な流れらしいのだが)が存在すると思っている時点で「アウト」なわけよ。「俺様はここまでしか見ない。あとはよきにはからえ。以上。」
「ここまでしか見ない」ことを仕事としている人がそれ以上のモノを見るはずがなく、その人にとってはJavaもRubyもStrutsもEJBもRailsも大差はないわけ。たぶん、PCBとかBCGとか3-4文字の略称ならなんでも、「それはいいね」とか言い出すはず。
概要設計→外部設計→内部設計という流れで仕事をしていく思想は老化でもなんでもなく、先祖代々伝わる伝説みたいなもの。その伝説は情報処理試験とかを通じて若手の脳味噌にも刷り込まれていくわけだが。
おやじ問題
で、そういう問題を解決しようとしても動くに動けないのが日本企業。
この老化現象はとめる事も出来ないので何らかの処方箋を考える必要があるんだけど、これをPDCA回すには絶対トップダウンでは不可能だと思う。現場のエンジニアでしか判断できない領域が必ずあって、彼らを巻き込んだうえで議論を重ねていかなければ同質の苦しみを常に生み続けることになる。
トップダウンで動けないというところに日本企業の悲劇があるんじゃないかな。会社における地位が過去の働きに対する恩賞みたいなものだから。ある程度の地位に座る時には、もはや知識が陳腐化している。そして、上にはもっと陳腐化した人達がずらりと(笑。 当然、陳腐化した上司の言う事など素直に聞けるはずがない。
トップに近くなってくると、その辺をよく理解していて、言うことが抽象的になる。変に陳腐化した知識を丸出しにして恥をかくよりは、抽象的なことで煙にまくほうがかっこいいからね。そして抽象的だから、途中階層のおじさんたちは自分に都合の良い解釈ができる。
「本質を理解する」なんてのもこの抽象化の一環でしょ。ぼろださずにカッコをつけられる。便利な言葉なわけよ。
ちなみに自分の知る限りでは、改革的米国企業はトップダウンで動いている。トップにその判断能力があり、トップがそういったら下も当然のごとく従う。
じゃあ、どうしたらいいんだろうね
まあ、こうしてブログで愚痴っても明日が明るくなるわけではない。どーしたらいいんだろうね。
「斧で気にいらないおやじないしはスーツ組を斬りつける」なんてのを考えてみたけど、刑務所行きは楽しくなさそうだ。かといってボトムアップで改善していくというのも時間がかかるし、重箱の隅をつつくような改善で満足しちゃう「若いけどおやじ」みたいなのが入ってくるのがオチ。
んー、つんでますな。(つづく)