「その改善、意味あるの？」に大きな価値がある。Webフロントエンド版DX Criteriaの生かし方

2024年2月、日本CTO協会は、フロントエンド開発に携わるチームのためのアセスメントツール「Webフロントエンド版DX Criteria」を公開しました。

これは、「Webフロントエンド」の観点から、開発者体験の向上につながる項目をまとめたもので、各項目に点数をつけることで、組織の現状をチェックすることができます。

起案者であり、策定にもかかわった古川陽介さんは、JSConfやNode学園の運営にも携わる、Webフロントエンドの第一人者です。彼は「Criteriaをつくった目的は、より高い点数を目指して改善行動をとってもらうことではない」と語ります。

では、開発者体験を向上し、チームをもっと良い状態にするために、このCriteriaをどう役立てるべきなのか？　古川さんにうかがいました。

• keyboard_arrow_down 「フロントエンドエンジニア」が生まれて約10年。ようやく知見を体系化できるようになった
• keyboard_arrow_down バックエンド、インフラ、デザイナー‥領域の重なる全員で話し合うことが、Criteriaを生かす第一歩
• keyboard_arrow_down 「改善したくても人がいない」でも議論に上った時点で、良い流れは始まっている
• keyboard_arrow_down 「点数のつけにくさ」など課題もある。Criteriaを使ってみて、改善要望を寄せてほしい

——そもそも、なぜ2024年のこのタイミングで、Webフロントエンド版DX Criteriaをつくることにしたのでしょうか？

古川：「フロントエンドエンジニア」という職種が確立されて約10年が経った今、様々なベストプラクティスやアンチパターンが明確になり、それらを網羅的に体系立てることができるようになったのではないか、と考えたからです。

フロントエンドのこれまでの歴史を振り返ると、2015年頃にパラダイムシフトがありました。当時、スマートフォンの利用が急速に広がる中でのJavaScriptの大幅アップデートを機に、インタラクティブなクライアントサイドアプリケーション開発が非常に容易になった。またこれと前後してReactやAngular、Vue.js、Next.jsが登場し、コンポーネント志向で開発するための道具立ても揃った。現在主流となっている開発スタイルの原型が形づくられたのがこの時期だったのです。

こうした技術や利用端末、通信環境などの急激な変化に対応する方法として、多くのフロントエンドエンジニアが有益な知見をコミュニティに還元し、それがベストプラクティスやアンチパターンとして定着していく流れがあります。しかしそれらはあくまでも各自の取り組みであり、体系的な指針とは一線を画します。

知見がある程度業界に蓄積されてきた今、それらを網羅的に体系立ててまとめることで、改めてフロントエンド開発のあるべき姿について考えることができるのではないか。そう考え、Webフロントエンド版DX Criteriaの策定に乗り出しました。

——この技術の変化の速さを鑑みると、今のCriteriaの内容が今後変わっていく可能性もあるのでしょうか？

古川：もちろんあります。今回の内容は、いわば今年のスナップショットにすぎません。時間が経つごとに、今回策定した内容の一部が時代に合わなくなっていくでしょう。その部分は差分で更新していきます。

ただ、Criteriaの大項目の1つである「効果的なシステム設計」については、まるごと差し替える可能性もあると思います。今までの歴史を振り返ると、デバイスが全く別のものになるレベルで革新的な変化が起きると、アプリケーションの設計にもパラダイムシフトが起きてきた。今、スマートフォンとPCをメインとしたデバイスで推奨されているコンポーネント志向の設計も、たとえばHMD（ヘッドマウントディスプレイ）が世の中に浸透するなど、デバイスに劇的な変化が起これば、大きく変わる可能性がある。

世の中の変化に応じて、Criteriaの内容も、少しずつ、あるいは大きく見直すことになるだろうと考えています。

——今回のCriteriaには、フロントエンドの技術回りだけでなくCI/CDやアーキテクチャ、デザイン、チームワークについての項目もあります。なぜ別の職種の領域も含めたのですか？

古川：フロントエンドを技術的に改善したり、良い状態を維持したりするために、これらの領域の要素が不可欠だからです。

改善のサイクルを素早く回し続けるにはCI/CDの整備が、パフォーマンスを向上するにはモジュール性や拡張性を考慮したアーキテクチャが必要。それに、より良いユーザーエクスペリエンスはデザイナーと一緒につくっていくもの。また、こうした動きを支えるチームビルディングも当然重要です。

バックエンドエンジニア、インフラエンジニア、デザイナーなどと重なり合う領域における連携を強化することで、フロントエンドの改善を進めやすくなる。Webフロントエンド版DX Criteriaの公開を知らせるプレスリリースに「フロントエンジニアのための」ではなく「プロダクトのユーザー体験と変化に適応するチームのための」としたのは、そんな主旨を込めたかったからでした。

——異なる職種の人とも一緒にWebフロントエンド版DX Criteriaを活用するには、どのように進めるのがよいでしょうか？

古川：私は「項目の意義について議論すること」が最も大切だと考えています。

Criteriaの各項目は何を意味しているのか。また、今のプロダクト開発でどの項目を重視すべきか。そして今の状態で各項目を採点するなら、何点をつけられそうか。デザイナーやバックエンドエンジニア、インフラエンジニアなどの関係者全員で議論し、認識を合わせていくのです。

話し合いを進めていくと、関係者全員の意見を集約した共通認識ができあがっていきます。項目の意味がわからない人がいたら惜しまず説明することで、関係者同士の知識レベルを近づけることができる。技術発信など賛否分かれる内容について互いの考えを共有することで、チームとしてどの項目に注力していくかを決める機会にもなるでしょう。また、鶏卵問題になりがちな難しい問題についても、学び考えるきっかけをつくることもできますし、CI/CDのパイプラインなどつい忘れがちなことにも気づけるはず。

Criteriaについての議論を重ねることで、関係者全員に、フロントエンドにまつわる知識を共有し、それぞれの意見を出し合って気づきを得て、チームとしての方針がまとまっていく。これが完了して初めて「点数を上げるための行動」に意義が生まれてくるのだと考えています。

そう思うと、Criteriaが最初に効果を発揮するのは「チームビルディング」である、ともいえるかもしれませんね。

——この議論は、聞いている限りかなり長期的な取り組みになりそうですが、どのように進めていくのがよいでしょうか？

古川：たしかに時間はかかります。だいたい1時間で中項目を1つ終えるくらいなので、Criteria全体の5つの中項目を議論しきるにはざっくり5時間程度かかると思います。チーム全体で丸1日使って話しきるイメージですね。

とはいえ、プロダクトの状況が変わるごとに、チームの方針も変わっていくはず。そのため半年から1年に1回くらいの頻度で、Criteriaについて話す1日を設けるのがよいのではないかと考えています。

——関係者同士での共通認識をつくって点数をつけたら、その点数をどう評価すべきでしょうか。100点といえる項目が少ないと落ち込んでしまいそうです。

古川：Criteriaにある5つの大項目には、それぞれに中項目が5つ用意されていて、中項目1つが20点満点となっています。

どの大項目も、100点をとるのは相当難しいです。50点以上であればかなり良い方。大項目で50点を下回る、つまり中項目に10点をとれていないものがあれば、何かしらのテコ入れはしたほうがいいかも、といったくらいに捉えてほしいです。

——点数が低い項目を改善すべきかどうかは、どんな観点をもって話し合うとよいでしょう？

古川：これはとても難しいポイントですね。

点数が低い項目を改善するかを議論するときは、まずその項目の意味をはっきりさせたうえで「プロダクトの特性を踏まえて改善が必要か」「チームはその改善ができる状態か」といった観点から、話し合って決めていくとよいのかなと思っています。

1つ目の、プロダクト特性の観点からは比較的判断しやすいはず。本当に難しいのは2つ目の観点です。改善したくてもそれができる人がいなかったり、それにコストをかける判断ができるフェーズではなかったりします。改善する必要がないからしない、ではなく、本当は改善したいけど今はできない、と判断するしかないシーンもあるでしょう。

古川：ただ、現場で「これは改善すべきだ」という意見が固まっていけば、その改善のために必要なスキルや工数を、多分どこかで獲得していけるだろうとも思います。個々人が必要な知識やスキルを能動的に習得していったり、採用方針や研修の内容など、チームよりももっと大きなスコープで物事を動かしていったりする流れが起きるかもしれない。

そしてそもそも、ここまで話してきた「チームでの議論を経て、何を改善すべきか決めること」ができていれば、チームとして相当高いレベルに到達していると言っていいと思います。議論の結果、色々な事情があるとわかり、改善すべきことに着手できなくても、チームの結束の強さには自信を持ってほしいですね。

——Criteriaを本来の意味で活用できなくなっている「危険信号」としては、どのような傾向に注意すべきでしょうか？

古川：手段と目的の逆転には常に気をつけてほしいと思います。具体的には「点数を上げるためにどうしたらいいか」と議論を始めたら、かなり危険かと。

Criteriaの点数を上げることが、プロダクトの改善に直ちに直結するわけではありません。あくまでCriteriaを使う目的は「プロダクトをよりよくすること」であるはず。ここに立ち返って、議論や施策を進めてほしいです。

——Criteriaについて、現時点で見えている課題があれば教えていただけますか？

古川：関係者全員で議論するのが大切だと話してきたものの、実際にやってみると盛り上げれば盛り上がるほど、1時間で答えられる設問数が限られてしまいます。チームの結束を高めるために必要な時間とはいえ、何度もスケジュールを合わせて集まらなければならないのは、小さな組織には負担があるかもしれません。

また、点数のつけ方が難しいとのフィードバックも届いています。たとえば「○○についてメトリクスをとり、それらを元に定期的に開発効率の改善を計画・実施しているか」という設問に対して「メトリクスはとっているけど、改善を計画・実行まではできていない」場合は、yesにチェックをつけるべきかnoにつけるべきか悩んでしまう。

ただ、数値を細かくつけられるようにすると、今度は点数をつけること自体も面倒になってしまいそうなので、いい塩梅で点数をつけやすくなるよう改善していこうと思っています。

——なるほど。古川さんは将来的にWebフロントエンド版DX Criteriaをどのような形で発展させたいとお考えですか？

古川：まずは偏りのない傾向が見出せるよう、様々な組織での点数のデータを集めることが先決です。その後は、いただいたご意見やご要望を踏まえ改善を重ね、簡易版の作成、データの自動集計やスプレッドシートからアプリケーションへの移行なども視野にアップデートしていくつもりです。できれば集計したデータの分析結果を公表できるような状況にしたいと思っています。

フロントエンド開発を取り巻く環境はこれからもどんどん変化していきます。われわれも開発現場で働くみなさんの実感に沿う形で改善を重ねるつもりなので、ぜひ挑戦してほしいし、フィードバックを寄せてもらえたら嬉しいですね。

取材・執筆：武田敏則（グレタケ）
構成・編集：光松瞳
撮影：曽川拓哉