■
開発プロセスの標準化
>>「〜がダメだから、○○はダメ」みたいな思考停止こそ一番おそれるべきものではないでしょうか？<<
この部分お気に入り( ´∀｀)
足を止める理由など大した知識がなくてもできる。批判野郎は楽なのだ。
それをしたくないから試行錯誤を繰り返す。
その経験は次に必ず生きてくる。失敗の経験は結構効率の良い経験値稼ぎであったりするからだ。
さて本題。
高レベルな技術者による俗人的な開発プロセスの中にはうまくいっているものがある。
っということは、うまくいく理由がそこに必ず存在していることになる。
これを解析して、一般的な話に展開できればそれが「標準化」になるんでないかな〜と思う。
思える。思おう。思えるといいな。
開発プロセスを持っている技術者に張り付き、
手順を逐一メモして、判断基準となる事柄を羅列する。
何がどうだからコレはいい、わるい。
今どういう状況が出てきたからあれをやろう、これをやろう。などなど。
この気の遠くなるような手間隙をかけて取得したメモを元に、
高レベル技術者のロジックを丸裸にするのを繰り返した後にでも、
集計作業を行えば何かしらの共通点はみつかると思えるしねぇ。( ´∀｀)
仮説をたてたあとは現実が伴うかどうかを考慮すればいい。
考慮した結果、専門の調査機関があり、予算がつかんと現状ではむりっぽい。
しかして、標準化に繋がる道はちいさな可能性はここに残ったのだ。
あとはだれがやるか〜だ。
もっと効率の良い方法はいつでも模索したいものだが。
余談
標準化した結果、猫も杓子も標準化をなぞって成功できるようなもんではない可能性はありそうな気もする。
なぜならソフトウェア開発は間違いなく専門職であり、
専門知識が必要であり、
実戦によって得られる経験は役に立つものであることを思うと、
知識が乏しく、経験も無いのが標準化プロセスをなぞれるか？という疑問が湧くからだ。
この疑問に経験則で立ち向かうと「間違いなくなぞれない。」っと、結論が出るのだが。
さて。どうしたもんだか。
■
おお。同じよなことを考えていたひとがいたφ(．．)
ブログでプロジェクトマネジメントする10の方法
