感染症拡大や環境問題など、経済・社会を取り巻く不確実性は高まり、変化を前提とした「ニューノーマル」を見据え、デジタルトランスフォーメーション（以下、DX）に取り組む企業が増えています。

こうした中で、サービス、プロダクトを安全、スピーディにリリースするために、組織文化に着目した「開発者体験」という“古くて新しい”テーマが見直されています。
そんな「開発者体験」をテーマに、ソーシャル経済メディア「NewsPicks」などを手がける株式会社ユーザベース（以下、ユーザベース）との共催イベント「Qiita × Uzabase Tech Meetup#2」をオンラインで開催しました。

「チームで追求する最高の開発者体験」と題した本イベントでは、ゲストにエンジニアリング組織に知見のある広木大地氏を招き、開発者体験向上の方法・ノウハウをユーザベース社での取り組み内容などと合わせて、講演・パネルディスカッションを行いました。今回はその当日の模様をダイジェストでお伝えします。

▼第1回のイベントレポートはこちら
変化の激しい時代にあって再注目されるTDDの重要性。「Qiita × Uzabase Tech Meetup#１」イベントレポート

イベントアーカイブ動画を見る

プロフィール

広木大地氏 ゲスト講演「DXとは何か？」

「Tech Meetup #2 チームで追求する最高の開発者体験」は、株式会社レクター 取締役の広木大地氏による、「DXとは何か？」をテーマにした講演から開始されました。

最近、DXってよく聞くけど、何ですか？

DX（デジタルトランスフォーメーション）とは、2004年にエリック・ストルターマン教授によって提唱された概念で、「ITの浸透が、人々の生活をあらゆる面でよりよい方向に変化させる」と定義されます。例えば、社会の取引コストの変化に適応して、業態を変化させることもDXであり、その際にデジタルツインやデジタルコイン、契約のデジタル化、デジタル署名といったデジタル技術を、単なる仮想的な役割ではなく「社会の実体の1つとして扱うこと」がDXには求められてきます。このような社会が変化していく予測がDXという概念が登場した背景でした。

その後、かつて世界の時価総額で上位を占めた日本企業は、平成の30年間を経てランキングから消え去り、代わってGAFAMなどのIT技術を制した企業が並ぶようになりました。社会の変化は予測から実感に変わり、こうした社会環境の変化に応じて企業はどう生き残るべきか──、という問いが生まれます。これが「デジタル技術を活用し、企業が生き残るための戦略」としての「企業のDX」です。

こういった意味で「企業のDXにはデジタル技術を必ずしも使わなくてよい」とも述べます。「変化を捉え、自分たちを再定義することも企業のDXにおいては1つの答え」だからです。

「社会の変化を捉え、自分たちを再定義する答えを導き出す」。つまり、社会のDXという変化に対して、「企業のDX」とは単なる「問い」にすぎず、「答え」を自分たちで導く必要があるというのが本質だというのです。ところが、「問い」よりも先に「答え」について語られることが多いため、DXという言葉の定義や意味合いがわかりづらくなっているのだろうと論じました。

社会の不確実性は高まっている

一方で、コロナ以前から、社会情勢の変化により、不確実で変化し続ける社会を前提とした新しい戦略の考え方が重要になってきました。「ニューノーマル」に向け、組織文化に注目したメタ戦略の重要性が改めて認識されています。「予測が難しいなら、変化の兆しを捉えて即応すればよい」からです。

これが、変化に対応して自己を変革する能力＝「ダイナミックケイパビリティ」です。これまでの組織能力（オーディナリーケイパビリティ）と比較すると「企業の能力に求められる要素は『技能的効率性』から『顧客ニーズとの一致』へ、『買う』から『学習する』へ、そして、『ベスト・プラクティス』から『企業固有の文化・遺産』へと変わってきている」ということです。

「企業が新しいデジタル技術を活用する継続的なプロセス」をDXとするなら、ソフトウェアの開発文化資本にもダイナミックケイパビリティが求められているはずだ──、広木氏はこう述べます。

企業の「DX」と「開発者体験（Developer eXperience：DX）」は両輪

企業がDXを実現するためのダイナミックケイパビリティと、ソフトウェアの開発文化におけるダイナミックケイパビリティは密接に結びついています。特に、後者は「開発者体験（Developer eXperience：DX）」と呼ばれ、開発者が高速に仮説検証に取り組める文化・組織・システムを整備していくことです。

どちらも「DX」と省略される2つのDXは、実は車輪の両輪であると広木氏は強調します。

では、開発者体験の文化資本が蓄積しやすい企業とそうでない企業にはどんな差があるでしょうか。

「習慣行動の獲得が当たり前にできる会社と、説明コストがかかる会社とでは、後者では説明が面倒だからと自己変革が阻害される可能性がある」といいます。

そもそも、よい習慣は合理的に説明できるわけではありません。例えば、かつて「ユニットテストを書いた方がコストはかかるが、書くべきか」という議論がありました。今ではユニットテストを書くことが常識になり、体感的なメリットも理解されているものの、かつてはユニットテストに意味があることを説明する必要があったのです。

つまり、「リソース効率」や「オペレーション効率」を重視するオーディナリティケイパビリティを選好する組織文化では、高速にトライアルアンドエラーできる組織文化が定着しにくいというのです。

これを打破するためには、「形から」入ることにも価値があるということです。「多くの習慣的行動は、形だけまねてもすぐには意味がないが、目的を持ってやり続ければ、習熟し、高いレベルになる」からです。

DXには高速にトライアルアンドエラーできる組織文化が必要

毎週、数千回、数万回のテストやデプロイを実現する世界に対し、自動化されていないシステムは、半年に1度、手動のテストとリリース作業に追われます。開発者体験にフォーカスし、手元で修正したコードが、リアルタイムで自動テストが行われ、問題がなければ本番に出すことができる環境に改善していくのです。

さらに、よい組織には、よい文化資本を持つ人材が集まります。

文化資本は何らかの習慣行動の違いとなって、観測可能になり、やがてオープンな開発者のコミュニティを通じて、社外の開発者に伝わり、その結果、同様の習慣を持つ人が惹かれあい、集まるからだ──、広木氏はこう述べ、セッションを締めくくりました。

石井幸次氏　技術講演①「ビジネス中心に7年間走り続けたAndroidをリアーキしている話」

続いての講演は、ニューズピックスでEngineerを務める石井幸次氏による「ビジネス中心に7年間走り続けたAndroidをリアーキしてる話」です。

石井氏は法人向けNewsPicksで開発リーダーを務めます。そんな石井氏が組織の立場を超え、Androidのリアーキ（リアーキテクチャ）を行った経緯はどのようなものだったのでしょうか。

リアーキの背景

石井氏によると、ユーザベースグループには次のような7つのバリュー（「The 7 Values」）があるとのこと。

Androidチームは、優秀なエンジニアで構成され、技術力がないとできないUIやスピーディなリリースを行っていたものの、優秀な業務委託のエンジニアに「正直いうとここ10年で一番ひどいコード」「少し触るだけでバグが出る」と言わしめる状況でした。

具体的な問題点には「巨大な1つのモジュール、ルールベースでレイヤーが構成されている」「単体テストがほぼない」「属人性のあるコード」「ライブラリなどのバージョンを気軽に上げられない。上げると思わぬクラッシュ」といった問題がありました。

その理由として石井氏は「ビジネス優先で走り続けてきた」結果、「何度かリニューアルやアーキテクチャ変更はしたが、抜本的な変更をする時間、体制が取れなかった」点を挙げます。

こうした時代や組織、事業フェーズの変化によって適さなくなった技術的負債を目の当たりにして石井氏は、「この状態で何年も実装していくのはモチベーションが上がらない」「（Androidアプリの）法人機能はスマホ経験値が少ない開発者でも実装できるようにしたい」という思いを抱いたそうです。

どのようにリアーキを進めたのか

法人向け機能は「スケジュール厳守で、かつビジネス目標（獲得確率向上）厳守」という制約がある中、Androidチームも他の実装を進めており、誰も頼れない状況で、アーキテクチャの統一をどのように進めたのでしょう。

石井氏は「1人でもやりきってやるという意志」と「これまでの経験・自信」しかなかったと振り返ります。リスクを最小化するため、年末休暇とロンバケ制度（長期休暇制度）を活用し「迷ったら挑戦する道を選ぶ」というバリューに従って行動を開始しました。

具体的には、Androidチームに「法人の新機能で新アーキテクチャを使いたい」と宣言し、2週間くらいで実践で使えるレベルのサンプル実装を作成。Androidチームに合意を得て、法人チームでは他のメンバーにリーダー業務やiOS開発を委譲し、孤独の中で法人機能の実装を開始しました。

しかし、開発を進めてみると、想像していた以上に既存コードの影響を受けるので回避するための実装が必要で開発量がとんでもなく多いことがわかってきました。

こうした状況で仲間が手を差し伸べてくれました。「『The 7 Values』にある通り、Androidチーム社員が渦中の友を助けてくれた」と石井氏は振り返ります。

今後の展望

法人機能をスケジュールどおりリリースした結果、NewsPicksの経験がない外部委託の開発者でも問題なく実装できるようになり、法人機能以外も新アーキテクチャに移行することが決定したそうです。

石井氏は「Androidチームが負債解消前の2人から5人体制になり、採用時に優秀な人を採用しやすくなった」とリアーキの効果を述べます。

今後は、iOSも含めて新アーキテクチャへの移行を進め、「テストを必須にし、進化し続けるアーキテクチャをめざす」とのことです。また、仕事に使う時間の20％を将来のプロジェクトの探索也取り組みに使う「20％ルール」をつくり、NewsPicksで技術的ブランドを確立したいとのこと。

石井氏は、意志があればシステム改善は絶対できるとした上で、意志を実現するためには「組織の文化」は大事だと述べました。他部署の自分がAndroidのリアーキを実現できたのは「自由主義でいこう」という文化があったおかげだ──、石井氏はこのようにセッションを締めくくりました。

大場吾郎氏　技術講演②「デザイナー×フロントエンジニアで追求する最高の開発者体験」

3つ目の講演は、アルファドライブのNewsPicks Enterprise（法人向けサービス）でEngineerを務める大場吾郎氏による技術講演②「デザイナー×フロントエンジニアで追求する最高の開発者体験」です。

大場氏は2020年3月にユーザベースグループのAlphaDriveにジョインしました。新規事業開発特化型の総合支援ツール「Incubation Suite」や、「NewsPicks Enterprise」などの開発を手がけており、デザイナーと連携し、フロント開発に携わることが多いとのこと。

よくあるフロント開発の課題

大場氏は、よくあるフロント開発の課題として「リリースしている製品とデザイン、乖離が発生する」問題を挙げました。

デザイナーがエンジニアにデザインを渡し、エンジニアが開発してリリースを行う過程で確認、修正の依頼やデザインの修正、追加の確認依頼といった往復が発生します。

また、エンジニアがデザインどおり開発できなくて不具合が発生したときにはデザイナーがリリース前チェックを行ったり、ビジネスサイドがデザインに対して指摘を入れ、修正したりすることもあり、「デザイナー、エンジニア間のやり取りが多くなる」「デザイン設計どおりに実装されないことがある」「デザインチェックを挟むことになる」「フロントは修正されるけどデザインが変更されないで陳腐化することがある」といった問題につながっていました。

こうした問題は「デザイナーとエンジニアに距離があることや共通認識がなく、デザインガイドラインもないことにより発生しがちだ」と大場氏は話します。

そこで、不要なコミュニケーションをなくし、二度手間をなるべく発生させない、チーム内で共通認識・言語を持つようにする、デザインが更新されないで陳腐化されることを防ぐといった世界をめざしました。

デザイン設計とフロント開発をもっとシームレスに

大場氏は、実際の取り組みでのポイントを紹介しました。

そのポイントとは、「デザイナーとエンジニアの距離を近くする」ことです。
お互いのやることを共有し、効率のよい作業の仕方について議論がしやすい環境を作りました。また、デザインガイドラインを整備しておき、フロントエンジニアも修正できるように編集権限を持っておくことで、「デザイナーのデザインツールを知り、デザインガイドラインを整備しておけば、細かい修正はエンジニアができるようになるため効率的だ」というのです。

他にも、ブラウザ上で簡単にデザインができるFigma（フィグマ）上でも、コードでも、パーツ・コンポーネント単位で定義していくAtomic Design（アトミックデザイン） を採用することや、デザインの段階でコンポーネント名称を設計しておくこともポイントに挙げられました。これにより、コード側でコンポーネント名を考えなくてよくなり、Figma側で考えた名称がコードで変更されるといったことも防げる効果があります。

今後について

さらなる開発者体験の向上をめざし、「デザインとフロントコードの連携」を検討しているとのことです。
例えばデザインからコードを出力するツールとして、Figmaからコードを出力できる「overlay」というツールや、Figmaのプラグインを活用することで、「フロントエンジニアはコンポーネントやカラーを気にせずロジックだけ書けばよくなる」と述べます。

そして、デザイン設計を元とした開発成果物のデザインチェックや、デザイン設計を元にテストできる未来が到来するだろうと述べ、セッションを締めくくりました。

高山温氏　技術講演③「開発者体験エンジニアリングの楽しみ方」

4つ目の講演は、ニューズピックス CTOの高山 温氏による技術講演③「開発者体験エンジニアリングの楽しみ方」です。

開発者体験はすべての会社が取り組むべき普遍的テーマ

CTOは「会社の長期的な競争力を支える技術方針を定めるのが役割」だとした上で、開発者体験を1つのキーワードとして取り組んできたと言います。

高山氏が参考にしたのが『LeanとDevOpsの科学』という書籍です。同書は、ソフトウェア企業の開発スタイルと市場占有率や収益性との関係を科学的に証明していく試みが紹介され、より高速かつ安全に仮説検証できる組織は、市場占有率や収益率でもハイパフォーマンスを示していることが記されています。

高速とは「開発に迷わない、待たない、無駄なコミュニケーションが発生しない」ことであり、安全とは「意識しなくてもセキュリティが保たれ大きな障害にならず、心理的な安全が保たれている」ことです。

その意味で、開発者体験は「古くて新しいテーマ」であり、最近になってビジネス競争力に直結することがわかったということです。

時代に合わせた普通の改善活動が必要

NewsPicksは、ビジネスを立ち上げた初期は、エンジニアは少数精鋭で、良くも悪くも「力技」がまかり通る開発文化でした。しかし、ビジネス拡大に伴い、開発者は50人を超えても、「力技」の文化はそのままになっていました。

そこで、2020年から開発者体験を重点技術領域にして地道に改善を行いました。具体的には、デプロイの負担を減らし、手動オペレーションを減らす、自動テストの強化やセキュリティ監査の強化といったことです。

高山氏は、開発者体験エンジニアリングはCTOという役職を抜きにしてエンジニアとして楽しいと述べます。その理由は次のようなものです。

・サーバーサイド、クライアントサイド、様々なレイヤーでボトルネックが変わり続ける
・純粋な技術的課題が多い
・お客様が開発者、気持ちが手に取るようにわかる
・ビジネス競争力に直結している

開発者体験エンジニアリング事例

では、具体的にどんな取り組みを行ったのでしょうか。1つ目は、主にC言語のソースコードに対し、コンパイラよりも詳細かつ厳密なチェックを行う「Lint」の使用です。

社内には「好みの問題」レベルのコードの書き方でレビューが白熱していました。コーディング規約にコードの書き方を追加しようという意見が出る中で、高山氏は「規約に追加するなら必ずツールで自動チェックできるものだけ」にしようと決めました。

2つ目は「マージ即リリース」です。NewsPicksは、もともとは特別な権限がないとリリースできないシステムでした。正社員でないメンバーも開発するシステムだったため、権限がなくてもリリースに困らないようにすることを優先し、CI/CD（継続的インテグレーション/継続的デリバリー）を完備してリリース作業をゼロにしました。

そして、3つ目が「張り付き待機の廃止」です。毎日22時に動画番組の公開という運用があり、ミスが許されない作業だったため、エンジニアが張り付きで作業をする必要がありました。これを数ヵ月かけて徐々に手作業を廃止し、当番制も廃止にしました。

これらの取り組みによって、デプロイのためにSSH（Secure Shell）でコマンドを実行していた運用から、マージされたらbotが動き、Slack経由で自動でデプロイできるようになりました。また、cron実行中はデプロイすることができなかった状況も、「バイナリを上書きするのではなく、まず移動させてから新しいディレクトリにバイナリを設置」できるようになりました。

デプロイに困らない・開発環境で困らないNewsPicksへ

今後について、高山氏は「みんなが使うツールをみんなでよくする」「明日楽をするために今日がんばる」ことをチームで極限まで取り組んでいきたいと抱負を述べました。

そして、エンジニアが技術よりもユーザー価値を作る事に集中できるようにし、最高に開発しやすいNewsPicksを実現したいと述べ、セッションを締めくくりました。

パネルディスカッション・質問会

最後に、広木氏（モデレーター）と高山氏、林氏によるパネルディスカッションが展開されました。最初のディスカッションテーマは、「チームで追求する最高の開発者体験」をイベントテーマに設定した背景についてです。

【トークテーマ】「チームで追求する最高の開発者体験」をイベントテーマに設定した背景

高山氏は「みんなで使うツールをみんなでよくしていこう」という取り組みは組織文化としても大事だと述べました。開発者がいいところを持ち寄って1つのチームになるのが理想だということです。

林氏は、「NewsPicksはビジネス先行で、エンジニアはひたすら開発に追われている状態だった」と述べました。アジャイルといっているのに、週1回しかデプロイしていない状況を改善し、みんなが作ったサービスを早く届ける開発者体験の向上は、文化組織面からも追求したいテーマだということです。

林氏は高山氏と、エンジニアが開発に集中できる環境を整備しており、「これにより、開発者1人あたり、週1回のデプロイが可能になった」ということです。

開発者50人が週1回のデプロイを行うことで、1週間に50回のデプロイが可能になりました。これは高山氏が入社した頃に比べ、約2.5倍の改善だということです。

【トークテーマ】ユーザベースでのこれまでの取り組み

具体的に取り組んだのは『LeanとDevOpsの科学』の内容に沿って、デプロイ回数を計測し、回数を高めるための課題を挙げ、1個1個改善していくことです。

組織面では「SRE（Site Reliability Engineering）チーム」の立ち上げがあります。高山氏は「今までは各チーム内でクローズしていた開発者体験をキーワードに掲げた結果、ビジネス側のテックチームも、改善を求めやすい空気が醸成され、エンジニアリングの一体感が高まった」と話します。

林氏も、「SREの進化はビジネスサイドは気づきにくいが、テックチームは改善が進んで、リリースが早く、正確になっていることを体感している」と述べました。

【トークテーマ】開発者体験を改善した際に苦労した点・工夫した点

林氏がこだわったのは自動化です。スピーディなリリースを阻害しているのが「運用でエンジニアが忙殺される」ことだと林氏は述べます。運用に引っ張られて新しいエンジニアリングできない問題に対し、工数確保の取り組みとして自動化を取り入れていったのです。

ここで、広木氏から「トップレベルの意識改善でなく、ボトムアップで文化を変えるためのアプローチ」について質問された高山氏は、「エンジニアとして、自動テストを増やすなどの小さな改善を積み上げ、成功した体験がある」とし、「エンジニアがすぐにできることは意外とある」と答えました。

林氏も、組織の何かしらの課題に対して、「自由にやっていいよ、という空気があるならまずやってみるべきだ」と話しました。

広木氏は、技術負債の解消や開発者体験向上についてボトムアップで実現した経験から「テーマを掲げて仲間を募るやり方や、自分がボトムの立場なら、目の前のコードを変えてフルリクエストするやり方もある」と話しました。

何もしないで誰かがアクションするのを待つのではなく、「体験してもらい、事業サイドに『あのツールを使いたい』と思ってもらえるように提案をもっていく」巻き込む力もボトムアップに必要な要素だということです。

【トークテーマ】今後の注力したいこと・助けてほしいこと

今後について高山氏は、ユーザベースには「異能は才能」というバリューがあり、「様々な個性やスキル、多様性を持ち寄ってサービスを作りたい」と述べ、文化に共感していただける人にジョインしてもらいたいと話しました。

林氏は、「テクノロジーの力で、経済をもっと面白くする」というミッションに共感してくれる人と、一緒にやっていきたいと述べました。

最後に開発者体験をテーマにしたイベントをやってみて思うことを問われた林氏は、「改めて開発者体験の重要性を再認識した」として、文化や組織作りを推進していきたいと抱負を述べました。

高山氏は、「今回のセッションで他のメンバーの事例発表を聞いて、チームとして最高の開発者体験を作るプロセスが知れた。今後もこの取り組みを続けたい」と話しました。

広木氏も、「今後も、開発者体験に注目しながら知見を持ち寄っていきたい」と締めくくりました。

イベントアーカイブ動画

編集後記

不確実な世界に企業が適応するためのデジタルトランスフォーメーション（DX）と、開発者体験の文化資本が蓄積する企業は変化適応力が高まるという文脈での開発者体験（DX）は両輪をなす、という提言は改めて重要だと感じました。

また、石井氏が紹介したリアーキや、大場氏のセッションで紹介されたデザイン設計とフロント開発をシームレスにする取り組みなどの事例は、トップダウンの改善ではなく、ボトムアップで組織文化を変えていく事例として印象的でした。

また、広木氏と高山氏、林氏によるパネルディスカッションでもチームとして最高の開発者体験を追求していくことが、企業の業績や競争力確保に有効であることが納得できる内容でした。今回のイベントは、“古くて新しいテーマ”である開発者体験に注目しつつ、組織文化を改革していく契機となったのではないでしょうか。

文： 阿部 欽一