📣

アジャイル開発って至極真っ当で普通のことだったよ

2022/11/08に公開約2,500字

開発プロセスに大きな興味を抱くきっかけは、全エンジニア共通だと思うんです。(意味深)

自分も最近は開発プロセスに強く関心がある状況なので、ふと目の前にあった『アジャイルサムライ』を手に取り、そのまま購入しました。

今までアジャイルについては、サイクルを高速で回すイマドキのカッコいい開発手法、くらいの曖昧な理解しか持っていませんでしたが、改めてしっかり読んでみると、「あれ。アジャイル開発って至極真っ当で普通のことじゃね。」 と感じるものでした。

イテレーションとか、スクラムとか、デイリースタンドアップとか色々言葉が登場してイケイケな感じがするアジャイル開発ですが、本質を見失ってはいけないなと感じます。アジャイル開発の本質は、もっとシンプルでした。12の原則を早速リスペクト)

アジャイル開発の本質

『アジャイルサムライ』を通して自分がずっと感じたものは、

  • 顧客に価値を届けることが最も大切なことである
  • アジャイル開発は、それを達成しようとする姿・思想・試みを指す

という2点です。
イテレーションやスクラムの方法論は、それを叶える1つの手法に過ぎないんだという気づきです。

顧客に価値を届ける

なぜプロダクトを開発するのでしょうか。
立ち返ってみると、その根本にあるのは必ず「何らかの課題を解決するため」だと思います。

当然ですが、課題を解決するためには 「お客様が本当に求めているものを開発し、提供する」 ことがプロダクト開発において最も大切なことであり、忘れてはいけない価値観です。

それを達成するためには、「お客様が求めているものと、今開発しているプロダクトがずれていないか」というチェックを定期的にしてもらうのが良いですよね。全部作った後に見せるのではなく、定期的にレビューする方が良いに決まっています。

というわけで、開発を短い工程に区切り、ちゃんと動くものを作り上げ、お客様に見てもらってフィードバックを貰おうとなったわけですが、これが「イテレーション(1~2週間で設計・実装・テストまで完成させる)」や「ショーケース(お客さんにプロダクトを見てもらう)」という形で表れたわけです。…よく考えるとめっちゃ当たり前ですよね。

他にも、お客様が求めているものが変わることだって往々にしてあるはずです。ビジネスに応じて要求が変わるわけです。(特に最近は変化が早いと言われているのでなおさら。)そんな時に、

「いや、それは契約時に要件として無かったですよね?いまさら無理です。もしくは追加料金と工数をいただきます(ニッコリ)」

なんて回答は、「価値を届けること」から「プロダクトを作り上げること」に焦点が置かれてしまっている証拠で、(感情的にはともかく、価値を届けるという本質から考えると)そこには何の価値もないことになります。

要件の変更を受け入れられるようにできたらいいよね、じゃあイテレーションという単位で開発を進めて、機能の優先順位とスコープを調整できるようにしていけば良いんじゃね、という開発を目指しているのがアジャイルです。…発想はめっちゃ普通で真っ当です。

何だか受託寄りですが、自社開発だって、市場の変化にあわせて柔軟に開発を変えて進められると強いですよね。

アジャイル手法も結局は価値提供

イテレーション以外にも様々な特徴が言葉が出てきますが、すべて顧客に価値を届けることを考えると自然なものです。

ベロシティを測る
→ ベロシティ(開発速度)を測ることで、進捗に対する客観的な事実を明るみに出すことができる。間に合わないのを隠したり残業でカバーするのではなく、スコープを減らす?スケジュールを延ばす?なぜ遅れている?という建設的な議論を顧客とすることができる。

インセプションデッキを作る
→ 「なぜプロダクトを作るのか」や「何をやるべきで何をやるべきではないか」という意識統一が図れるデッキを開発チーム内で共有することで、メンバーそれぞれが自分の仕事の意義を意識するようになり、より良いプロダクトが生まれやすい組織を作り出すことができる。
※反対に、上流で何が起こってるか分からんけど自分に振られたタスクをやる、という状態では顧客の価値を届けようとする意識が薄れる。

帽子をかぶる
→ 明確な役割分担をしたときに起こりがちな、「自分はテスターなのでデバッグは担当範囲ではありません」「私は開発者なのでデプロイはやりません」という仕事バリアー(受動的)を張るのを防ぐ。それぞれが自由に役割を変えることで主体的に仕事に取り組めるし、「イテレーションで設計からテストまで全部やって動くものを作る」にはメンバーがどんな役割の帽子もかぶれる状態が良いに決まっている。

テスト駆動開発・CI/CD
→ 変更に強くなる。素早い開発を可能にし、柔軟な機能変更を求めている顧客の意見を反映できる。

うん。すごく真っ当だ。

まとめ

何らかの課題を解決する良いプロダクトを作るにおいて、

  • 開発メンバーひとりひとりがプロダクトのビジネス的意義を理解している
  • ズレのない、本当に求められている価値あるものを開発する
  • 要件の変化・仕様の変更に柔軟に対応できる

という状況は非常に望ましいものです。という訳でそれを実現する方法を考えてみました…がアジャイル開発でした。

何かとカッコイイ響きがあるアジャイル開発ですが、その原理原則は「顧客に価値を届ける」という非常にシンプルで至極真っ当なものからスタートしており、こっちを忘れてアジャイル開発の「型」だけ取り入れて実行するのは全く意味のないものだなと思います。

とはいえ、これらを実践するのが難しいわけですが、ではどうやってこれを実践するか、ということをアジャイルの本質を忘れず継続的に考えていきたいなと思いました。

Discussion

ログインするとコメントできます