本研究所では、アジャイル開発を素材に、より良いシステム開発のあり方を求めていきます。モデリングや設計などを学ぶことは大切ですが、開発手法そのものを見直すことは、より良いシステムを作るだけではなく、開発を担当するチームが成長し、個人の満足度も高まると考えられます。第6回は、開発者の陥りやすい状況や、それを改善するときに「注意しなければいけない」と気付いたことを紹介します。

 開発者としては、「発注者のために良いシステムを作りたい」と思うのは自然なことです。でも世の中には“良い”とは呼べないシステムが存在していることも確かです。現在の開発手法では「顧客を満足させたい」という思いが、ときには顧客に与える効果としては裏目に出てしまうことがあるような気がします。開発者として、「良いシステムを作る」ということをどのようにとらえるべきなのでしょうか。

繰り返す仕様変更のなかで“ヒヤっ”とした瞬間

 私はかつて、「良いシステムを作る」ということは、「発注者の要望に応えること」だと思っていました。しかし、大学時代の経験から、この“応える”という言葉に危険性を感じています。

 大学時代の私は、2年生のときから、あるサッカー大会の大会運営支援システムの開発に携わっていました。顧客によるレビューを数回に渡って受けながら、システムの仕様を変更するという流れで開発してきました。

 この「レビュー → 仕様変更」という作業を何度か続けていくと、仕様変更に抵抗を感じなくなります。次第に、顧客からの修正依頼がくれば、「修正対応をして当然だ」という考え方になっていきます。このような考え方が広まってくると、その修正依頼が対応すべき要求かどうかを冷静に判断することが少なくなり、ほとんどの要求を鵜呑みにするようになりました。

 要求に応え続けた結果として、開発が大幅に遅れたり、自分たちへの大きな負荷となってのしかかってきたりします。問題が大きくなり限界に近付くことでやっと、「なにも考えずに突っ走っていた」ということに気がつくのです。このときに「ヤバイ!」と思い、ヒヤっとしたことは今でも忘れられません。

アジャイルは“自己監視”のためにある

 学生ならではの経験かもしれませんが、このような経験が、みなさんにもないでしょうか。開発中は周りが見えなくなりがちです。周りというよりは自分たちの状況を冷静に見られないとも言えます。

 こうした「レビュー → 仕様変更・修正」という流れは、一見すると繰り返し開発のようでし、アジャイルのようにも見えます。しかし、今の私は「これは全くアジャイルではない」と言い切れます。その理由は、今、行っている作業が良いことか悪いことかを自分自身で判断できていない」ことです。今思えば当然ですが、当時は「ヒヤっ!」とするまで悪いことだとさえ思ってもいませんでした。

 私がアジャイルを経験してからよく感じるのは、「アジャイルは自分で自分を監視する仕組みである」ということです。「監視」という言葉は少しキツイ感じがしてしまうかもしれませんが、自分を冷静に見ているという点では合っていると思います。

 アジャイルでは、進捗や開発の障害だけでなく、開発者の気持ち (モチベーション)など様々なものを見える化していきます。それはつまり、「自分(チーム)を律するためのもの」であるとも考えられます。

 ここでの見える化は、マネジャーや顧客のためのものではなく、チームのためのものです。チームが顧客と対話しながら自分たちの成果が顧客の満足に向かっていることを、客観的に把握しながら進むための仕組みなのです。例えば、顧客やマネジャーには“動くシステム”を定期的に提供することで、顧客が求めるシステムを提供できているかどうかを判断しながら、プロジェクトを進められます。