「アジャイル開発」を導入して気づいた2つのこと（ビジネス側の目線）
大企業育ちの末にスタートアップのVoicyで奮闘中のAYAです。
Voicyではサービス機能の拡大に伴い、開発スピードを上げていくために「アジャイル開発」を導入し始めました。
ご存知の方も多いと思いますが、「アジャイル開発」とは、機能単位の小さなサイクルで、計画から設計・開発・テストまでの工程を繰り返すことを通じて開発を進めていくことです。
コンサルにいた頃、大手企業に「アジャイル開発」への移行を提案する資料を作ったり、導入ケースのプロジェクトを横目で見ていました。
しかし、実際に自分たちが「アジャイル開発」を取り入れるとなると、気づいていなかったことが多くあり、多くの学びがあります（現在進行中）。
ということで、現時点で気づいた「アジャイル開発」の導入を検討する際に、経営の観点で留意しておいた方が良さそうなポイントを整理したいと思います。
今のところ、気づいたポイントは以下の2つです。
ビジネス側との密な協働を仕組み化
システム開発それ自体が目的にならないように、事業としてのゴールを常に意識して進める仕組みがとても重要だと気づきました。
細かく開発モジュールを分けて進めるため、より良い機能を作ることに集中するあまり、事業との結びつきを意識することが薄れることも。
そういえば、このことは「アジャイルソフトウェア開発宣言」の背後にある12の原則にも定められています。「アジャイルソフトウェア開発宣言」とは、2001年に当時ソフトウェア開発手法分野で活躍していた17名の専門家によってまとめられた文書です。一般的には、この宣言がアジャイル開発を公式に定義した文書だと考えられているそうです。
Business people and developers must work together daily throughout the project.
（ビジネス側の人と開発者は、プロジェクトを通して 日々一緒に働かなければなりません。）
実際に、サービスが複雑になっていくと機能単位だけでなく、全体のバランスなどをしっかりと確認する必要が出てきます。UX観点だけでなく、法的に問題が無いのか、更には事業として効果的な組み合わせなのか、など…
こういった観点が抜け落ちないためにも、Biz Devや経営企画などのチームも一緒に参加して進めることができる体制が不可欠だと思います。
リリースの基準を明確化
「アジャイル開発」を導入したからには、システムリリースの件数に拘るモードに入るかもしれません。そもそも「アジャイル開発」って、短期間で開発・リリースをして、マーケットやユーザーの反応を見て、改善を重ねていくことですし、これ自体に問題は無いと思っています。
ただ、すでに出来上がっているプロダクトに追加する新機能などをリリースする場合、その新機能があまりにひどいものだと、一気にSNS上で「改悪」だとか様々な意見が流れてしまい、既存のプロダクト部分にまで大きく影響が出てしまう場合があります。
そのため、会社としてリリース基準をしっかり共通認識で持っておくべきだと思います。リリース基準とは、「誰（もしくは、どの会議体）がリリースの最終決定をするのか？」みたいなことです。
ちなみに開発チームだけで決定していくのは危険だと思います。第三者の目を入れてチェックをすることは重要だと思っています。
そして、せっかくのアジャイル開発でスピードアップしたいわけですから、その決裁が混み合ってリリースに遅れが生じるようなことがないように考える必要があります。なので、多くの人たちの決裁が必要とならないように設計したいと思います。
今後もVoicyでは更にサービスを進化させていくため、様々なポジションの採用を行なっています。
一度カジュアルに話でも聞いてみたい、と思ってくださった方、ぜひ月1回開催の「Bar Voicy」にお気軽にご参加ください。
この記事が気に入ったらサポートをしてみませんか？