DevEx（開発者体験）とは、機械のように単に生産性を最大化することではなく、開発者もまた人間なのだから人間としての体験を尊重するべきだ の考え方を指します。
定義にはいくつかの派閥があり、Microsoft などビジネスが得意な会社はタスクをこなす上での障壁の無さと考えます。私はこれは狭義だと思いますし、生産性の理から脱せてないので好ましいとも思っていません。
私はBeyond Productivity: Embracing Experiencityという記事を書きました。もっと広義に捉えています。
DevRel(Developer Relations) とは、開発者も顧客とみなして丁重に扱おう、良好な関係を築いていこうという考え方です。
元々は 外部的 でした。開発者をターゲットユーザーとした製品を開発する企業が、自社製品を末永く使ってもらい、また広めてもらうために、ユーザーと仲良くするのです。ユーザーは開発者ですから、開発者の価値観に寄り添うのがポイントです。一般ユーザーよりも情報発信と参加型イベントの比重が重くなります。ですので、まさにそのあたりを専任して行うエバンジェリストやアドボケイトが重宝します。
近年は 内部的 な DevRel も合流しています。Platform Engineering がまさに当てはまりますが、社内の開発者を顧客とみなして、丁重に寄り添っていこうと考えます。結局のところ、会社を支えるのはエンジニア達であり、エンジニア達が一番大切ですから、もっと寄り添おうというわけです。たとえば社内のエンジニアが使う API プラットフォームは、社内エンジニアという顧客を相手にしたビジネスだとみなせるわけです。
私は DevEx と DevRel が合流し始めていると感じます。つまり 内部的な DevRel として DevEx の向上を目指す のです。言葉がないと不便なので、これを DevRelEx と呼ばせてください。
もっとも、こんな小難しい言い方をしなくても、すでにエンジニアリングマネージャーはチームのために尽くしています。ですが属人性が高いものでした。
私はこのような「もったいない」現状を変えたくて、またスケールさせたくてソフトスキル・エンジニアリングをつくりました。DevEx と DevRel はテクニカルな側面だけでは足りません。もう一つ、ソフトスキルが重要なのです。特にその個人そのチームその組織に合った、きめ細かい実装と運用が必要になります。これはエンジニアリングの素養を持つプロフェッショナルでないとできないのです。
さて、ソフトスキル・エンジニアとして活動する私は、DevRelEx に役立つ概念をつくりました。ご紹介します。
機能としてのマネージャー（Manager As A Function） とは、マネージャーを機能とみなすことです。メンバーは機能を使うようにマネージャーを使います。MaaF と略します。
従来はマネージャーが上位者が、半ば一方的に管理を行っていたと思います。優れたマネージャーは傾聴や関係構築が得意ですが、それでも上位という立場に変わりはありません。
MaaF では逆に、DevRel らしくメンバーを丁重に扱います。メンバーのニーズを優先します。そのためにマネージャー自身は機能となって、どうぞ私をご自由にお使いください、とします。
MaaF は機能として、インターフェースを提供しなくてはなりません。
たとえば次のようなものがあります。
すでに使っている組織も多いかと思いますが、マネージャーの予定表の空きに、誰でも自由に予定を追加できるようにすることです。
マネージャー側は、もし追加された予定に問題がある場合は拒否します。そうではない場合はデフォルトで承認します。
Ask Me Anything と Request Me Anything です。会議の形でも行えますし、非同期でも行えます。
詳細は以下を見てください:
主に大学で教員が学生向けに使うもので、「この時間帯は開放していますのでいつでも誰でも遊びに来てください、何でもお答えしますよ」というものです。
造語ですので少し詳しく解説します。
マネージャーチケット とは、「1時間で対応できる範囲で検討と回答を行う」というチケットのことです。検討と回答は非同期的に行い、回答としてはメッセージや文書やプロトタイプを書きます。マネージャーは、このチケットを必要に応じて配ります。メンバー側からチケットを提示されたら、1h を使って調査や回答をします。
マネージャーチケットの良い点は次のとおり
MaaF だからといって、四六時中受け付けるわけにもいきません。マネージャーにも色々仕事があります。ですので、MaaF としてのリクエストを受け付けないメンテナンス期間は それなりに 設ける必要があります。
典型的には、マネージャーの時間の使い方は以下 3 種類に分かれるでしょう。
私のおすすめは、メンテナンス期間は最低限でも半日のスパンで取ることです。日単位で取れるともっと良いです。普段の打ち合わせと MaaF に応えるだけでは確実に病んでしまうので、主体的になるための孤独な時間が必要なのです。
背景として DevRelEx が来ている話をしました。
次に DevRelEx として使える道具を一つ紹介しました。機能としてのマネージャーです。そのために使えるインターフェース（窓口）の案も 5 つ整理しました。
現代は VUCA であり、DEIB であり、生成 AI の時代でもあります。変化が激しい上に正解がわからず、従業員側の水準も高くなっているという厳しい時代です。だからこそ DevRelEx の視座が求められるように思います。皆さんもぜひ意識してみてください。また MaaF を使ってみてください。それではまた。