ブルームテクノロジー

テクノロジー

開発者体験向上についての考察と取り組み

開発者体験向上についての考察と取り組み

システム統括課 ブログ担当 亀井です。

12月も半ばとなり、東京も非常に冷え込むようになりました!
(地元では既に雪が降ったそうです……)

私は現在入社6年目で、インテグレーション事業部という部門でいわゆるEMのロールを担当しています。普段はガシガシとコードを書いたりする訳ではなく、プロジェクト進行の指揮を担ったりする裏方のメンバーです。
前職からマネジメントをしていたということでもなければ、マネジメントの専任としてブルームテクノロジーに入社したわけでもない(元々はWEB開発担当のエンジニアとして入社しました)ので、私にとっては初めての経験を積ませて頂いていますし、まだまだ見習いの身で勉強漬けの毎日です……。

さて、今後もエンジニアチームである我々はQCDバランスを保ちつつも、その全ての質を向上させながらPoCとローンチの小さなサイクルを繰り返していく必要があります。創業期ともいえる今、経営判断に素早くフィットすべく回転速度をあげる必要性は高く、チームの生産性向上は必須の課題となっています。

本記事では私がチームの生産性向上を課題にするにあたり、学び実践する上で感じた「開発者体験(Developer Experience)」の重要性と、取り組むべきことの考察を備忘録としていくつかまとめてみようと思います。同じようにこれからチームの生産性を上げたいという方や、マネージャーとの意思疎通を円滑にしたい方にとって、少しでも参考になれば幸いです。

開発者体験とは何か?

開発者体験とは「開発者が経験する開発業務における体験」のことであり、組織における開発プロセス・文化・製品管理・人材管理といったものが含まれます。開発者体験は、開発チームが高速かつ高精度の仮説検証を行うために必要な構成要素のひとつと言えます。延いては生産性に影響をもたらす事象の一つであり、良いソフトウェアエンジニアリングを行うにあたり避けては通ることのできない過程だと考えています。
参考:Developer Velocity: How software excellence fuels business performance

以下のような経験は無いでしょうか?

  • 技術的負債が蓄積していて、改修コストが異常に高い
  • ドキュメントがなく、レポートラインも不明瞭
  • 環境がレガシーであり運用コストが常に高い
  • 常に緊張感があり失敗が許されない

どんなに優秀なエンジニアだったとしても、これらが絶えず発生する現場で満足のいくパフォーマンスを出すことのできる人間は限られてくることでしょう。

開発者体験を向上させる為に

ではそれらを一つでも多く解消し、生産性を上げるためには何をすればいいのでしょうか。ここでは「私(個人)の生産性」ではなく「私たち(チーム)の生産性」を上げることを目標とします。

これには千差万別の答えがあると思いますが、私は「生産性」という抽象的な概念を具体化するために開発者体験の定義が役に立つと考えます。開発者体験が含有する構成要素は「文化」「開発プロセス」「製品管理」「人材管理」といったものです。これらの課題を潰し改善することで着実に開発者体験は向上していくと捉え、私たちエンジニアチームはまず最も重要な文化の醸成から着手することにしました。

取り組みの例を一部紹介いたします。

まずは、Googleの有名な方法論である「Fail Fast」の実行です。
チャレンジと、チャレンジに伴う失敗を恐れて実行できない組織はあらゆる判断が遅くなるだけではなく、心理的安全性という観点でも良好とは言えません。まして取り返しのつかない状況になるまで失敗を言い出せないなんてことがあれば、それはソフトウェアエンジニアリングの上で最悪だと言えます。

Fail Fastは直訳すれば「さっさと失敗しろ」です。少し言い換えると「上手に失敗しなさい」になるかも知れません。有名な話ですが、Googleでは失敗した時にベルを鳴らしてお祝いする、なんて文化があったそうです。もはや「失敗おめでとう」な考え方から学ぶオープンマインド。流石にベルを鳴らすまではいかないですが、私たちもFail Fastを踏襲したチャレンジングなチームになるべきだと考え、みんなでこれを実行してみようとなりました。

次に「Give First」の実行です。
ここには互いに共助精神を持つことの根付きを推奨する意図があります。そもそもエンジニアの文化は共助によって作り上げられたことが多くあり、OSSなどその最たるものです。身近な例で言えばQiitaやZenn、noteや個人ブログでのアウトプットにも同じことが言えます。これらは個々人の営業やキャリア影響というメリットの側面も当然ありますが、これらのプラットフォームを支えるユーザの多くは「自分が困ったことは誰かも困っている」のもと共助精神から情報共有を行っている筈です。

私たちも共助精神を持つことを推奨し、Give&Takeではなく自分から貢献する「Give First」の精神を大切にしていくことで助け合いながら良いものを作り上げるチームになりたいと考え、これも実行してみることにしました。

こんなチャットでのやりとりもあって、技術共有も活発に行われています👍
(re:Inventにあわせて活発になるチャット、良いですよね)

「私たちはどんなチームか?」というアイデンティティに関する問いへ迷いなく答えられるようになることはコンピテンシー基準の明確化であり、良いと思った取り組みを自信をもってチャレンジできるようになることは、開発プロセスの向上速度も加速させると考えています。

文化形成が、次の開発者体験ステップの足がかりになってくれることを期待しつつ、これらがどれほどの生産性影響をもたらすかはまた半年後に測定していきたいと思います。

>>エンジニア採用情報<<