開発プロセスは終わらない
ソフトウェア開発のプロジェクト開始時には「キックオフ」、完了時には「ふり返り」などと称して、プロジェクトとしてのけじめを付けたりすることが有る。開発契約などの実務上の作業は別として、プロジェクトの現場としては一区切りを付ける意味で必要だし悪くないと思う
でも、継続的にソフトウェア開発に関わる立場として言えば、プロジェクト毎に開発対象は異なるにせよ「開発プロセスは終わらない」のが実状だろう。一つの開発作業が終わったら、プラス面として開発メンバーのスキル向上や技術的蓄積の増加などが上げられるし、マイナス面としては積み残し課題や技術的負債が上げられるはずだ。だから、次に行う開発プロジェクトではこの様々な蓄積と負債を共に抱えつつ作業することになり、前回の開発では実施出来なかった上手い対応が出来るはずだし、不可欠のはずだ。
言ってみれば、保守開発とか派生開発で得られた知見は次の開発へフィードバックされる形になるので、結果的に開発プロセスとしては下記のようにグルグルと回る形が自然だろう。開発の実作業が忙しくなると、前回のふり返りで「次回にトライしたいこと」などと上げていたはずの項目はついつい忘れがちになるけれど、実はそのような蓄積を生かすのが本来の姿ではないかとも思う。
- 新規開発を行う。
- 開発が終了し、ソフトをリリースする。
- 保守・派生開発を継続する。
- 1へ戻って別の新規開発を行う。この時、保守・派生開発の結果を生かす。
そんな事をぼんやり考えていたら、下記のような開発形態を取っている会社があると知人から教えてもらった。プロセスがグルグルと回る形態はまさしく思い描いていたものだ。対象として「企業の情報システム」が上げられているけれど、それに限定される必要は無く他でも同様に適用できる考え方だろうし、別の開発案件に変わってもプロセス自体は変わらずに生かせるはずだ。
システム知識を持った上で、業務の相談を求められる…こんな存在になるよう、システム運用保守の仕事に対する認識を変えなければなりません。
システム運用・保守の改善 | 株式会社データ総研
そして、同時にプロセス自体の整備も必要です。
業務のシステム化が一巡した今、システムライフサイクルは、「システム運用保守工程」ありきでスタートすべきです。
そんな訳で、最近流行の「超上流工程」という考え方は新しい要求を掴む意味においては有効かも知れないけれど、実際のところは保守や派生開発といった「超下流工程」の次工程に過ぎず、開発現場で積極的に生かすべきはむしろこのような蓄積された情報や経験、ノウハウではないかと思っている。
「超下流工程」の目的は、この「慣れ」によって隠ぺいされてしまいがちな問題点や課題を見付け出し、来るべきICT再構築の目的・目標設定に反映させることである。
http://www.nikkeibp.co.jp/news/it07q3/542161/
ICT再構築時代の最大の課題は、業務とシステムの問題点・課題を無意識のうちに問題点・課題として認識できない状況に陥ってしまうことではないだろうか。
関連
