2024年4月24日、一般社団法人 日本CTO協会（以下、日本CTO協会）は「Webフロントエンド版 DX Criteria」を策定した。本ガイドラインは、日本CTO協会が監修・編纂する「DX Criteria」のWebフロントエンド領域特化版だ。近年、Webフロントエンドの技術環境は日々変化しており、組織としての変革やエンジニア個人の技術のキャッチアップなどの対応が困難になりつつあるのが現状だ。そのような中、フロントエンド領域では組織としてどのように課題を棚卸し、組織ひいては企業としてのケイパビリティを高めていくべきだろうか。本ガイドラインを策定した同協会DX Criteria策定ワーキンググループの佐藤歩氏と古川陽介氏に聞いた。
佐藤歩氏（画像左）
KINTO テクノロジーズ株式会社 IT/IS部
古川陽介氏（画像右）
株式会社ニジボックス デベロップメント室室長
目次
「フロントエンド領域の課題に対するガイドラインになれば」
ーーまずは「Webフロントエンド版DX Criteria」策定の背景についてお聞かせください。
古川氏：きっかけは、ニジボックスが日本CTO協会の法人会員に加盟することになり、当社主催のイベントに理事の広木（大地）さんをお呼びして、広くDXに関連するテーマで話し合ったことでした。そのときにジャストアイデアで「DX Criteriaのフロントエンドにフォーカスさせたものをつくりませんか」と聞いたところ、広木さんから「ぜひやってみましょうよ」と言っていただいたのが始まりです。
オリジナルのDX Criteriaは、Developer eXperience（開発者体験）とDigital Transformation（企業のデジタル変革を意味するDX）のどちらも取り扱います。このようなガイドラインは非常に有意義なのですが、もう少し範囲を絞って開発にフォーカスしたものも必要なのではないかと考え、策定することにしました。
ーーそこからワーキンググループをつくり、本格的に策定を始めた流れでしょうか。
古川氏：佐藤さんには素案作成の段階から自ら手を挙げて参画していただき、以来二人三脚で策定を進めたので、とても助かりました。最初に私が考えていたアイデアはボトムアップに寄りがちで、開発の現場で困っていることやアンチパターンなどの観点から進めていました。それに対して佐藤さんから、トップダウンの目線もあった方がいいと指摘をいただき、両方の視点からアイデアを広げ、項目を作成していきました。それでも、100もの項目を策定するのは本当に大変でしたね（笑）。
佐藤氏：そうですね（笑）。当時、たまたま私が法人会員として日本CTO協会に入ったばかりで。日本CTO協会のSlackにジョインしたところ、広木さんが「Webフロントエンド版DX Criteria」の策定メンバーへの参加を呼びかけていました。フロントエンドだったら、役に立てることがあるだろうと参加したんです。策定は基本的に私と古川さんの二人体制で進めていきましたが、レビュアーには各領域の専門家の方々に参加していただき、1年ほどかけてブラッシュアップさせていきました。
ーー現在、日本の開発組織におけるフロントエンド領域には、どのような課題があるのでしょうか。
古川氏：そもそも、フロントエンドはまだ歴史が浅い領域です。おおよそ2010年代から徐々にワードとして流行り始めて、それ以前はマークアップやコーダーといった違う内容で呼ばれていました。しかし、技術的革新が立て続けに起こり、私がフィールドにしているNext.jsやReactといったフレームワークも、2010年代後半ごろから領域として確立され始めました。このように、フロントエンドは比較的新しい領域のため、開発の現場では浸透しつつも、組織づくりの中ではあまり定着していません。
エンジニアが技術のキャッチアップができていない場合や、まだHTMLやCSSだけで開発していた時代から抜けられない現場もあります。それぞれの開発組織が手探りの状態でしたが、今は徐々にベストプラクティスやアンチパターンが出てくるようになり、大きな枠組みで指標がつくれるようになったのが現状だと考えています。
佐藤氏：「フロントエンド領域は技術の変化が早い」という話は10年前から聞いていました。たしかにフロントエンドは技術スタックが急速に変わり、すぐに既存技術が陳腐化してしまうこともあるので、決して遅くはないでしょう。しかし、そのような変化の元となっているのがどこかと考えると、やはりクライアントサイドやデバイスのスペック、加えて通信速度があると思います。鶏卵の前後は別として、そのような技術発達によってクライアントサイドの要求が急速に変わっています。データベースは持続可能性を重視して開発を行いますが、クライアントサイドはどうしても、そのときどきの要望にフレキシブルに対応する観点が必要になります。
とくにWebの場合はオープンなプラットフォームで、変化が激しく技術選定の幅も広いので、まさに手探りの状態です。環境と技術の変化に追従し続けることは、やはり個人の成長観点でもチームや組織の技術戦略でも課題だと思います。そのようなフロントエンド領域の課題に対するガイドラインとして策定したのが、「Webフロントエンド版DX Criteria」です。自分たちの持っているケイパビリティで不足しているところや伸ばすべきこと、組織の成長として目指すべき方向性を考える手がかりになればと考えています。
フロントエンド技術に関わるすべてのエンジニアに適用可能
ーー本ガイドラインには、計100項目が設定されています。Webフロントエンド領域に特化している分、中には項目決定に苦労したものや慎重な議論を要したものもあるかと思います。
古川氏：ありましたね（笑）。とくに組織にフォーカスした大テーマ「成長できるチーム」は、最後まで議論があったポイントです。フロントエンドの技術的な側面だけであれば、組織の話は不要になります。そもそもまずはテーマに組織の観点を入れるべきかについても議論になりました。しかし、現状のフロントエンド領域が直面する局面や実態を反映して策定すると考えれば、組織に触れなければならないと考え、項目を加えることにしました。
ただ、フロントエンドの組織づくりを考えると、どうしても自分たちの組織を念頭に置いてしまいがちです。より小規模なチームにも適用するにはどのような項目を策定すべきかも、レビューの方々を含めてさまざまな意見や観点を取り入れながら決定していきましたね。
佐藤氏：やはり私たちはマネージャー職なので、チームや組織の成長には思い入れがあります。そんな私たちだからこそ書けるものがあるのではないかとも考えました。だからこそ、古川さんがお話ししたことも含めて、最終的に技術のクライテリアに対してどこまでの項目を入れるかの着地点は議論を重ねました。ただ、実際にはお互い長年フロントエンド領域で経験を積んできていたので、「たしかにここは重要だよね」と共通認識を確かめ合う場面も多々ありました。
ーー「Webフロントエンド版DX Criteria」では5つの大テーマと5つの小テーマで構成され、合計100項目が設定されています。この構成の意図についてお聞かせください。
佐藤氏：「DX Criteria（企業のデジタル化とソフトウェア活用のためのガイドライン）」を策定した広木さんからアドバイスをいただいたこともありますが、それぞれのカテゴリーごとに配点を変えると非常に大変で、そこでもまた議論が必要になります。そのため、それぞれのスコアが割り付け100点になるよう均等にして、ある程度データが集まった際に比較検討がしやすいような構成を意識しています。
古川氏：実際のアセスメントシートをご覧いただくとわかりやすいと思います。今回は項目にあてはまる場合は「TRUE」、あてはまらないものには「FALSE」、一部あてはまるが懸念事項のあるものは「BUT」として、それぞれの配点は1点、0点、0.5点としました。ただ、ここで意図しているのは点数の寡多ではなく、ある程度データが集まった際に偏差値を出せるような仕組みにすることです。スコアと組織の良し悪しは必ずしも相関しません。むしろ組織やチーム全体で現在の課題や強みを洗い出し、今後のチームビルディングに役立てるためのガイドラインと捉えていただきたいと考えています。
ーーたしかに、組織やチームのあり方や規模は企業によってさまざまで、項目に当てはまらない場合も考えられます。
古川氏：策定にあたって想定するチーム像については非常に悩んだところです。さきほどフロントエンド領域は成熟途上にあるとお話ししましたが、市場的に見ても開発者が不足していると思っています。チームとしてはどうしてもエキスパートが集約した形になり、複数の開発を兼任するケースが多い印象です。今後フロントエンドエンジニアが増えてくれば、専任のフロントエンドチームをつくれるような規模になると思います。しかし、現状ではそのような企業はまだ少ないことを念頭に置いた上で、専門の知識やナレッジを横に波及させていくイネーブリングも必要になると考え、「成長できるチーム」にはイネーブリングを追加しました。
佐藤氏：組織に関する大テーマを「成長できるチーム」としたのも、今回のコンセプトでもある「ボトムアップからもアプローチできるクライテリア」がベースとなっているからです。たとえば専門家が分散出張型で開発を手がけるチームなのか、もしくは一つの開発チームの中にいるフロントエンドの開発者が担当するのか。こうした構成やロールに関わらず、エンジニアなら誰もが自分ごとで考えられるアクショナブルなものを志向しています。
さきほど古川さんがお話ししたイネーブリングのようなパターンもあれば、事業ごとに開発チームがあり、その中でフロントエンドエンジニアを一人か二人専任でおくスタイルもあります。スタートアップの場合はより渾然一体としていて、フロントエンドエンジニアが不在の可能性もあるなど、さまざまなパターンが考えられます。
そのため、今回のテキストでは「フロントエンドエンジニア」という言葉はなるべく使わずに、フロントエンド技術に関わるすべてのエンジニアに適用可能になるよう意図しました。だからこそ現状のチームでは当てはまらない項目もあるため、スコアの優劣で判断せず、今後の成長戦略を考える一助としてポジティブに活用いただきたいです。
「Developer eXperience Day 2024」で実データを元にしたセッションを予定
ーー作成者のお二人としては、「Webフロントエンド版DX Criteria」を具体的にどのように活用してほしいとお考えですか。
古川氏：まず、フロントエンドチームを強化したいと考えている方々が主なターゲットになると考えています。とくに、チームはつくったものの、今後どのような成長戦略を描き、そのためにどのような取り組みをすべきかを検討している方に役立ちます。
次に、まだチームをつくってはいないものの、フロントエンド領域の重要ポイントやチームの作り方について知りたいと思っている方にも、このクライテリアの内容を見ていただきたいです。それぞれの項目を見れば、「こういう点に気をつければいいのか」と理解しやすいと考えています。また、最初のフロントエンドエンジニアを雇う際に、自分たちの弱点を把握し「こういうスキルや要件を持った人を雇おう」と考える一つの指針としても活用できると思います。
佐藤氏：実際に使ってみると、できているところもあれば、課題が多く見つかるチームもあると思います。その際に、課題を可視化することはもちろん重要ですが、現実的な課題の優先順位付けも大切です。たとえば、「この項目はこのシチュエーションなら外してもいい」といった具合に、どの項目を優先的に取り組むべきかの意思決定が必要になります。アセスメントシートを使った後に、こうした意思決定のフレームワークやワークショップなどに取り組んでいくのもよいと思います。
ーー最後に、7月開催のDeveloper eXperience Day 2024では、『Webフロントエンド版 DX Criteriaの誕生秘話とその活用法 〜 UXのためのDXプラクティス』と題してお二人と広木様のセッションが予定されています。今回のセッションのポイントなどについてお聞かせください。
古川氏：今回お話した内容も多少は含まれますが、今度の講演では実データを踏まえた具体的な話ができるかと思います。たとえば、今までに「Webフロントエンド版 DX Criteria」を使った企業が実際にどの程度活用できているのか、どのような点に課題があるのかといった具体例を交えた話があれば、より有意義になると考えています。また、広木さんにも参加していただけるので、オリジナルの「DX Criteria」を策定した際にどのように取り組んでいたか、どのような思いがあったのかといった視点も交えて対比していきたいです。
佐藤氏：Webというプラットフォームの中でも、エンドユーザーが触っている部分をつくるのがフロントエンドの領域なので、やはり私たちがよりよいチームにならなければ、ユーザー体験もよくなっていきません。今回策定した「Webフロントエンド版 DX Criteria」を活用し、そこで得た気づきを元に改善活動をすることで、フロントエンド領域を皆さんと一緒によくしていきたいと考えています。ぜひ今回の講演をご覧いただき、ともに議論を深めていきたいですね。
（取材／文／撮影：川島大雅）
