※本セッションのアーカイブ視聴はコチラからどうぞ

多くの企業がDX（Digital Transformation）を推進するなか、エンジニアの役割が重要性を増しています。本セッションのテーマは、“もうひとつのDX”である「Developer Experience（開発者体験）」。そもそも開発者体験が良い状態がどのような状態なのか、そして開発者体験を良くするためには何が必要なのか、議論を深めます。

ゲストは、プログラマーの視点から効率的な仕事の進め方を説いた著書『その仕事、全部やめてみよう』が話題の小野和俊氏（以下、敬称略）と、プログラミング言語・Rubyの開発者であり“Rubyのパパ”として知られるまつもとゆきひろ氏（以下、敬称略）。開発者を志す​きっかけとなった原体験についてもうかがいました。

ファシリテーターが気になるゲストのこと

牧野：
本セッションでは、2人のスペシャルゲストとともに、開発者体験（Developer Experience＝DX）についてお話をしていきます。

小野さんの著書『その仕事、全部やめてみよう』を読みまして、まさに CX・EX・DXの話が盛り込まれていて非常に参考になりました。あの本のなかでいちばん強調したい見どころはどういったところでしょうか？

小野：
開発はもちろん普段の仕事も、基本にしてもっとも大事なのは“誰がどのようにうれしくなるのか”ということだと思うんです。しかし、ややもするとそれが見落とされた状態で進んでいくことがあります。DX（Digital Transformation）の推進が叫ばれるなかで、「DXによってCXやEXがどう良くなるのか」と問うた時に、その観点が抜け落ちていることがあるんですよね。そうではなく、そもそも仕事とは誰かに喜んでもらうためのものであると常に意識する。そのことをいろいろな角度から論じたところがポイントです。

牧野：
まつもとさんにも質問がありまして、昨今コロナの影響で世の中がいきなりリモート環境に放り投げられたような状態ですが、まつもとさんはもともとリモートをベースにお仕事をされていますよね。何か変化はありましたか？

まつもと：
私は1997年から島根県に住んでいて、シリコンバレーや東京などから距離を置いて日常生活を送っています。メインの活動はもともとネットベースなので、地方にいて困ることはほとんどありません。ただ実際は、毎週のように国内外に出張していたんですね。コロナという外圧によって、物理的に移動して直接会って話さないといけなかった仕事がリモートでできるようになって、すごく楽になりました。

病気が流行るのは良くないことですが、社会全体が強制的にリモート環境でできる状況になったというのは、数少ない良いところだったんじゃないかなと思います。

エンジニアと非エンジニアを結びつけることのおもしろさ

牧野：
お二人は基本的にDeveloper Experienceを常に考えて仕事をされていると思いますが、普段開発をされているなかでいちばん大事にしていることは何でしょうか？

小野：
僕がプログラミングに出会ったのは、小学校4年生の頃でした。2つ上の先輩の家に遊びに行った時に、その先輩がプログラミングをして画面を動かしていたのが衝撃的な体験だったんですね。それで自分も始めたのですが、その頃はプログラマーがこれから必要とされるような風潮は全然なくて、どちらかというとマイナーなことをやっている変な人みたいな感じだったと思います。

でも、プログラミングに心が惹かれてしょうがなかった。四六時中そのことばかり考えていたいと思えるものが見つかった時から、没頭する自分の気持ちを突き詰めていくほうがいいと思って生きてきたんです。

そういう意味で大事にしていることは、まさに“Experience”で、自分がいちばん没頭していることに対していちばん時間を使うことは最高のExperienceなんですね。たとえ役に立たなくても、いちばん心惹かれるものにできるだけ時間を多く使うことを重視してやってきました。

牧野：
いま没頭しているのはどんなことですか？

小野：
事業会社で働くなかで、エンジニアとそのほかの人たちを結びつけることに没頭しています。というのは、クレディセゾンはもともと金融の会社で、エンジニアはいなかったんです。そこに、ベンチャーやSIからエンジニアが新たに入ってきて、総合職のプロパー社員と混ざり合っているのがおもしろくてしょうがないんです。

当然、いろいろな前提や常識が違う部分はありますが、いかにみんなが気持ちよくスムーズに仕事ができるかを考えるのがおもしろい。そういう意味で、Developer ExperienceやEmployee Experience がどうしたらもっと良いかたちになるかを日々考えています。

違う者同士がくっつくこうとすると、その瞬間に対立が生まれます。でもうまくいけば、お互いの領域がレーダーチャートで重なるように、お互いの強さが合体した多様性に富んだ組織になるので、すごくダイナミックでおもしろいと思います。

Rubyの開発において実現したいDeveloper Experienceとは？

まつもと：
私自身はプログラミング言語にハマっていて、高校生の頃からプログラミング言語をつくりたいと思っていました。最初に使った言語はBASICで、いま手に入る環境に比べるとものすごく乏しい環境だったんです。そのフラストレーションを解決したくて、プログラミング言語にのめり込んでいきました。

プログラミング言語をつくりたいと思っても、当時は情報を手に入れられる人が非常に限定されていました。コンピューターサイエンスに関する本は高校生にはちょっと難しくて、つくりたいという想いとフラストレーションはあるのに、実際にプログラムする環境もほとんどなかったんです。その後、大学でコンピューターサイエンスを勉強して、就職してプログラミングのスキルをつけて、それからRubyの開発を始めました。

結局、自分が使いやすいものがほしいという想いが原点にあります。自分にとってベストなDeveloper Experienceが何なのかを模索してきた感じというか。ただ、何が良いDeveloper Experienceなのかは未定義で、唯一の解はないんです。自分が実現したいDeveloper Experienceを探究することが大事で、それこそがRubyの使い勝手やテイスト、ファンの人たちが引きつけられる要素になっていると思います。

未定義のなかを探してどんどん未定義の領域を広げていく活動にいちばん時間を使っているので、実際に皆さんにRubyを使っていただく時に、良いフィーリングでプログラムができるためにはどうしたらいいのか、どんなエクスペリエンスを提供したらいいのかを定義することが必要だと思っています。ですから、エクスペリエンスを定義することが、私の日常生活とRubyの開発においてもっとも大事です。

Developer Experienceが良い状態とはどういうことか

牧野：
Developer Experienceに踏み込んで考えていくと、開発者体験という意味でのDXが良い状態というのはどういうことなのでしょうか？

まつもと：
Rubyの場合は、RubyそのものがDeveloper Experienceを提供しています。きちんと言語化はされていませんが、“Rubyを使うと気分が良い”という状態を目指しているんですね。それが何によって実現されているかというと、自分が表現したいものと表現しなければならないもの、そのギャップが少ないことが大事だと思っています。

プログラミングはコンピューターとインタラクションしないとできません。伝えたいことは当然あるわけですが、自分が表現するものは最低限で済ませて、あとはコンピューターにやってほしいわけです。そのあたりのバランスが、Developer Experienceではないかと思います。

小野：
僕の場合、Developer Experienceにおいて大事なのは、自分の価値が正しく理解されていることを、開発者ひとり一人が感じられることだと思います。さっきご紹介いただいた本のなかで、「エンジニア風林火山」という内容を書いたんですが、エンジニアにはいろいろなタイプの人がいます。

僕は、コード書くのがものすごく速い人を「風のプログラマー」、何かトラブルが起きた時に平穏さをチームにもたらしてくれる人を「林のプログラマー」と呼んでいます。さらには、最新テクノロジーに詳しくて新しいことをどんどん取り入れて行こうとする人を「火のプログラマー」、守りが得意でクオリティを担保してくれる人を“山のプログラマー”と呼んでいます。

なかでも、風のプログラマーや火のプログラマーは目立ちやすいんですよね。その分、林のプログラマーや山のプログラマーは、自分で目立たないと思っていることがあります。でもそれぞれの強みはかけがえのない価値といえます。それをちゃんとわかってもらえている、かけがえないものだと評価してもらえている、上司からも同僚からも理解されているというチームの環境こそ大事なんじゃないかと思っています。

そのためには、自分がどの領域で強みを持っているのかを意識して伸ばしながら、チームのなかで自分はこれにいちばん詳しいという誇りを持ってやっていく。もしかしたら自分ではその強みを自覚していなくても、周りの人がそれを強みだと言って引き出してくれて気づく場合もあるかもしれません。そういう自分の強みを明確にしていくこと、そして周りがその多様な価値を認めることが大事だと思います。

ベクトルの消し合いは良いDeveloper Experienceの足枷になる

まつもと：
先ほどはRubyが提供する体験という軸で話しましたが、開発者の良い体験において人間関係は重要な側面があります。特にソフトウェア開発は、いろいろなところで対立構造が起きやすいんです。お客様と開発、営業と開発、経営者と従業員のように、利害が対立しやすくて、対立するとベクトルが消し合ってしまいます。目指すべきゴールと提供すべきバリューが明確で、ムダな対立やストレスがないことは、開発者の良い体験にとって非常に重要なんじゃないかと思います。

小野：
僕もまつもとさんがおっしゃることは大事だと思っていて、それは開発者の間でも起こり得ますよね。例えば我々のチームだと、ベンチャーから来た人たちと、SIやエンタープライズから来た人たちと、エンジニアでも全然違う種類の人たちがいるんです。そうするとやっぱり価値観が違って、それぞれが考える大事にすべきものとどうでもいいもののギャップがあるんですよね。そうすると、ベクトルをお互いに消し合うところに不毛な時間や労力を使ってしまいます。

我々のチームは「HRT（ハート）の原則」を絶対に守ろうと決めています。HRTとは、Humility（謙虚）、Respect（尊敬）、Trust（信頼)の頭文字を取ったもので、これらを欠く発言はやめようと。これはGoogleで実践されているもので、守られていればベクトルの消し合いは限りなくゼロに近づけられるんじゃないかと思っています。

エンジニアとしての価値を認めることが良いDeveloper Experienceにつながる

牧野：
最後に、どうすればDeveloper Experienceを良くできるかについてお話をしていきたいと思います。

小野：
我々のチームでは、「HRTの原則」を守ることのほかに、短所について言及するのは禁止というルールがあります。それぞれに価値観が違うので、短所ではないことが短所に見える場合があるんですよね。それをあえて指摘すると、だんだんお互いを攻撃しはじめてしまいます。レーダーチャートを書いた時に、ある人の長所が別の人の短所を補っていれば、チーム全体としては問題ないんです。

大前提として「HRTの原則」がありつつ、思ったことは自由に何でも発言できる心理的安全性が担保されていることも重要です。エンジニアとしての価値がちゃんと認められて、どんなことでも心地よく発言できて、攻撃されることがない環境が大事だと思います。そういう環境であれば、ちょっとした改善の気づきを言いやすいですよね。

ちなみにもうひとつの原則は、成果に対して忠実でいようということです。Developer Experienceが高い状態で仕事をしていても、何かしらのアウトプットがなければ意味がないので。

“誰が”発言したかよりも“何を”発言したか。開発者のエゴは捨てよう

まつもと：
良いDeveloper Experienceを実現するポイントのひとつは、ゴールが明確であることだと思います。同じ方向を向いているからこそお互いにコミュニケーションができるという話がありましたが、良いバリューを提供することを明確に見据えることが必要かなと思います。

もうひとつは、誰が発言したかを極力重視しないこと。オープンソースコミュニティの場合、世界中から自発的に参加する人たちばかりですが、誰が発言したかよりも何を発言したかを重視したいので、Rubyのコミュニティにおいては、上に下にも差別がないことは重要なポイントです。

そしてもうひとつは、開発者としてのエゴを重視しないこと。なぜなら、自分の書いたコードが尊重されたり、すばらしいプログラマーだと褒められたりすることは重要ではなく、最終的に良いプロダクトを世に出すことが大事だからです。

牧野：
ものをつくる時に“この機能は自分のもの”と考えていると、良いものから離れてしまうことがある気がします。それが提供されることによってどんな価値がもたらされるのか、もっと大きなところに基準を持つことが良いものづくりにつながると思います。

小野：
当事者意識はコードにも意見にも持つべきである反面、それによって生じるエゴは持たないようにするということですよね。一見相反するけれど矛盾はしなくて、両方とも大事だと思います。

まつもと：
自分が関わったという気持ちや名誉は大事なので残したいのですが、コードに対する所有権に関しては、実は重要なものではないんです。

エンジニアが能力を最大限に発揮できる開発者環境とは？

牧野：
今回のセッションでは、エンジニアが能力を発揮できるDeveloper Experienceがどのようなものかをお話ししてきました。最後にそれぞれひとことずつコメントをいただけますか。

小野：
良いDeveloper Experienceにとって、当事者意識は持ってもエゴは持たない、“誰が”ということを意識しない、フラットにゴールを目指していくことがポイントだと感じました。そのために、開発者の価値を認める場所をつくることを今後も進めていきたいと思いました。

まつもと：
目指すべきゴールが明確に定義されているかどうかは重要なポイントです。そして枠組みが決まっていると、開発者はそのなかで取り組みがしやすいんじゃないかと思います。なので、プロダクトオーナーやプロジェクトマネージャーのような人たちの果たすべき役割は大きいと思います。そういう人たちがいるからこそ開発者が良いチームをつくることができるし、心理的安全性を保ってのびのびと開発ができるのではないでしょうか。

牧野：
開発者をはじめ、関係者がみんな同じ方向を向いてフラットにものごとに取り組み、良いものをつくって、その価値を最大化しようと考えていくことがポイントですね。そして、自分が没頭するようにものづくりをする、自分の経験をもとに価値をはかり、それを指針として開発に取り組むことが重要だと感じました。