アラタナエンジニアブログ

aratana Engineer's Blog

ここが大事だよアジャイルプロセスを"実際の経験"から語ります!

この記事はaratana Advent Calendar 2017 - Qiita 6日目の記事です。

f:id:kimesawa:20171130110645g:plain
aratana advent calendar 2017


こんばんは。夜の芋焼酎。お湯割りで♡先にお湯を入れて、後から焼酎を入れるんやで。きめさわです。

突然ですが、アジャイル開発してますか?

弊社では、絶賛アジャイル開発実践中でありますが、やはり一筋縄には行かないところがありました。

うまく出来ていることもありますが、ことうまくいっていないところが強調されてくるとアジャイル開発をしていても、雰囲気も悪くなるものです。

もちろん、イテレーションによる振り返り(レトロプロスペクティブ)により、改善できることも多いのですが、そもそも最初からやり方を失敗していたところもあり、こうした大きな振り返り(年末ですしね)ができるタイミングで、次どうしたらよいかを考えることは大変重要だということで記事にしてみました。

そもそもなぜアジャイル開発にこだわるのか

僕達にはとてもうまく行ったウォーターフォール開発の経験がありました。
それにも関わらずアジャイル開発に舵を切ったのには多くの理由があります。

これまで採用していた「ウォーターフォール」ですが、「ウォーターフォール」自体は「アジャイルプロセス」の対義語ではなくて、対義語は厳密には「計画駆動プロセス」です。(ウォーターフォールは計画駆動の一形態です)

それは、ユーザーが求める機能をあらかじめ計画していく方法です。
もちろん、あらかじめ全てを計画でき、変更がなければうまくいきますが、そうはいかないのが、現実。

一方、アジャイルでは、「計測」を用いて、未来を「計算」していきます。
プロジェクトに対する変更と不確実性をうまく取り込みながら、短いスパンでその成果を計測し、つくるべき機能を常に調整しながら不確実性を徐々に減らしていく。
そのやり方が、プロジェクトにぴったり合っていました。

また、アラタナでは、フレックスタイムが導入され、残業を減らしていこうという取り組みがありました。

プロジェクトの性格と、これからのアラタナの取り組みを含め、この「アジャイルプロセス」がぴったりハマると思っていました。

アジャイルに向くプロジェクト・向かないプロジェクト

そのような比較をすると、なんとなく、全てのプロジェクトにアジャイルプロセスが合いそうな気もしてきます。
変更がないプロジェクト・全てが予測できるプロジェクトなど程度の差はあれ、ありえないからです。

しかし、アジャイルに向く、向かないというのはプロジェクトの性格ではなく、プロジェクトの状態によって変化することを最近知りました。

エッセンシャルスクラムで紹介されている「クネビンフレームワーク」は、プロジェクトの状態によってアジャイルに向く、向かないがあることを整理して伝えてくれています。

クネビンフレームワークによるプロジェクトの状態の区分(領域)は以下の通りです

1. 単純な領域・・・単純な問題を扱うプロジェクト。
たとえば、既存プロダクトを顧客の環境にデプロイするのがこれで100回目という状態。
こんなプロジェクトでは、アジャイルより手順を整理して実行する方がよい。


2. 込み入った領域・・・日々の保守作業。サポートや不具合対応など。
アジャイルが対応できないわけではないが、ここは、専門家が戦術的・定量的なアプローチをすることによって活躍する領域。


3. カオスな領域・・・危機的状況。秩序を回復するために何らかの対応が必要になる。
こんなときに次のイテレーションで何をやるのか判断するような状況ではない。


4. 複雑な領域・・・複雑な問題を扱っている状況。予期できず、学習・検査・適応を行う必要がある状況。
実験が必要で交流と会話が大事な世界。ここがアジャイルが一番適している状況。

5. 無秩序・・・上記の状況に当てはまらない時には、それは無秩序の状況。
置かれている状況をどう理解すればよいのかわからない。
そんなとき、人は自らの個人的な好みに基いて状況を解釈して行動する傾向にある。
ソフトウェア開発においては、それは「計画駆動プロセス」を選択する人が多い。それは慣れているからだ。
ただ、この選択はソフトウェア開発においてはほとんどうまくいかない。
まずは無秩序からの脱出を図る。
状況を構成要素に分解して、それぞれを4つの領域に当てはめる。
もちろんこの状況でアジャイルを適用してはいけなくて、まずはなにより脱出を図るべき。


現在のプロジェクトの状況はまだまだ4(複雑な領域)と思いたいけど、3(カオスな領域)か5(無秩序)になりつつあるかもしれません。
そういう状況に移行して、こうしておけば良かったと思うことが出てくるわけですが、しっかり振り返り、次のTryを作ることが大事ですね。

この記事ではアジャイルプロセスの実践面から大きく振り返ってみて、次はこうしたいっ!!というところを挙げて行けたらと思います。

とはいえ、アジャイルプロセスをやって良かったと思えるところももちろん沢山あります。むしろ良かったことのほうが多いです。
アジャイルプロセス自体がダメだったのではなく、アジャイルプロセスのやり方を一部誤った。。。というより一部端折ったところに問題があるのです。

そこで、まずは、やって良かったところを先に挙げておきましょう。

ここが良かったアジャイルプロジェクト

1. 計測による進行は思っていたよりも正確


イテレーションごとに計測していったベロシティは思ったいたより正確だっと思います。
何が正確かといえば、その計測の内容(計測なので当然)と、このまま割込や追加がなければ、今上がっているものはいつ終わるかが徐々に見えてきたということ。

もちろん、追加があればそれを含めて計算し、常に時期が見えるようになっていきました。
バーンダウンチャートいいですね。

2. ユーザーストーリーマッピング

ユーザーストーリーマッピングでストーリーを洗い出しました。
何も決まっていない状況のなか、このやり方はとてもマッチしていたように思います。
長い時間メンバー全員が一つの部屋に閉じこもり延々と洗い出していくのはある意味苦痛でしたが、その分の成果は大きかったです。

3. 自己組織化

今回、色々な技術を新たに採用し、実験を繰り返しながらかつ目まぐるしく変化する状況に対し、イテレーションをこなして進めてきました。
また、イテレーション内では、誰が何をやるのかは上司ではなくチームが決めます。

そして何より、振り返り(レトロスペクティブ)により、色々改善されていきました。
モブプログラミングを採用したり、朝の共有も(やってなかったんかい!と言われそうですが)振り返りにより始めました。
飲み会や社内共有会なんかも振り返りから実行されたものです。

こうした活動から、チームが自信を持ち、進めていけたと思います。

4. ドメイン駆動設計とぴったり合う

今回導入したものの一つにドメイン駆動設計がありました。

ここでその詳細な説明は省きますが、簡単に言えば、複雑なビジネスの問題領域を整理し、言語化し、それを実装に落とし込んでいく手法です。
最初からこういった複雑な問題を整理することは不可能で、多くの会話と実験が必要になる設計手法です。その分、整理され、実装されたコードは理解しやすく、変更にも強いものになっていきます。

これは、クネビンフレームワークの「複雑な領域」の説明ともぴったり合いますし、イコールアジャイルプロセスにぴったりの設計手法であるということです。

まだまだ、良かった点はあると思うのですが、このあたりで、失敗したところを挙げて行きます。これらは全て今思えば!というものです。
最初からそうしておけば良かったでしょと言えるものばかりかもしれませんが、後から気がつくことがやっぱり多いわけです。

ここが大事だよ、アジャイルプロジェクト

プロダクトオーナー不在または、プロダクトオーナーがいっぱいはだめ!

ここを曖昧にしたままスタートしてしまいました。当然ステークスホルダーはいっぱいいて、それぞれから色々な話しをきいてストーリーに落とし込んでいってはいたのですが、それをまとめ上げて、製品に責任を持つ人を決めないまま来てしまいました。
この状況はプロダクトオーナーが不在な状況。またはステークスホルダーがみんなプロダクトオーナー的存在になるような状況です。

当初はそれでもストーリーが上がっているし大丈夫と思っていたのですが、大事なのはそこではありませんでした。

プロダクトオーナー不在になると陥る状況というのは以下のようなことです。

割込作業が増える・・・プロダクトバックログを実質管理する人がいない状況で、プロジェクト自体の状況は常に変化します。そんなとき起こるのは、急な打ち合わせや急な資料作成などの作業。割込が増えると完全にイテレーションの計測に影響します。
それでも割込が少なければある程度コントロールできるのかもしれませんが、そのコントロールはプロダクトオーナーが決定しなければまとまらないものです。

優先順位・決める人が不在・・・プロダクトオーナーが不在なので、開発チームが優先順位を状況に応じて入れ替えていきました。当初はこれで良かったのですが、プロジェクトが進めば非常に判断に迷う状況がでてきます。

それはステークホルダーが増えたり、あちらを立てればこちらが立たず的な状況が起こったりすることで発生します。

つまりそこで決める人が必要になるのですが、特に作っている製品の現状だけでなく、製品の未来を予測でき、それに基いて決められる人=プロダクトオーナーの存在が欠かせなくなってきます。
作っている当人、開発チームと、ステークスホルダーが多く存在する状況ではこの決断は(どんなに当事者意識があろうとも)難しいことです。

ステークスホルダーをまとめる人が不在・・・当初は予測してなかったステークスホルダーが増えることも現実には起こります。そんなとき、プロジェクトの状況は変わります。

そのステークスホルダーが必要なものが、他のステークスホルダーが欲しかったものに影響がでるのはよくあることです。そんなとき起こるのは、一斉に各所から変更の希望や不明点が発生するということ。

そんなとき、プロダクトオーナーの存在が重要になってきます。ステークスホルダーが全員プロダクトオーナーになってはいけないのはこういうことです。

完了の定義 / ストーリの分割

イテレーションごとに完了の定義がなかったわけではなく、単体テストが通り、e2eで動作ができればよしとしていましたが、もっと厳密にやれば良かったかなというのが今の理解です。

動作させるというだけでなく、今ここでこれはイテレーションに入り切らないから、それは、ストーリーを分割してそっちの完了の定義に書いておこうとか、セキュリティ面の完了の定義とか、資料の作成もここに含まれると思いますし、e2eの自動テストもこの定義に含まれるべきだったかもしれません。

細かくしないことで、ストーリが次のイテレーションまでかかってしまったり(分割できないため)、動作するものが「今」見せられなかったり、資料を作るだけのタスクが残ってしまったりしました。

また、完了の定義を細かくすることで、もっと厳密に計測ができ、この機能が(もちろん変化がなければ)いつ終わるのかもっと具体的に提示することが出来たかもしれません。

インセプションデッキの意味

あとから期間が固定に変更されたとき、最低限の機能が固まった時、思わぬステークホルダーが増えた時、それによって、製品の行き先に迷いが出た時、開発メンバーが増えたとき、ビジネスの背景が変わった時。。。

これらは全て実際に起こったことです。

そんなとき、立ち止まってもう一度、振り返る、そして変化させ、それに追随することができる。こういうことがインセプションデッキの役割であるわけです。
インセプションデッキは作って終わりではないということ。必ず必要なものでした。

マイルストン・ロードマップはやっぱり必要

マイルストンやロードマップはアジャイルでは作らないと言ってはいないんですよね。

いつ、どんな固定イベントがあって、それまでに必要なもの、間に合わない場合にどう調整するかも含めてマイルストンやロードマップは必要なものでした。
実際それもインセプションデッキに含まれるものですね。

それぞれのプラクティスには意味がある。

こんな感じで大きく振り返ってみましたが、一番実感しているのは、多くのアジャイルのプラクティスがあるけれど、それぞれ必要で意味のあるものだったということ。

特にスクラムなんかは厳密に役割ややることが決められていて、アジャイルなのに窮屈なプロセスだと思っていたのですが、やはりそれぞれに意味があってそれが欠けると何かが起こるようになっているのだと思いました。

もちろん、意味を理解することなく使うことはやはり失敗する要因ではあるけど、大事なのはそれを「使わない」ことで何がおこるかを考えておくことでした。

あとは、失敗できること。実験・試して失敗できる環境であること。これは最近のモダンアジャイルに沿った考え方でもあります。
(詳しくはエンジニアブログのこの記事(http://lab.aratana.jp/entry/2017/08/08/151414)をどうぞ)
そして、この失敗を活かせる環境であることが何より大事です。

アラタナはそれができる環境なのがいいところですね。
そういう環境だからこそ、アジャイルを採用し、一部失敗したところもありますが、それを活かしてさらに改善でき、何より、よりよいプロダクトを作っていくことができるのだと思います。

最後に一つ付け加えるならば、「スクラムマスター」を雇うことって選択肢の一つにあってもよいと思いました。
特に失敗できる容量が少ないプロジェクトはそうかもしれません。
それほど、アジャイルのプラクティスは難しい側面があるし、やってみて初めてわかる価値、やらなかったことで気がつく価値がとても多いのです。

明日は、7日目新卒川原パイセンによる「GoogleAppsScriptの高速化のためAPIの数を減らす」です。いい記事を期待してます!