改善型開発(^-^)
id:kuranukiさんのページで
という主張があることを以前、知り合いから聞いていた。聞いた瞬間、アハ！現象が起きた気がする。行っていることを単にまとめると、「繰り返し型開発を保守と呼んでしまおう。」ということになるような気がする。しかし、開発者たちが目指す未来への道筋は従来の「完成」を目標にするところとは大きく異なっている。小さな完成はあるとしても、その先はSIerの未来であり、かつ顧客のビジネスである。
自分は顧客の未来だけを見つめることが、SIerの未来を知らないうちに切り開くだろう、程度しか考えていなかったが、それでは周りを説得できない。SIerのビジネスモデルを展開するためには自分たちの利益が明確化されていなければいけないという発想から、SIerの未来を悲観しながらも、受身から戦略的発想への転換を進め、SIerの未来を切り開いていこうという主張が感じられる。
先日、同僚の若手が退職したが、退職理由がSIerの未来を悲観し、コンサルティングファームにてIT開発のあるべき姿を実践していくとのことであった。コンサルティングファームはよく知らないのだが、どうやら自分たちでシステム開発を顧客の立場で行い、成功したときにのみ報酬が発生するようだ。つまりシステム化をしても顧客や自分たち(開発者も顧客と同様の立場のため)が満足できる結果が残せなければ、報酬を得られないという厳しい状況でのシステム化をしていくことらしい。要求開発という考えでより顧客の立場に立って物事が考えられるかもしれないが、コンサルティングファームとは始まり(顧客から対価をもらってからはじまるかどうか）が違うため、同じ土俵にすらあがっていない、とも言われた。
じゃあ、やっぱりSIerに未来はないのだろうか。
確かにこのままではあまりうれしい未来はない、というか今までもあまりうれしい状況ではなかった気がする。なので、まずは足元から固めていきたい。そのときに、改善型開発は割合簡単に採用できるはずだ。
改善型開発のキモは発想の転換であり、SIerのあるべき姿からSIerの未来への警鐘からの具体案であるが、行うこと自体は繰り返し型開発でスモールリリースを続けるという、従来からいわれていた手法を実践するだけだ。しかし、そこに意識の転換をもとめ、開発ではなく、行うことの大半は保守であり、システムを育て続けていくという考えをもって開発に当たろうというだけである。
自分の周りでは繰り返し型開発を行っても成功している例は割と少ない。以前、雑誌にも書いたが特に
- 受け入れテストを行わない繰り返し型開発
を防ぐことができるだろう。(実はこのケースは結構経験しており、いくらマネージャに進言しても、受け入れてストを繰り返し単位で行うことはできなかった。ひどいところだと、サブシステム間の結合テストすらされず、コンポーネントテスト程度で繰り返し終了としているところもあった。)
受け入れてストを行ってもらうには、顧客も参加しなければいけない。これを保守といえば、顧客も参加し、積極的にテストをしてくれる。これは本当にリリースしてしまうのでやらざるを得ないのだ。従来の繰り返し型では最後にまとめてリリースすることも多かったので、いくらUPで「リリースレベルまで高める」といっても、現実にはそのような状況にするのは難しかったのだ。ここに発想の転換で保守としてしまうと、繰り返し単位でリリースするので、かならず受け入れてストをすることになるのだ。
自分の経験からも、なぜか保守のプロジェクトは成功するが、新規開発はたいそう苦労することが多かった。以前、漠然と「保守を続けていけばいいのに。でも、サービスのリリースがその単位でないから無理なんだ。」と感じていたが、ここを工夫次第で何とかすればよいのだ。たとえば、一部機能だけではリリースできない、という場合でも、ソースコードはその機能だけを実現し、リリースしてしまうのだ。単にその機能を使うことができないように、入り口だけサービスを提供しない状態にしておけばよいのだ。修正したソースをリリースしてしまう、こんな緊張感が保守であり、安全を求めるために、開発単位を適切にし、入念なテストを行う必要性が誰にでも理解でき、実践できるのだろう。
改善型開発、これはすばらしい。メリットはまだまだある。今度、改善型開発のメリットをまとめてみよう。
