アジャイル開発を完全に理解したチーム

夏休み終盤。我々4人は琉球大学のAgileMiniCampに参加した。

AgileMiniCampとは、アジャイル開発という考え方でソフトウェアをチームで開発する演習講義である。

僕を除いて、三人はAgileMiniCampに初めて参加する。しかも、実質開発時間は5時間と少ない。

だから、僕は「最低限の価値を提供できるソフトウェアを作れる」という確信を持てなかった。

しかし、蓋をあけてみるとびっくり。三人は短い時間でアジャイル開発のキモを抑えられたのだ。ここでいうアジャイル開発のキモは以下の4つである。

• 仕様書や道具よりコミュニケーションを大事にする

• 動くソフトウェアを小さく完成し続けることで、動くソフトウェアに対するフィードバックを貰えるようにする

• ソフトウェアを使うユーザを第一に考え、ユーザからの要求変更を歓迎する

• 計画に従うよりも、チームの状況やユーザからの要求に合わせてやり方などを変える

これらを三人は完璧に抑えて、スムーズな開発を進められた。おかげで最低限の価値を提供できるソフトウェアを完成させることができた。

これを見た僕は「これならインターンでの開発もスムーズにいく」と楽観的に考えるようになった。

この状態を何と言うか。IT関係の人なら分かるだろう。

アジャイル開発、完全に理解した

そして、夏休み明けからチームでインターンに参加し、とあるソフトウェアを開発することになった。

インターンでもスムーズに進む開発に潜む違和感

インターンに参加して最初の1ヶ月間は、MVP（Minimum Viable Product, 必要最低限の機能を備えたプロダクト）を実装する時期だった。

そのためには、「ユーザが抱える課題は何か？」「ユーザが求める最低限で最大の価値を持つ機能は何か？」をまず考えなければならない。

そして、それらを最終決定するのがプロダクトオーナーである。

幸いなことに、チーム内で、ユーザが抱える課題に直面している当事者が存在し、その人がPOとなった。そのため、そのPOにインタビューをすれば、ユーザが求める機能の候補がどんどん出てきた。

あとは、これをPO自らが整理して、MVPを定義すればよい。

しかし、ここでPOは少しつまづいた。なぜなら、欲しい機能がありすぎてどこから手を付ければいいのかを整理できなかったからだ。

そこで、僕は「僕はこの課題を先に解決すべきだから、この機能はMVPに必要な機能じゃない？」と口を出した。

あくまでも、僕は「優先的に解決すべき課題を手かがりに必要な機能を考えられるように助言しよう」というように助け船を出すだけのつもりだった。

ところが、POは僕の意見をそのまま受け入れて、MVPに必要な機能を決定した。本来ならば、POの意見が優先されるべきで僕の意見は却下されてもいいはずなのに。

その状況に対して、僕は「たまたま僕とPOの意見が一致したんだろう」と思い込んだ。

今振り返ってみれば、これが1つ目の違和感だった。

もう一つの違和感は、優秀なメンバーであるFさんの個人プレーである。

チーム開発では実際に実装する前に、各週ごとに実装すべき機能とそのために必要なタスクを話し合う時間を設けている。

なぜなら、チームメンバー全員で実装すべき機能とその理由、タスクを共有していないと、無駄な作業やメンバーで異なる考え方による対立を招きかねないからである。

しかし、Fさんの一人はその話し合いに参加せず、開発環境の整理や実装方法の調査など、個人プレーに走っていた。

僕は、その人の姿勢に違和感を持った。「ちゃんと話し合いの内容を分かっているのかな」と不安になった。

ただ、その人は我々が実装したい機能を早々と実装できるぐらいの実力があった。

それもあって、「あぁ、Fさんは内容を把握しているんだ」という思い込みんだ。

こうしている内に、MVPは実装されていった。

僕、その課題は知らないよ？

開発が始まって1ヶ月ぐらいに事件は起きた。POが次の開発する機能とそれに対応する課題を見て、「僕、その課題は知らないよ？」と言った。

POがプロダクトが解決する課題を知らない。それはチーム開発が根本から崩れる事態である。

なぜなら、「ユーザが抱える課題は何か？」「ユーザが求める最低限で最大の価値を持つ機能は何か？」を最も把握しているべきなのは、POだからである。

そのPOが課題を把握していないというのは、チーム開発の方針が定まらないということになる。

当然、チームは混乱してしまった。

僕、3人の話していることが分からない

これも開発が始まって1ヶ月ぐらいした時に、起きた事件だ。

開発時間内に実装すべき機能を実装できなかった出来事が起きた。この時、Fさんが「僕、3人の話していることが分からない」と言った。

つまり、実装すべき機能を実装できなかった原因は、FさんとPO・その他メンバーの間で意思疎通が出来ていなかったことだ。

もちろん、こうなるとチームは混乱してしまった。

招かざる客のこと「思い込み」

２つの事件が起きた原因を一言で言うならば、「思い込み」である。

POが課題を把握していないこともFさんが3人の話していることを理解できていないことも、自分の思い込みから生まれたものだ。

POが僕の意見をそのまま受け入れたことに対して、僕は「たまたま僕とPOの意見が一致したんだろう」と思い込んだ。

実際は、POが「自身の意見とは違うけど、筆者がそう言うならそれに従おう」と僕の意見を優先したということなのに。

Fさんが個人プレーに走ったことに対して、僕は「あぁ、Fさんは内容を把握しているんだ」と思い込んだ。

実際は、主に手話でコミュニケーションしている3人についていけないから、仕方なく自分ができることをやっていたということなのに。

どれも、僕の勝手な思い込みから起きた問題なのだ。

ネガティブな予測をせず、ポジティブな予測をして動く。僕の良い癖でもあり、悪い癖でもある。今回は悪い方向にいってしまい、チームを混乱させてしまった。

共有を意識し、チームは前に進む

そこから、勝手な思い込みをせず、チームの状況やメンバーの意見や意思疎通の共有を意識し始めた。

POに対しては、POの意見を聞き出してPOの意見が最優先であることを徹底的に確認した。そうすることで、POと開発メンバーで課題を共有して把握することができると考えたからである。

POは、開発メンバーの意見も聞いてくれる素晴らしいPOだ。ゆえに、開発メンバーの意見を優先してしまうところがある。

だから、「POはどう考えているの？」と「我々の意見を採用するかは、POが決めていいよ」という声掛けを何回もやった。

Fさんに対しては、メンバーの話し合いが分かっているかを徹底的に確認した。そうすることで、Fさんが把握できていないことをチームで共有し、再確認を行うことができるからである。

もちろんFさんに限らず、チームメンバー全員で話し合いを把握したかどうかを確認した。

チームメンバー全員で話し合いを把握するために、ホワイトボードに図やフローチャートを書いて目に見える形にするなどの工夫もした。

すると、チーム開発のスピードは向上した。開発スピードが速い時は、3時間の開発で3つの機能を実装できた。

概ね順調に開発を進めることができ、12月下旬にインターンは無事に終了した。

なんと素晴らしいことだろうか！

しかし、更に素晴らしいことがあった。それは、「これ、めっちゃいいプロダクトだから、1月以降も開発続けようよ」とメンバーが提案したことだ。

なぜなら、そのセリフが良いプロダクトと良いチームを作れた証だからだ。プロダクトもチームも良いものになっていなければ、インターンが終わった後も続けたいという気持ちにはならない。

今なら、このセリフが言えると僕は思っている。

アジャイル開発、チョットデキル

･･･いや、それはまだ早いか。

ともかく、本当に「アジャイル開発、チョットデキル」と言える日を迎えられるように頑張るかもしれないということを添えて、この記事を締めくくります。
最後までお読みいただきありがとうございました。

余談

2023年今年の漢字は「躍」です。
色々と活動していて正に躍動していたという個人的見解から今年の漢字を定めました。来年は色々と活動して得た学びを後輩たちや自分に還元したいです。