ウルトラアジャイル開発を実現するための10のこと

こんばんは。高石です。

ウルトラアジャイル開発と題して推進している超スピード重視の開発。
その中でも当社が超スピード開発を実現するために意識している10つのポリシーについてお話ししたいと思います。

1.動くもので語ろう。

まず一番重要視しているポリシーは、すべて動くもので議論するということ。
実際に稼働するものを持って顧客との要件調整を行うようにしています。
「稼働志向(オリエンテッド)」です。
言葉やペーパーだけで議論しても、やりたいことはなかなか出にくいものです。
スーパーマーケットに行って、聞いたこともない野菜を、身振り手振りで説明して探すようなものです。
本来欲しい野菜にたどり着ける可能性はとても低いです。
いち早く実際に「動くもの」、「見えるもの」を作成し、それを元に議論を進めています。

要求事項が出てこないからといって顧客を責めるのはナンセンスです。
それは、自分達が「動くもの」、「見えるもの」を見せきれず、顧客が要求事項をイメージできなかったことが原因である可能性が高いです。

2.ビジュアル化して語ろう。

動くものができるまでは要求事項は出にくいものです。
でも、動くものができるまでの間に顧客と認識を合わせておかなければいけないことはたくさんあります。
たとえば、見積もりのためのシステムモデルや機能概要など。
アジャイルだからといって「工数を決めて、その範囲でできるところまでやります！」では、最終的に動くサービスが完成するかもわからないので、顧客もエンジニアもアンハッピーです。
もしかしたら動かない状態で、工数オーバとなってしまう可能性だってあります。
そのな状態は避けなければいけません。

動くものができるまでの間は、ホワイトボードやペーパーにサービスのモデルをフリーハンドで記載して言葉だけではなくビジュアルで示して認識を合わせるようにしています。

設計時のチーム内認識合わせも同様です。
言葉だけの議論では認識あっているかどうかわかりません。必ずビジュアル化して整理をするようにしています。
みんな怖がらずにホワイトボードの前に立つように心がけています。

3.要求事項の決め方を決めよう。

アジャイルだからと言って、すべてを柔軟に変更可能としてたら破綻してしまいます。
要求事項をすべて取り込んでも結果的にスケジュールに間に合わなければ本末転倒です。

そんな時は要求事項を事前に決めるのではなく、要求事項の決め方(実装優先順位の決め方)を決めるようにしています。

例えば、エンドユーザに見える部分の要求事項は優先的に取り込もうとか、メインフローの変更を優先して取り込もうとか。
要求事項の決め方を顧客と合わせておけば必然的に同じ目標に向かって進むことができるようになります。

4.スケジュールを決めよう。

これもよく誤解されがちですが、アジャイルだからといってスケジュールを作らなくてよいというわけではありません。
各タスクのスケジュール(完了目安)は、顧客への確認タイミングを提示する目的の他に、エンジニアのモチベーションをコントロールも役に立ちます。期限がないと人間はだらけてしまうものです。
スケジュールがないと一生そのタスクは終わらない、というくらいに思っています。

必ず、すべてのタスクにスケジュール(完了目安)を設けるようにしています。

5.ドキュメント思考しよう。でもドキュメントはなるべく作らないようにしょう。

設計時はドキュメントをイメージして思考するようにしています。
アジャイルだから設計しなくてよいということはありません。実装すべき処理パターンをドキュメントに書くときと同様に一定の軸を決めたマトリックスで整理(設計)する必要はあります。
ただし、それをドキュメントに起こす必要はありません。
内部認識合わせ用であれば、一時的なスプレッドシート(Excelなど)の資料で作ってもよいですし、ホワイトボードで共有し、写真にとって保管する方法でも構いません。
必要なもの、キモとなる部分だけ見える化して整理しています。
ドキュメントが成果物であるとか、ドキュメントは万人にわからなければいけないという神話は忘れてしまいました。

あとは顧客との仕様認識合わせなどは、その顧客のレベル(気になるポイント)に合わせて、最低限の説明ドキュメントをつくるようにだけしています。

6.進捗阻害要因の徹底的な排除しよう。

マネージャは進捗阻害要因をいち早く見つけそれを徹底的に排除することを心がけています。
判断基準は進捗を阻害するか否かです。
進捗を阻害しないような課題はなるべくメンバの裁量で進めるようにしています。

また近い将来、進捗阻害要因になるであろうリスクにも気を配り、リスクが顕在化しないよう徹底的にケアする必要があります。

7.顧客にもアジャイルな運用をしてもらおう。

アジャイル開発はエンジニアだけでは成り立ちません。
顧客から適切なフィードバックを受けて、検討、取り込みを繰り返すプロセスを生み出すことが重要です。
顧客から適切なフィードバックを受けられるような情報提供と、進捗の見える化を実施しています。
「1.」で記載したように「稼働オリエンテッド」で見える化を実現し、運用とフィードバックのサイクルを効率良くまわせるようにしています。

8.効率化フレームワークやツール活用しよう。

効率的なフレームワークやツールを積極的に採用しています。
ここは未だ探り段階ですが、効率化のためのツールを日々模索しています。
日々、世の中では新しいフレームワークやツールが生まれてはブラッシュアップされているので、それを使わない手はありません。
例えばスマホアプリを開発する上では、マルチOSを1つのコードだけで実現する、ハイブリッド開発フレームワークはアジャイルでサービスを実現したい場合にはとても有用です。(いまだ評価中ですが。)

9.自動化できるものは自動化しよう。

リリースやデプロイ、ユニットテストなどは、アジャイルでイテレーション開発をする際は何度も反復します。
これをすべて手動でやるのはナンセンスです。
人間がやる必要のない作業はすべて自動化して、時間短縮を行います。
1日数十回以上実施する作業ですので、自動化することで積み上げると大きな時間短縮につながります。

10.定期的に振り返り、自分たちのやり方を調整しよう。

アジャイル開発に限りませんが、定期的な振り返りを実施し、都度自分達のやり方をチューニングしています。
過去のやり方に囚われていてたり、改善活動を繰り返さないと、ウルトラアジャイル開発は実現できません。

プロジェクト終了時に、進捗を阻害したものや、見積もりと乖離したものを明確にし、より効率的に実施するためにはどうすべきだったかという仮説をたて、次のプロジェクトに生かすようにしています。
アジャイル開発に限る話ではありませんね。

終わりに

以上、今回は弊社のコアコンピタンスである「ウルトラアジャイル」を実現するための10個のポリシーについてお話ししました。

日々、新しい技術が生まれては、生活に馴染んだり、一方で淘汰されていくという技術進化サイクルが早くなる現代において、スピード感をもってサービスを生み出すことが顧客、しいては当社の利益を最大化する方法であると確信しています。

そのためにも、引き続きウルトラアジャイルな開発のために、日々思考していきたいと思います。

今回は「ウルトラアジャイル」を実現する上での考え方(ポリシー)について記載しましたが、次回はもう少し踏み込んだ方法論について整理して記載していきたいと思います。