アバナードがDX時代に目指す「進化的マイクロフロントエンド開発組織」の構築とは？

アーカイブ動画

登壇者プロフィール

菅原 允氏
アバナード株式会社 ディレクター
フランスとワインをこよなく愛するエンジニアリングマネージャー＆アプリケーションアーキテクト。メーカー系SIerで.NET開発をメインにソフトウェアアーキテクトとして従事したのち、2013年9月にアバナード入社。ここ数年では、アバナードにおける、モバイルアプリおよびフロントエンド開発に特化した組織部門を立ち上げ、スペシャリストを育成しつつ、多数の案件をデリバリーしている。最近では、Experience Design（XD）チームのリードも兼任し、DesignerとDeveloperを繋ぎながら、Agile/DevOps CoachとしてUX駆動の開発プロセスを推進している。

アバナードが持つ人材と専門性、組織体制とは

アクセンチュアとマイクロソフトのジョイントベンチャー、アバナードはグローバル全体で3万8000人の従業員が働いている。そのうち、日本拠点の従業員数は700人。マイクロソフト技術以外についても様々な活動を行っている。

アバナードの組織体制は、「アプリケーション＆インフラストラクチャ」「モダンワークプレイス」「ビジネスアプリケーション」「データ＆アナリティクス」という4つの事業領域から構成されている。

またプロジェクト視点では、ソフトウェアエンジニアリングやインフラ、DevOps＆アジャイル、エクスペリエンスデザイン（XD）、セキュリティなど、人材を提供する組織で構成。菅原氏はXDチームのリードも兼任し、デザイナーと開発者とを繋ぎながら、アジャイル/DevOpsコーチとしてUX駆動の開発プロセスを推進している。

「体験」重視にパラダイムシフトするフロントエンド開発

現在、多くの企業が取り組んでいるDX。それによってフロントエンド開発を取り巻く環境が従来の単なるシステム化から、「体験」重視へパラダイムシフトしている。

「単にシステムを作るだけの時代は終わり、ユーザーにとって、品質の高い優れた製品・サービスが必ずしも良いとは限らなくなってきました。つまり、フロントエンジニアにもユーザーが求める価値を提供する力、体験をデザインする力が求められるようになってきたのです」

また、フロントエンジニアがカバーする技術領域や責任範囲もダイバーシティ化しており、最新技術の進化に対し、どこから手をつけたらいいのか悩むエンジニアも増えている。 フロントエンジニアも多種多様化しており、「デザイン寄りのフロントエンジニア、バックエンド寄りのフロントエンジニアなど定義が曖昧になっている」と菅原氏は指摘する。

菅原氏が立ち上げたフロントエンド開発組織「Front-End Development Team（通称FED）」は、ソフトウェアエンジニアリング部門の1組織として、インフラやアドバイザリー、XD、DevOps＆アジャイル、セールスなどの他の組織と結びついてサービスを提供する。

フロントエンドというとWebシステムというイメージがあるが、アバナードの場合はモバイルアプリケーションもカバーしている。また、スクラムで開発する場合は、フロントエンドエンジニアもロールの区別なくデベロッパーとして定義されるので、バックエンドの開発も担当することもあるという。

現在FEDチームに所属しているメンバーは約50人。チームの責務としては、フロントエンドとモバイルの開発だけでなく、提案活動やデリバリー活動、運用保守、技術研究なども含んでおり、複数チームにまたがる領域を対応することもある。

「案件の大きさに応じてメンバーを組み合わせ、One to Many型でアサインします。一人の人が複数のプロジェクトにアサインされることもあり、必要に応じ、グローバルチーム、他の組織、ニアショア、オフショアなどとも連携し、柔軟にチーム規模を増減させた運営をしています」

「相手をリスペクト」しながら、得意領域を武器に成長する

2017年、菅原氏はモバイルアプリケーションの開発を任されることになり、複数のプロジェクトで経験を蓄積した。当時はモバイルアプリ開発の組織がなかったため、10人程度のモバイルアプリ開発者を集め、2018年に非公式の組織ながらアバナード発のモバイルアプリ開発組織を組成した。

2019年に、正式組織としてFEDが誕生。2020年には扱う技術領域の拡大及びXDチームとの協業を開始した。現在は他チームを含め、クロスファンクショナルなチームとしてコラボレーションを拡大している。FEDチームのコンセプトは「スピード」「クオリティ」「エキスパート」「プロアクティブ」「チェンジ」の5つである。

「誰かが失敗をしたとしても、それを責めるのではなく、失敗を糧にさらに成長してほしいというカルチャーを持っている。それをチームのメンバーにも認識して欲しいと思い、コンセプトに入れています」

組織の中で一番大事にしていることは、「相手をリスペクトすること」だと菅原氏は言う。例え対立する場面があっても、相手をリスペクトして対立することをいつも念頭に置いて動いてほしいのだと強調する。

顧客体験の価値を提供するエンジニアリング組織とは

続いて、フロントエンド開発組織が直面したチャレンジが語られた。最初に紹介されたのは、顧客体験の価値を継続的に提供し続けるためには、どうエンジニアリング組織を育てていくか。

その問いに対し、菅原氏は「ワインを飲む」シーンを例に説明を行った。食事をしたいと思い、フレンチのレストランに行った。すると料理に合わせるワインを勧められ、そのワインを飲んだ。このときの「ワインを飲む」という体験は、ワインを飲むことによって食事のさらなる満足感が得られたことである。

一方のレストランでは、スペインのワイン「チャコリ」を注ぐことにチャレンジした。チャコリは20cmぐらいの高さから注ぐことで、香りとおいしさが増すワイン。高い位置から注いでみたが、失敗。だが失敗によって「気づき」が得られたという。このように同じワインを飲むという体験でも、得られる価値は異なるのだ。

『経験価値マネジメント』の著者であるバーンド・H・シュミットいわく、顧客体験は5つに分類されるという。

良い体験はポジティブな感情を含むようだ。これを、アバナードのある40代男性の行動に着目し、エンジニアリング組織の「体験」を観察してみたのが以下である。

• Sense（感覚的価値）

• Feel（情緒的価値）

ポジティブ体験：チームメンバーが順調に成長して嬉しい。久しぶりにコードを書いたら楽しかった。
ネガティブ体験：仕事が減らなくてつらい。

• Think（創造的・知的価値）

ポジティブ体験：デザイン思考は面白い。
ネガティブ体験：アサインされたプロジェクトで扱っている技術がレガシーでモチベーションが下がる。

• Act（行動・ライフスタイルに関わる価値）

ポジティブ体験：リモートワークで通勤時間が減って、自分の使える時間が増えた。
ネガティブ体験：リモートワークで足がむくむ。

• Relate（準拠集団への帰属価値・社会的経験価値）

ポジティブ体験：デザイナーチームはみんなMacBookが使える。
ネガティブ体験：フロントエンジニアチームは、MacBookが使えない人もいる。

ここで大事なのは「ネガティブな体験をポジティブに変えていくところ」と菅原氏は言う。そのためのチャレンジとして、アバナードではさまざまな取り組みを行っている。

変化の激しいフロントエンド周辺技術をどう選択するか

2つめの問いは、多様かつ細分化されすぎたフロントエンド周辺技術の著しい変化に対し、エンジニアリング組織として何を選択し、どう追随していくのか。

「主流のトレンドにターゲットを絞り、主に3つのフレームワークを使っています。これまではAngularを使うことが多かったが、最近ではReact、Vue.jsも増えています。モバイルアプリ開発も主流のターゲットに絞り、主に使っているのはSwift、Kotlin、Flutterなど。最近は1ソースでiOSとAndroidの両方に対応したいというニーズが増えているので、Flutterを取り入れています」

では、技術の主流を知るにはどうすればよいのか。その手段として菅原氏が勧めるのが、次のサイトでチェックすることだ。FEDでは特定の技術に依存せず、ソリューション適性に応じて、柔軟かつ最新技術に追随できる技術を中心に、テクノロジー選定を行っている。

https://2020.stateofjs.com/en-US/technologies/front-end-frameworks/

アバナードではフロントエンド技術だけではなく、バックエンド技術、さらにはマネジメント技術なども必要な技術スタックを選定している。

フロントエンジニアをどう採用し、育てていくか

続いてのテーマは、フロントエンジニアをどう採用し、育てていくのか。アバナードのフロントエンドチームでは以下のような人物を求めている。

1. 相手を尊重したコミュニケーションが取れる
2. テクニカルパッションを持っている
3. 自身の置かれている状況を理解し、自ら考えて行動できる
4. 自身のやりたいこと、将来のビジョンに向かって具体的な行動を起こせる
5. 変化に柔軟に対応できる
6. 他社と差別化できる武器を持っている

フロントエンジニア、バックエンドエンジニア、デザイナーのクロスファンクショナルなチームコラボレーションをどう実現するかについては、「今、まさにチャレンジしている部分」と、菅原氏。フロントエンジニアとデザイナーは関心領域が異なるため、意見が対立することもある。

両者の溝を埋めるために菅原氏たちが構築しているのは、デザインシステムの構築である。デザインシステムとは、プロダクト作成に必要なルール・ツールをまとめたもの。デザイナーとフロントエンジニアの架け橋になる仕組みとして普及しており、アバナードのプロジェクトでも「Storybook」によって構築・適用することが増えているという。

またプロジェクトチームの編成の工夫も必要だ。一般的にUI/UX（デザイナー）チームは独立していることが多いが、機能開発チームとロールで境界があると、それを盾に対立する傾向がある。

境界をなくすために、UI/UXチームメンバーを機能開発チームに割り当てることも考えられるが、開発が進むとデザイナーの参画率が減るため、デザイナーが孤立する傾向にある。

そこでアバナードでは両者の良いところを活かすべく、UI/UXチームと機能開発チームは分離するが、UI/UXチームが複数の機能開発チームを担当するという編成を検討している。

フロントエンジニアのモチベーションやエンジニア体験はどう向上させる？

最後のテーマは、最新技術を追い求めたいフロントエンジニアのモチベーションやエンジニア体験をどう向上させるか。アバナードでは、次のようなテクニカルパッションをつなげるための取り組みがある。

• アサイン希望のヒアリングおよびアサインでの反映
• エンジニアロードマップの作成 ・小さくても実績を作りクライアントや上位層への説得材料にする
• トレーニング時間の年間80時間確保
• 技術情報共有サイトの構築
• テクノロジースペシャリスト向けキャリアパスの解説
• 技術スタック変更を伴う継続的なアサイン変更
• 会社からの技術研究に対する費用補助の提供

また、アバナードで最新技術を適用した例として、大手家電メーカー向けのSNSモバイルアプリ開発プロジェクトが紹介された。

AndroidとiPhone向けにReactNative/Swiftでサービスを提供していたが、運用コストの増大からFlutterに置き換えた。開発・運用コストの削減を図ったことに加え、最新技術に触れたことで、開発者のモチベーションが大いに上がったという。

進化的マイクロフロントエンド組織へ

現在、FEDでは進化的マイクロフロントエンド組織へのチェンジを図っている。この背景にあるのはアバナードで扱っている技術が増えており、チャレンジしていきたい領域があるからだ。

マイクロフロントエンドとは、マイクロサービスの考え方をフロントエンドに拡張した手法で、モノシリックなフロントエンド部分をマイクロサービス化することで、マイクロサービスの課題を解消できるという。もちろんデメリットもある。ドメイン分割が非常に難しく、独立性が増す反面、実装難易度が上がることだ。

アバナードのフロントエンド組織はまず2人で立ち上げたことから始まった。これが第1段階で、第2段階に入り、フロントエンド開発リーダー、マークアップエンジニア、フロントエンジニア、BFFエンジニアが加わり、1チームでフロントエンド開発をカバーできる状態になった。

第3段階は複数チームを束ねるメンバーが成長し、チームから組織へと成長。ここではプレイングリーダーとなるフロントエンド部門長の負荷が高くなることと、チーム間の情報連携をいかに行うかが課題となった。その課題を解決するため、第4段階ではフロントエンドアーキテクトを追加し、チーム間の連携に対する複雑さに対処した調整を行っている。

さらに組織が大きくなると、フロントエンドディレクターを追加することで、分散型リーダーシップを実現するという第5段階への進化が必要になる。チームの独立性が高まる一方で、フロントエンドディレクター間の連携が必要だ。連携をどうするかは大きなポイントとなる。

アバナードでは、今後もマイクロフロントエンドという点から、クロスファンクショナルチームの実現を目指していくという。

最後に菅原氏は「フロントエンジニアも体験をデザインすることにチャレンジしてほしい。アバナードが今狙っているのは、マイクロフロントエンドの領域。現在フロントエンジニアを絶賛募集中なので、興味のある人はアクセスしてほしい」と語り、セッションを締めた。

【Q&A】参加者から寄せられた質問に回答

セッション終了後、質疑応答が行われた。

Q.AngularやVue.js、Reactなどの言語を、プロジェクトに応じてどう使い分けているか。

戦略的な視点から、我々が使いたい言語をクライアントに提案していくパターンが増えてきました。以前はプロジェクト時のメジャー言語がメインでしたが、最近ではエンジニアが使いたい言語が増えてきたので、クライアントニーズとマッチするかどうかを確認して、調整して適用していくことが多いです。

Q.80時間のトレーニング、新技術への費用負担などの施策を、経営層の理解を得るためにどう提案したのか。

ボトムアップではなく、アバナードでは全社員に対してアンケートを実施しており、そこで出てきた要望などを集計して、具体的な施策に落とし込みます。80時間のトレーニングもそういった中から出てきた施策だと思います。

Q.Storybookの具体的な活用方法を知りたい。どのように用いることで、デザイナーとフロントエンドエンジニアのコミュニケーションが改善されたのか。

使い始めたばかりなので、あまり成果については語れませんが、StorybookはReactのコンポーネントレベルまで落とせるので、エンジニアも理解が進む。またエンジニアにもデザイン案を開発してもらうことも考えています。

Q.デザイナーはHTMLやCSSを調整する認識であっているか。またデザイナーチームや開発チームで独立して開発している中どうやってソースコードの管理を行っているのか。

HTMLやCSSだけを担当するメンバーはいますが、ケースバイケースです。リポジトリについては、ほとんどのケースではGitで共有し、フロントエンドの詳細なコーディングを行っていきます。そこは分離すると大変なので、1つにしています。

Q.モバイルの組織を作った背景について聞きたい。

顧客ニーズが高まっていたことです。ハイブリッドをやる時期もあり、モバイルWebがいいという潮流もありましたが、ネイティブを作りたいというクライアントが多かったので、組織としてやってみることになりました。技術スタックはなかったので、そのときは必死に吸収していきましたね。

Q.クライアントから示されることはなかなかないと思うが、あえて新しい技術を使う機会を作るためにしていることはあるか。

メリットを伝え、どこがお互いの繋がるポイントかを考えることです。お客さまにとってのメリットを考えるのは大変ですが、技術情報の共有をすることもある。そうすることで、このテクノロジを使ってみようと賛同されることもまれにある。自分たちのペースに巻き込むようなことをしていくと機会が増えると思います。

Q.クライアントがデザインやフロントエンド表現についての期待を言語化できていない、リテラシーギャップが大きい場合、どういう体験を作るかの認識合わせはどのようにしているか。

よくやる方法は共感マップを作ることです。期待値が自分たちで分かっていないクライアントにはワークショップを開催し、意見を引き出すことをしています。思いがけない潜在的ニーズが含まれていたこともある。時間がかかりますが、価値があるものを作るときは有効な手段です。

Q.失敗を歓迎する文化、社員をリスペクトする文化はどういう取り組みが必要なのか。

アバナード社長の安間がそのことを大々的に公言しています。トップダウンで言ってくれることで精神的負担が軽減される。失敗するにしても2種類ある。やってはいけない失敗と、賢い失敗。前向きな失敗であればいいのではと思います。

Q.クロスファンクショナルな組織でフロントエンドエンジニアの成果に対する評価はどう行っているか。

ゴールがないと評価は立てられないので、必ずゴールを立てています。そこに対する結果、例えば今だとプロジェクト軸で動いているので、プロジェクトに対するパフォーマンスで評価します。フロントエンジニアの成果は、成熟度に合わせて、ケースバイケースに行いますが、基本的には開発の中身で見られます。

どんなに品質が良いシステムを作っても使われないと評価されません。自分たちがどの段階にいるのかを考えるのが大事です。それは可視化しないと出てこないので、自分で自分をよく観察すること。例えば自分のジャーニーマップを描いたり、スキルマップを作ったりするとよいでしょう。そうすることで自分の進む方向が見えてきます。アバナードに興味があれば、いつでも門を叩いてください。

注* Microsoft、XXXXX は、米国 Microsoft Corporation の米国及びその他の国における登録商標または商標です。
注* その他、記載されている会社名、製品名は、各社の登録商標または商標です。

アバナード株式会社
https://www.avanade.com/ja-jp

アバナード株式会社の採用情報
https://www.avanade.com/ja-jp/career