リーン・XP・ユーザー視点を組合せた開発と、注意すべき「陥りがちな罠」
先述した課題に対するVMwareの答えは、おおよそリーンXPの中にある。リーンXPはVMware Tanzu Labs（旧Pivotal Labsを拡張したもの）が進めているソフトウェア開発手法だ。しかしVMwareオリジナルではなく、リーンスタートアップ、エクストリーム・プログラミング（XP）、ユーザー中心デザイン（UCD）といった広く普及している手法を組み合わせたものとなる。
1点目の人材不足に対する答えは教育だ。ただし座学ではなく、アジャイル開発が分かるメンバーについてもらい、一緒に開発を進めていきながら学ぶ。アジャイル開発を習得したい人にコーチがついて伴走してもらうようなイメージだ。
なおリーンXPではプロダクトマネージャー、プロダクトデザイナー、エンジニアの3つの役割があり、それぞれの役割にコーチがつく。プロダクトマネージャーはチームの代表で「これはビジネスに寄与するか？」とビジネス要件の優先順位付けをする。プロダクトデザイナーはUIだけではなく「ユーザーは気に入ってくれるのか」とUXも考える。エンジニアは機能の実装を担当する。
よくプロダクトマネージャーはプロジェクトマネージャーと混同されるが、リーンXPはプロダクトを開発するためのチームなので、プロジェクトマネージャーは含まれない。もし開発の進ちょく状況を社内と調整するなど、必要な場合は開発チームの外に設ける。開発チームは開発に専念してもらうためだ。
2点目のテーマ選定の課題では、アジャイル開発に入る前に、念入りに課題の洗い出しと優先順位付けを行うこと。特に、プロダクトの利用者となる人物像（ペルソナ）をあらかじめ定義して、それに当てはまる人物を探し、ヒアリングをすることだ。例えば交通系アプリケーションなら「首都圏在住、会社員、家族構成……」などを定義して、該当者を探すことから始めよう。
これまでの要件定義では仮説から検討していたかもしれないが、実際のユーザーにヒアリングしないと気づかないことは多々ある。仮説をもとに、ユーザーにヒアリングを重ねることで対象テーマを選定し、具現化していく。そうすればテーマ選定の問題は解決していくはずだ。
例えばJR東日本は「JR東日本アプリ」の大幅リニューアルに向けて、2017年から動き出した。そこでVMware（旧Pivotal）の支援の下、開発にリーンXPを採用。徹底的にユーザー像を洗い出し、該当者にインタビューを重ねたという。チームメンバーはリーンXPで得たものとして「プロダクトをこうしたいという思いは必要条件ではあるが、十分条件ではない。仮説という思い込みを解消するために、ひたすらユーザーに確認すること」と語ったという。
3点目の社内プロセスとの不整合になると、リーンXPの開発手法自体では解決できない。新しくアジャイル開発を試す時に既存の社内制度が障壁になるなら、治外法権的に社内プロセスから除外してもらうなど特別対応で対処することもあるそうだ。
長らくアジャイル化支援を見てきた中村氏によると「これまでも企業がユーザーの要求や変化にどう対応していくかを考え、アジャイル化する対象が浮き彫りになっていましたが、パンデミックでこうした動きは加速してきました」と話す。
一方で、陥りがちな罠は「アジャイルが目的化してしまうこと」。あくまでアジャイルは手段なので、目的にすえてしまうと迷走してしまうし、うまくいかないリスクが高くなる。プロダクト（ソフトウェア）を開発する前に「求められるものをちゃんと定義して、そこから開発していきましょう」と中村氏は強調する。
他にも「これからわが社はアジャイル化を進めていこう」と決断した時に、その目的を人材育成とみるのか、開発手法のシフトとみるかで齟齬が生じてしまうことがある。どちらを目的としているのかは関係者間で意識合わせをしていく必要があるだろう。あるいは両方かもしれない。
アジャイル×自動化で、ビジネス価値に繋がるスピードと生産性を
リーンXPの中身を見ていこう。繰り返しになるが、リーンXPはVMwareオリジナルではないので、気に入った要素を採り入れて実践することは可能だ。テクニカルな観点では、ペアプログラミング開発（ペアプロ）、テスト駆動型開発（TDD）、継続的インテグレーションとデリバリー（CI/CD）の3つ。
ペアプロはその名の通り、ペアでプログラミングを行う。操縦士と副操縦士をイメージしてもいいかもしれない。中村氏は「ペアプロの大きなメリットはナレッジがシェアできること」と挙げる。特に初心者だと分からないことがあると、手が止まってしまったまま長時間浪費してしまう。そこでペア（コーチ役）がいると、疑問がすぐ解消できる可能性がある。
中には「一人のほうが早くできる」とか「ペアと長時間一緒だとストレスになる」と否定的な意見もある。確かに一人でも猛スピードでコーディングできるなら、ペアプロはまどろっこしくて生産性が落ちると感じられるかもしれない。そのためペアプロは教育の機会として、限定的に行うなどすると良さそうだ。強制はしないほうがいい。中村氏も「人材育成という観点ではペアプロは適しています」と言う。
TDDはプログラムに必要な機能について最初にテストコードを書いてから、本番コードを書いていくため、品質が担保されるようになる。CI/CDはビルド、テスト、デリバリーなどを自動化し、開発のサイクルを早めることができる。
中村氏は「もしリーンXPに興味があれば、代表的なプラクティスに関して、まずは書籍やWebサイトを探してみてください。色々な情報がありますので、そこからスタートすることができるでしょう」と話す。
あるいは直接関係ないかもしれないが、アジャイル開発やスクラムで特徴的な習慣を取り入れることから始めるのも良さそうだ。例えば毎朝のスタンドアップ朝礼や週次のレトロスペクティブ（ふりかえり）など、定期的に行われるミーティングだ。レトロスペクティブなら交流会的な側面もあるので、オンラインでビール片手に意見交換してもいい。こういったことなら、すぐにでも実践できるのではないだろうか。中村氏によると「やってみたら新鮮な発見があった」と感激する人は少なくない。
ただし「遊んでいるみたいで気が引ける」という意見もよく聞く。その点について中村氏は「自分たちが何をしているのか、社内でアピールしてみてください。勉強会でも、共有会でもミートアップでもいいので、社内の他チームに共有する機会を意識することで、相互理解が深まっていきます」とアドバイスする。遠慮しているとなかなか進まないので「（社内で先んじて）アジャイルをやるメンバーは社内でのコミュニケーションに長けた人をアサインするといいですよ」と中村氏。
そもそもアジャイルの目的はサービスリリースを早めることで、新しい機能を迅速に展開できるようにすること。そして、それを企業の競争力強化につなげることにある。よって、アジャイルの文脈においても自動化の仕組みは欠かせない。
昨今普及しつつあるコンテナ技術では、CI/CDなど自動化のハードルを下げることや、開発環境を容易に準備できる。アジャイルでスピードを高めるとともに、コンテナ技術を使うことで、開発生産性をより高めることが可能となる。
最後に中村氏は次のメッセージで締めくくった。「アプリケーションやプロダクトがお客様のビジネスに直結しているいま、お客様が期待されるビジネス価値（アウトカム）が何かをよく理解し、お客様に真に信頼されるパートナーであることを目指しています。アプリケーション開発支援を通してお客様の変革を実現する支援をしていくことが、私たちが目指す姿です」
