開発プロセステーラリングで持つべき視点

今日は萩本さんと、開発プロセスのセッションに出た。

今日は萩本さんの言っていた開発者が「考えるようにしないといけない」という話がとても耳に残ったが、その内容がらみでちょっとした気づきがあったので、メモ代わりにブログに書いておく。

私はアジャイラーなので、お客様の開発プロセスの策定をご支援する場合、「ミニマム思考」でいく。

つまり、体系的で大上段なものを間引いてテーラリングするのではなく、

必要最小限のもの（XPみたいなものを想像して）と本質をまず考えて、プロセスの課題を鑑みて、その現場や、人数や、スキル、文化、制約事項…などを考慮しながら、少なくとも必要なものを「足していく」というアプローチが多い。

　そうすると、その現場での「最適プロセス」ができあがるわけである。

しかし、それではまだ甘い事がわかった。

今日、お客様が自分では、エンジニアリング的にも経験側的にも「不要」と思っていたある場面でのシーケンス図が、お客様曰く「これを書いたおかげで動きが理解できた」という事を仰っておられた。

　つまり、あまりテーラリングもせずXPのようなプロセスを導入できるお客様のスキルレベルはある程度高いはずだが、「開発プロセスを導入しよう」と思っているお客様は、そういうのに慣れていないはずなのだ。例えばオブジェクト指向の開発の開発プロセスを導入したいなら、恐らくお客様の開発メンバの大半は「オブジェクト指向」に慣れていないことが多いだろう。

　上記の「最適プロセス」は現場の状況を考慮すれば確かに理屈では「最適」に見えるが、参加する開発メンバが「学び」が必要であるという場面の方が導入においては多いはずで、大抵の「プロセス導入」では「学び」と「成長」を考慮した成果物やアクティビティを考えないといけないと思った。

　上記の「これを書いたおかげで…」というのでその人は学びを得て、システムのアーキテクチャを理解した状態でコーディングができたわけだが、これも沢山書いていると、私の感覚と同じように「こんなん似たり寄ったりだから書かなくてもいいし、書くのがだるい」という状況がプロジェクトの途中でもやってくるかもしれないし、そうでないかもしれない。そのような「成長」を迎えたら、その中間成果物的な成果物は書く必要が無くなるかも知れない。

　プロジェクトの中でも開発メンバは成長するので、プロセスの途中でも振り返り等でプロセス自身のフィードバックを得ることにより、かなり動的ではあるが、「学び」と「成長」を考慮した「現場で効率のよいプロセス」ができるかも・・・なんて今日は思いました。