SHOEISHA iD

※旧SEメンバーシップ会員の方は、同じ登録情報(メールアドレス&パスワード)でログインいただけます

CodeZine編集部では、現場で活躍するデベロッパーをスターにするためのカンファレンス「Developers Summit」や、エンジニアの生きざまをブーストするためのイベント「Developers Boost」など、さまざまなカンファレンスを企画・運営しています。

モダンアプリケーションへ舵を切れ(AD)

アジャイル×自動化でプロダクト開発にスピードと生産性を――仮想化技術の雄VMwareが組織のアジャイル化を支援する理由

  • X ポスト
  • このエントリーをはてなブックマークに追加

 アプリケーション開発を素早く実践するにはアジャイルやスクラムといった手法に、コンテナ環境が欠かせない。いざアジャイル化に舵を切ろうとした時に直面する課題にはどんなものがあるか。克服するにはどうしたらいいか。マルチクラウドのプラットフォームとアジャイル化支援に強みを持つヴイエムウェア 中村貴弘氏に訊いた。

  • X ポスト
  • このエントリーをはてなブックマークに追加
Sヴィエムウェア タンズ ジャパン ディレクター 中村貴弘氏
ヴィエムウェア タンズ ジャパン ディレクター 中村貴弘氏

組織のアジャイル化を推進する中で直面する3つの課題

 いまアジャイルを積極的に主導している企業の1つにVMwareがある。VMwareと聞くと仮想化技術を思い浮かべる人も多いのではないだろうか。まずはVMwareの現在地から紐解いていこう。

 ここのところVMwareはグローバルで自社の現在地を「第3章」と表現している。最初にVMwareがサーバーの仮想化を実現したのが「第1章」とすると、続いてデータセンターの仮想化(SDDC:Software-Defined Data Center)を実現したのが「第2章」。そして現在は「第3章」へと移り、マルチクラウドなど、クラウドやプラットフォーム選択の自由度を高めているところだという。章が移るにつれ抽象化のレイヤが上がっているのが分かるだろうか。

 第3章のマルチクラウドの抽象化と密接な関係にあるのがコンテナでありKubernetesとなる。VMwareでは、コンテナプラットフォームの構築・運用に必要な機能をオールインワンで提供するVMware Tanzu for Kubernetes Operationsという製品と、コンテナアプリケーションの開発生産性を向上させるVMware Tanzu Application Platformという製品を提供している。このコンテナプラットフォームに目を向けると、そこで稼働すべきアプリケーションをいかにモダナイズしていくかが課題となっている。そこで、VMwareではプラットフォーム製品のみならず、顧客のアジャイル化を支援しているのだ。

 VMware にとって、Pivotalとの統合で得たアジャイル化支援は一つの強みとなっている。今回話を聞くヴィエムウェア タンズ ジャパン ディレクター 中村貴弘氏もPivotalからVMwareへとジョインしたうちの1人だ。

 中村氏は顧客企業がアジャイル化していく中で直面する課題は大きく分けて3つあると指摘する。

 1点目は人材不足。アジャイルを推進したくても「そもそもできる人がいない」、あるいは「スキルが足りない」ことで前に進めない。

 2点目はテーマ選定。アジャイルを推進すると決断したものの、「何を対象にすればいいのか分からない」といったことが多い。例えば「フィンテック」や「IoT」などのテーマはあるものの、何から手をつけていけばいいのかわからず、右往左往してしまうことも多い。

 3点目は社内プロセスとの不整合。予算申請方法や開発プロセスがウォーターフォールを前提としていて、アジャイル推進の足かせになってしまう。

リーン・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など自動化のハードルを下げることや、開発環境を容易に準備できる。アジャイルでスピードを高めるとともに、コンテナ技術を使うことで、開発生産性をより高めることが可能となる。

 最後に中村氏は次のメッセージで締めくくった。「アプリケーションやプロダクトがお客様のビジネスに直結しているいま、お客様が期待されるビジネス価値(アウトカム)が何かをよく理解し、お客様に真に信頼されるパートナーであることを目指しています。アプリケーション開発支援を通してお客様の変革を実現する支援をしていくことが、私たちが目指す姿です」

この記事は参考になりましたか?

  • X ポスト
  • このエントリーをはてなブックマークに追加

【AD】本記事の内容は記事掲載開始時点のものです 企画・制作 株式会社翔泳社

この記事は参考になりましたか?

この記事をシェア

  • X ポスト
  • このエントリーをはてなブックマークに追加
CodeZine(コードジン)
https://codezine.jp/article/detail/16214 2022/08/16 12:00

イベント

CodeZine編集部では、現場で活躍するデベロッパーをスターにするためのカンファレンス「Developers Summit」や、エンジニアの生きざまをブーストするためのイベント「Developers Boost」など、さまざまなカンファレンスを企画・運営しています。

新規会員登録無料のご案内

  • ・全ての過去記事が閲覧できます
  • ・会員限定メルマガを受信できます

メールバックナンバー

アクセスランキング

アクセスランキング