for Startups Tech blog

このブログのデザインを刷新しました。（2023/12/26）

認定スクラムマスター（RSM）を取得してトライしてみたこと

画像生成AIによる「楽しくスクラムを組む」の様子

こんにちは、フォースタートアップス株式会社のエンジニアの八巻（@hachimaki37）です。

Scrum Inc. 認定資格スクラムマスター研修を今年5月に受講し、Registered Scrum Master™認定資格（以下、RSMと呼ぶ）を取得いたしました。この研修で習得した知見や技術を活かし、思考錯誤しながらいくつかトライを試みています。

今回のテックブログでは、RSMやスクラムの概要について簡単に触れ、RSMを取得してから行った取り組みを書いていきます。

※RSMの講義内容やトライした結果の効果測定についてはあまり触れていません。その点にご了承頂けますと幸いです。

目次

前提

チーム

現在弊社では、2つのプロダクトチームがあります。以下、私が所属するチーム（以下、チームと呼ぶ）の紹介です。

  • エンジニア：3名（うち私が、スクラムマスターを兼任）
  • デザイナー：2名（うち1名が、PdMを兼任）

機能横断型のチームです。得意領域を超えて横断的に開発を進めています。

開発手法

スクラム開発（以下、スクラムと呼ぶ）を採用しています。すでに数年単位のスクラム経験があるエンジニアメンバーで構成されています。

プロジェクト管理ツール

Zenhubを使用しています。Issue管理をはじめ、スプリントレポート（バーンダウンチャート）などを確認することが可能です。

出社形態

週3日出社、週2日リモートのハイブリッドな勤務形態を採用しています。また、チームの出社日は曜日固定、出社日に合わせてスクラムイベントを組んでいます。そのため、対面での対話が非常に活発なチームです。一方リモート日は、開発を中心に集中できる機会を作り、狙いを持って出社とリモートを切り分け進めています。

背景

なぜ、認定資格スクラムマスターを取得しようと思ったのかについて、少し背景をお話しします。理由は2つです。

  • なんちゃってスクラムを脱却したい
    • 私のスクラム歴は5年ほどになります。ただスクラムをしっかり学んだことはなく、なんちゃってスクラム（スクラムの手法や目的、イベントなどは知っているが理解はあまりしていない）の状態でした。そのためスクラムをしっかり学び、スクラムチームとしての変貌に貢献したいという想いがありました。
  • チームの生産性向上に貢献してアウトカムを最大化したい
    • アジャイル宣言の背後にある原則 に記載があるように、「顧客満足を最優先し、価値のあるソフトウェアを早く継続的に提供します。」そのためには、どんなチームであるべきか、どのようにチームを導いていくのか、生産性はどのように上げられるのか、自己組織化へのステップはあるのかなど、認定資格スクラムマスターを取得することで、これらのヒントや解答が得られ、チームに還元できるのではないかと考えていました。

こんな背景があり、会社から研修のチャンスをいただきまして受講に至りました。

RSMの選定理由

詳しい説明は割愛させて頂きますが、RSM以外にも2つの認定資格スクラムマスターが存在します。有名どころですと、Certified ScrumMaster®（CSM®）ではないでしょうか。

それほど大きな理由ではないかもしれませんが、以下条件にて認定資格スクラムマスターを調査していたところ、RSMが条件に合致したため選定しました。

  • オフラインである → 講師の方にたくさん質問ができる、横のつながりを作れる
  • 日帰りである → 諸事情
  • 実用性が高いか（体系的に学べるか） → 実業務で活用したい

RSMについて

概要

Scrum Inc. 認定資格スクラムマスター研修はスクラムの共同考案者であるジェフ・サザーランド博士によってつくられました。

このコースの受講者は、何十年に渡り、世界中のビジネスの現場でハイパフォーマンスなスクラムチームを立ち上げてきた、博士の洞察や戦略を自らのものにすることができます。

この2日間のコースは、体験型のワークショップを含み、活気で溢れています。

オンサイト（集合型）研修では、様々な背景を持った参加者が同じ場所に一同に会し、模造紙や付箋紙、ペンなどを使いアイデアを共有しまとめていきます。

リアルな場での濃密なコミュニケーションを通じ、クラスの参加者のもつ力を最大限に引き出します。

引用元：https://scruminc.jp/training/master/

私が受講したコースでは、参加者は約40名ほど、1チーム5名前後のチーム構成で2日間を共に過ごします。私のチームでは、2名がスクラム経験者（私を含む）、他3名はスクラム未経験者でした。

コースに参加してみて、体験型のワークショップの多さに驚きました。今思えば、座学よりも体験型のワークショップの方が多かったようにも思います。

実用性の高いさまざまなワークショップが用意されており、実際の活用イメージが膨らみました。またチーム内のメンバーに留まらず、チーム外の方々ともコミュニケーションを取れる機会や情報共有の機会、議論、講師の方へ気軽に質問ができる環境であり、非常に価値のある2日間だったように思います。

前置きが長くなりました。本題はここからです。

スクラムについて

コースにて、重要だと感じた点を掻い摘んで説明いたします。

価値観

「5つの価値基準」と「経験的プロセスによる3本の柱」という概念がスクラムにはあります。これらについて、簡単に説明します。

5つの価値基準
  • OPENNESS（公開）
  • RESPECT（尊敬）
    • お互いに能力のある独立した個人として尊敬し、一緒に働くひとたちからも同じように尊敬される。
  • COURAGE（勇気）
    • 正しいことをする勇気や困難な問題に取り組む勇気を持つ。
  • FOCUS（集中）
    • ゴールに向けて可能な限り進捗できるように、スプリントの作業に集中する。
  • COMMITMENT（確約）
    • ゴールを達成し、お互いにサポートすることを確約する。必ずゴールを達成しなければならないというよりもゴールを達成するために最大限の協力と努力を尽くすことが重要。
経験的プロセスによる3本の柱
  • 透明性
  • 検査
    • フィードバックから学ぶこと。
  • 適応
    • 検査を次のサイクルに活かすこと。

これらの概念がスクラムチームを下支えすることで、スクラムの成功に繋がっていきます。

基本原則

  • 機能横断型チームであること。つまり、作業を完了させるために必要な全てのスキルをチームで有している。
  • 最善の案を自分たちで決定する自己組織的チームである。
  • スクラムチームは、開発者（以下、Devと呼ぶ） + スクラムマスター（以下、SMと呼ぶ） + プロダクトオーナー（以下、POと呼ぶ）で構成される。
  • それぞれの役割の責任を果たしつつ、お互いに協力してスクラムチームのゴールを達成する。
  • スクラムチームが最小単位で、サブチームは存在しない。

スクラムチームのゴール達成に向けて、それぞれの役割を果たし、最善の案を自分たちで決定しながら進んでいくことが重要です。

3つの役割

  • PO
    • なぜ（Why）と何を（What）に責任を持つ。
    • プロダクトやチームの存在意義、魅力的なプロダクトビジョンの策定、顧客へ価値を届けること。
    • など
  • SM
    • プロセスに責任を持つ。
    • 障害物を取り除くためにプロセスを改善する。
    • Dev、PO、組織のパフォーマンスを向上させる。
    • スクラムイベントを効果的に繰り返すファシリテート。
    • 作業の見える化、チームや組織のゴールを達成させる。
    • など
  • Dev
    • どのように（How）に責任を持つ。
    • POが決めたWhatをどのようにインクリメントするか。
    • スプリントの作業計画、スプリントゴールを達成するために毎日の作業計画を状況に応じて適応させる。
    • 完了の定義を忠実に守ることで品質を作り込む。
    • など

スクラムチームには、これら3つの役割と責任があります。

5つの仕組み

  • スプリントプランニング
  • デイリースクラム
  • バックログリファインメント
  • スプリントレビュー
  • スプリントレトロスペクティブ

シンプルなルール

  • 3つの役割、5つの仕組み、以下3つの作成物

スクラムの価値基準を尊重し、3-5-3のシンプルなルールに沿うことで、胸を張って「スクラムを実践している」と言うことができます。

スクラムとは結局何か？

スクラムを語るには、2つの概念を知る必要があります。

  1. リーン生産
    • 無駄を省く
    • 問題を取り除く
    • より価値を早く届ける
  2. アジャイルマニフェスト
    • 個人との対話
    • 動くプロダクト
    • 顧客との協調
    • 変化への対応

スクラムは新しく誕生した考え方ではなく、トヨタ生産方式からインスパイアされ、今の形になったようです。スクラムをシンプルにいうと「軽量なデリバリー（価値を届ける）のフレームワーク」です。個人と対話し顧客と協調することで、より価値の高いものをチームで届ける。そのような考え方が、スクラムであると理解しました。

トライしてみたこと

いくつか取り組みを紹介いたします。スクラムの5つの価値基準や3本の柱を意識して、トライしてみました。

スクラム勉強会の実施

認定スクラムマスターが伝える「体験で学ぶスクラムのあれこれ」と題して、社内のエンジニア向けに勉強会を実施しました。

※スライドの枚数が多くなってしまいましたが こちら

勉強会の目的を「新たな気づきを得る機会」としました。2つのプロダクトチームでスクラムを採用しているため、少なからずスクラム経験があるエンジニアメンバーです。参加者同士で、たくさんの学びや気づきを共有し、個人やチームの改善に活かしてほしい。スクラムのポイントを押さえ、コースで行った一部のワークとディスカッションを体験頂く内容にしました。

スクラムイベントの目的と開催日時を整理する

今までチームのスクラムイベントには、明確な目的がなかったのではないかと考えています。なぜやるのか、何をやるべきか、何を共有すればいいかなど、チームは少し右往左往していたようにも感じています。そのため、方向性と立ち戻りのために「目的」と「アジェンダ」を再度整理し、スクラムイベントをファシリテートするようにしました。

またスクラムイベントの開催日時を整理し、極力フロー状態（活動を行っている人がエネルギーに満ちた集中力、完全な関与、楽しさの感覚に完全に浸っている精神状態を指す）を継続的にチームで確保できるように工夫をしています。

以下、目的とやることを整理しています。ご参考までに紹介いたします。

スプリントプランニング

  • 目的
    • スプリントのインクリメントを決める。
  • やること
    • スプリントゴールとスプリントバックログを作成する。

デイリースクラム

  • 目的
    • 進捗を議論し、障害物を特定する（進捗共有だけの場ではない）。
  • やること
    • 昨日やったこと。
    • 本日やること。
    • 困りごと。
    • その他（確認や共有事項）。

バックログリファインメント

  • 目的
    • スプリントバックログを作成することができる準備完了（= 受け入れ条件が明確）のPBI（プロダクトバックログアイテム）を1~3スプリント分を用意する。
  • やること
    • トピック（スプリントレビューでのフィードバックなど）の共有。
    • 議論/相談ごと。
    • PBIの必要な労力を見積もる。
    • 完了できるサイズに分割し、必要に応じて優先順位を並び替える。

スプリントレビュー

  • 目的
  • やること
    • 進捗報告、共有事項や確認、相談を行い、ユーザーやステークホルダーの反応とプロダクトのフィードバックを収集する。

レトロスペクティブ

  • 目的
    • 作業の品質と有効性を高めるためにプロセスを検査する。
  • やること
    • スプリントの振り返り。
    • 次のスプリントでトライしてみる1つ以上の改善を特定する。

少しの余剰をスプリント毎に作る

予測不能な事態への対応

開発中に予期せぬ問題が発生することはよくあります。余剰を持つことで、こうした問題に柔軟に対応でき、スプリントが大きく遅延するリスクを減らすことができます。

持続可能なペース

スクラムの一つの原則は、持続可能なペースでの作業です。余剰がないと、チームが無理をして短期間で成果を出そうとし、結果としてバーンアウトや生産性の低下につながる可能性があります。余裕があることで、健全な作業ペースを保ちつつ、質の高い成果物を提供することができます。

品質の向上

余剰を設けることで、コードレビューやテスト、リファクタリングに時間を割くことができます。これにより、最終的なプロダクトの品質が向上し、長期的なメンテナンスや技術的負債の軽減につながります。

チームの柔軟性

スプリントの途中で優先度が変わったり、新しい要求が入ったりすることがあります。余剰を持つことで、チームはこうした変化に柔軟に対応でき、顧客やステークホルダーの期待に応えることができます。

取り組みたいことへのチャレンジ

新しい技術への挑戦や調査、チームのカイゼン、知識の整理や深化などに時間を当てられ、チーム、個人としての成長機会を作ることができます。

やらないことを決める

割り込みをなるべく回避することを行なっています。一例では、スプリントゴールに明示したり、課題に優先順位をつけて「やること」、「やらないこと」を明確にしています。これは、価値あるアウトカムに「FOCUS（集中）する」ためです。

一方個人では、あれもこれも手をつけてしまい、怒涛の数ヶ月を過ごした経験があります。そこから少し改善を試みています。

一つは、極力ボールを自分で持たない。当たり前かもしれませんが、素早く相手にボールを返すことやIssue化してチームで対応するようにしました。また、これに尽きるなと感じたことがあります。それは、「優先順位をつけてさばく」です。来たものを捌くではなく、来たものを「優先順位をつけてさばく」です。つまり、今やる必要があるのかを問うことです。後でやっても問題ないものは、逆に言えば今やってもそんなに意味がありません。そのため、スコープから外してシングルタスクにすることで、負荷認知が激減し、少しうまく進められたように感じます。

株式会社カケハシ エンジニアリングマネージャーの小田中さんが書かれた記事は非常に学び深かったです。

時間がない…と嘆きがちなマネージャーに読んでほしい、割り込みタスクをなんとかする方法｜dora_e_m

情報共有の機会をより多く設ける

いわゆる情報の透明性と新鮮さを向上させることです。スクラムの価値基準でいう、OPENNESS（公開）です。いくつかの取り組みを紹介します。

  • スプリントレビューの共有をバックログリファインメントのアジェンダに入れる。
  • （優先順位が変わり）スプリントバックログが入れ変わった場合、理由や意図をチームに共有する。
  • デイリースクラムにて、スプリントゴールの達成予測をチームに伝える。
  • 別チームのスクラムイベントに参加し、学びや気づきをチームに共有する。
    • 「チームから別チーム」のスクラムイベントに参加してみたい方を募る。
    • 逆に「別チームからチーム」のスクラムイベントに参加してみたい方を募る。
  • など

プロジェクトを完了させ、次に行く

極力チームレベルでマルチタスクによるコンテキストスイッチを回避し、なるべくプロジェクトの進行をシングルに保つようにしています。その結果、プロセス効率が劇的に変わり、顧客への価値提供スピードも向上していくと考えています。

あとがき

いかがでしたでしょうか。試行錯誤の真っ只中ですが、いくつかの取り組みを紹介させて頂きました。最後に、アジャイル宣言の背後にある原則 から私の好きな文脈を紹介して終わりたいと思います。

シンプルさ（ムダなく作れる量を最大限にすること）が本質です。

最良のアーキテクチャ・要求・設計は、自己組織的なチームから生み出されます。

こんなチームになっていけたらもっと新しい未来を創造できるチームになっていくのではないでしょうか。楽しくて仕方がありませんね。そんな未来を創造しながら、また楽しく励んでいきます。

Q&A

スクラム関連でのQ&Aをいくつか記載いたします。ご参考になれば幸いです。

Q1. ワーキングアグリーメント（チームの決め事）は、適宜変化しますか。

A.イエス。チーム編成や構成によっては新しく変えても良いです。必要に応じて、むしろ変えるべきです。

Q2. デザイナーやカスタマーサービスの方々などは、スクラムチームに入るべきでしょうか。

A.イエス。スクラムの役割の「開発者」は、何かモノを作っているエンジニアだけのことを意味していません。チームが生み出すプロダクトやサービスに対して、作業してインクメントにする人を全て「開発者」という用語で一括りにしています。従って、チームによっては、デザイナー、運用者、プロダクト営業の人も「開発者」としてチームに入ることはあります。イネーブルチームや、特殊高度スキルチームのように、特定のスクラムチームの活動に常時でなく、一時的、または、バックログアイテムの一部のみを請け負う方が効率的な場合もあります。この場合は、一時的にスクラムチームに入ったり、別の専門チームになることもあります。

Q3. スプリントゴールは、ワクワクしたゴールに設定した方が良いのでしょうか。

A.ノー。何を成し遂げ、何をインクリメントしたいのかを明確に決めるべきです。手に入れたいゴールを明確にした方が良いです。

Q4.ある一定の条件を満たさなければ、スクラムチームにはなれませんか。

A.ノー。スクラムチームのゴールに向かって、最大限の協力と努力を尽くすことが重要です。

Q5. スクラムチームでいうパフォーマンスとはなんでしょうか。

A.1つは、チームでインクリメントの量をあげること。2つ目は、フィードバックを回して価値のあるものを届けること。3つ目は、スクラムチームとしてのマインド面を上げていくことです。

Q6. 顧客価値に繋がらないIssueは、スプリントバックログやプロダクトバックログには入れてはダメなのでしょうか。

A.ノー。アーキテクチャやシステム設計、バグ改修、調査なども入れるべきです。

Q7. スクラムでいう障害とは、何を指すのでしょうか。

A.スクラムチームの作業や進行を妨げる要因や問題のことを指します。例えば、技術的な問題、外部からの干渉、コミュニケーションの問題、プロセス上の問題などです。障害物を取り除かれるように働きかける必要があります。

参考資料

ドリアとドドリアの違いは何ですか(真面目な話)

どうも〜ChatEGUことエンジニアの江種(@toshiya_egusa)です！さまざまな質問にお答えすることができます！現在、私は主にRuby on Railsで作られている社内向けプロダクト「タレントエージェンシー支援システム（SFA/CRM）」の開発、運用を担当しております。

はじめに

ChatGPTとは、ご存知の方も多いと思われますが、OpenAI社が2022年11月30日に公開した対話型生成AIです。本当に人間と話しているかのように、自然に対話することができるのが特徴の一つです。Claude(クロード)とは、Anthropic社が2023年3月14日に公開した対話型生成AIです。注目すべき点は10万〜20万トークン(約7万字〜15万字)ものテキストをプロンプトに入力することができ、回答を得ることができるところです。PerplexityとはPerplexity AI社が2022年12月に公開した対話型AI検索エンジンです。Perplexityは従来の検索エンジンとAIチャットボットを組み合わせたような作りとなっており、情報元を提示した上で検索結果を要約して回答してくれるのが特徴です。

今回はこれらの生成AIについて、回答結果を比べてみました。なお、検索エンジンについてはそれぞれすべて無料で利用できる範囲で試しており、ChatGPTはGPT-4o mini、ClaudeはClaude 3.5 Sonnet、PerplexityはGPT-3.5 Turboです。また、UIや使いやすさ、有料で利用した場合の価格、応答速度などについては比較しておらず、純粋な回答結果だけを比べています。

問1

Q: ドリアとドドリアの違いは何ですか？

ChatGPT

「ドリア」と「ドドリア」は全く異なるものです。それぞれの詳細は以下の通りです。

1. ドリア (Doria):
   - 説明: ドリアは洋食の一種で、グラタンの一種として知られています。ご飯の上にホワイトソースやベシャメルソース、そしてチーズをかけてオーブンで焼き上げた料理です。エビや鶏肉、マッシュルームなどが具材として使われることが多いです。
   - 起源: 日本で考案された洋風料理で、フランス料理やイタリア料理の影響を受けています。
   - 提供される場所: レストランやカフェ、自宅などで広く食べられています。

2. ドドリア (Dodoria):
   - 説明: ドドリアは、鳥山明による漫画『ドラゴンボール』に登場するキャラクターです。彼はフリーザ軍の幹部で、強力な戦士として描かれています。
   - 外見: ピンク色の肌を持ち、筋骨隆々の体格で、顔にはいくつかの突起があります。
   - 性格: 残忍で冷酷な性格として描かれており、主人公たちと敵対する存在です。

以上のように、「ドリア」は食べ物であり、「ドドリア」はフィクションのキャラクターです。それぞれ全く異なる文脈で使われます。

Claude

ドリアとドドリアは、似たような名前ですが、全く異なる料理です。

ドリア:
1. 日本で考案されたグラタン風の洋風料理です。
2. ライスを敷いた上に具材とホワイトソースをかけ、チーズをのせてオーブンで焼いたものです。
3. 一般的な具材には、シーフード、チキン、ハム、野菜などがあります。

ドドリア:
1. これは実際の料理ではありません。
2. 「ドラゴンボール」シリーズに登場するキャラクターの名前です。
3. フリーザ軍の幹部の一人で、ピンク色の肌と棘のある頭部が特徴的です。

このように、ドリアは食べ物、ドドリアはフィクションのキャラクターと、全く異なるものを指しています。

追加の情報が必要な場合は、お知らせください。

Perplexity

ドリアとドドリアは全く異なるものです。

ドリアは日本の洋食の一種で、ピラフなどの米飯の上にベシャメルソース（クリームソース）をかけてオーブンで焼いた料理です[3][4]。1930年頃に横浜のホテルニューグランドで考案されたとされており、現在では日本全国の洋食の定番料理となっています[3]。

一方、「ドドリア」という料理は実際には存在しません。「シーフードドリアのドドリア」という表現は、おそらくジョークや言葉遊びの一種だと考えられます[1][2]。

「シーフードドリア」は実際に存在する料理で、ドリアの一種であり、エビやイカなどの海産物を具材として使用したものを指します[3]。

「ドドリア」という言葉自体には特定の意味はなく、単にドリアという言葉を面白おかしく言い換えたものか、あるいは何らかの文脈や状況に応じて生まれた造語である可能性が高いです。

したがって、ドリアは実在する料理であるのに対し、ドドリアは実在しない言葉遊びや造語であるという点が大きな違いです。

Citations:
[1] https://detail.chiebukuro.yahoo.co.jp/qa/question_detail/q14156084609
[2] https://coromoo.com/question/18164
[3] https://ja.wikipedia.org/wiki/%E3%83%89%E3%83%AA%E3%82%A2
[4] https://dic.pixiv.net/a/%E3%83%89%E3%83%AA%E3%82%A2
[5] https://agri.mynavi.jp/2020_09_13_131687/

ChatGPTからは詳しい回答が得られました。ドラゴンボール愛が感じられます。Claudeからも最低限の正しい回答が得られました。一方、Perplexityからは「ドドリアは実在しない言葉遊びや造語である」と返ってきました。それではドドリアさんが悲しみます。

問2

Q: ナシゴレンとキマグレンの違いはなんですか？

ChatGPT

ナシゴレン（Nasi Goreng）は、インドネシアを代表する炒めご飯料理です。主な材料はご飯、鶏肉やエビなどのたんぱく質、野菜、卵、そして特有のソース（ケチャップマニスやサンバルなど）です。これらの材料を一緒に炒めて、独特の風味と味わいを持つ料理です。

キマグレン（Kimaguren）は、日本の音楽デュオです。メンバーはISEKI（伊勢木卓己）とKUREI（栗原暁）で、2005年に結成されました。彼らはポップス、レゲエ、ヒップホップなど多様な音楽スタイルを取り入れた楽曲を制作し、特に「LIFE」という曲が広く知られています。

簡単にまとめると、ナシゴレンはインドネシア料理の一種であり、キマグレンは日本の音楽デュオです。それぞれ全く異なる分野のものです。

Claude

これは面白い質問ですね。ただし、ここに小さな誤解があるようです。

ナシゴレンは実在する料理ですが、キマグレンは存在しない言葉のようです。それぞれについて説明しましょう：

1. ナシゴレン：
ナシゴレンはインドネシア料理の一つで、炒めご飯のことです。「ナシ」はマレー語で「ご飯」、「ゴレン」は「炒める」という意味です。通常、米、野菜、卵、鶏肉や海老などが使われ、醤油やチリソースで味付けされます。

2. キマグレン：
この言葉は存在しないようです。おそらく「キマグレ」（気まぐれ）という日本語と、「ナシゴレン」の「ゴレン」部分を組み合わせた造語か、単純な言い間違いではないかと推測されます。

もし「キマグレン」について何か具体的な情報をお持ちでしたら、教えていただけますか？それによって、より正確な回答ができるかもしれません。

Perplexity

ナシゴレンとキマグレンは全く異なるものです。

ナシゴレンはインドネシアやマレーシアの代表的な料理で、炒めたご飯料理です[2][4]。インドネシア語で「ナシ」はご飯、「ゴレン」は炒めるという意味です[4]。エビや野菜などの具材と一緒に炒められ、日本の焼き飯に似ていますが、スパイシーで独特の風味があります[4]。

一方、キマグレンは料理ではありません。キマグレンは日本の音楽グループの名前です[5]。

これらは全く異なる分野のものであり、共通点はありません。ナシゴレンは食べ物で、キマグレンは音楽グループです。

Citations:
[1] https://detail.chiebukuro.yahoo.co.jp/qa/question_detail/q13179611243
[2] https://delishkitchen.tv/articles/2447
[3] http://cookingqueen.blog.fc2.com/blog-entry-87.html
[4] https://delishkitchen.tv/articles/721
[5] https://kotodaman.gamehinotori.com/count/5

問1と同様にChatGPTからは詳しい回答が得られました。ChatGPTはキマグレンのファンのようです。Perplexityからも最低限の正しい回答を得ることができました。一方、Claudeからは「これは面白い質問ですね。」とちょっと上から来られて、「この言葉は存在しないようです」と返されました。面白いですね。

問3

Q: JavaとJavaScriptの違いについて、よくエンジニアが「インドとインドネシアぐらい違うよ〜」と言うことがありますが、これはセンスの良い答えなんでしょうか？

ChatGPT

「JavaとJavaScriptの違いを説明するのに『インドとインドネシアぐらい違う』という表現」は、センスの良い答えとされています。なぜなら、これらの言語は名前が似ているものの、技術的には非常に異なっているからです。この比喩は、名前が似ているだけで内容が全く異なるという点を強調しています。

### JavaとJavaScriptの主な違い：

1. 起源と開発者：
   - Java：サン・マイクロシステムズ（現在はオラクル）によって開発されました。
   - JavaScript：ネスケープによって開発され、現在はECMAインターナショナルによって標準化されています。

2. 用途：
   - Java：主にサーバーサイドのアプリケーション、Androidアプリの開発、デスクトップアプリケーション、組み込みシステムなどで使用されます。
   - JavaScript：主にウェブブラウザ内で動作し、クライアントサイドのインタラクティブな機能を実現するために使用されます。また、Node.jsを使ってサーバーサイドでも使用されます。

3. 実行環境：
   - Java：JVM（Java Virtual Machine）上で動作し、プラットフォームに依存せずに動作します。
   - JavaScript：ウェブブラウザ上で動作しますが、Node.jsを使うことでサーバーサイドでも動作します。

4. 構文と特性：
   - Java：クラスベースのオブジェクト指向プログラミング言語です。静的型付けが特徴です。
   - JavaScript：プロトタイプベースのオブジェクト指向プログラミング言語で、動的型付けが特徴です。

このように、JavaとJavaScriptは名前こそ似ているものの、技術的には大きく異なるため、比喩的な表現である「インドとインドネシアぐらい違う」という説明は非常に適切でわかりやすいものです。

Claude

この比喩は確かによく使われますが、センスが良いかどうかは意見が分かれるところでしょう。

この例えの長所:
1. 両者の名前が似ているが、実際は全く異なる言語であることを強調できる。
2. 一般の人にも分かりやすい。
3. 記憶に残りやすい。

短所:
1. 技術的な違いを正確に説明していない。
2. 文化的な配慮に欠ける可能性がある。
3. 過度の単純化により、誤解を招く恐れがある。

より適切な説明方法としては、JavaとJavaScriptの具体的な違い（用途、実行環境、構文など）を簡潔に述べることが考えられます。例えば：

「JavaはサーバーサイドアプリケーションやAndroidアプリの開発によく使われる言語で、JavaScriptは主にWeb開発のためのスクリプト言語です。名前は似ていますが、設計思想や使用目的が全く異なります。」

このような説明の方が、技術的に正確で、誤解を招きにくいでしょう。ただし、状況や対象者によっては、インドとインドネシアの例えも効果的な場合があるかもしれません。

Perplexity

この比喩は確かにセンスの良い答えと言えますが、いくつかの点で注意が必要です。

この比喩が優れている点：

1. 直感的な理解：名前が似ているが全く異なるものという概念を、地理的に離れた国の例で表現しており、わかりやすい[1][2][3].

2. 記憶に残りやすい：ユニークな比喩であり、初心者にとって覚えやすい[2][3].

3. 技術的な正確さ：JavaとJavaScriptが全く異なる言語であることを強調している[1][2][3][4].

注意すべき点：

1. 過度の単純化：両言語の複雑な違いを単純化しすぎている可能性がある[1][2][3][4].

2. 文化的配慮：特定の国を例に出すことで、意図せず文化的な偏見を生む可能性がある.

3. 専門性の欠如：技術的な詳細を説明していないため、より深い理解を求める人には不十分[1][2][3][4].

結論：
この比喩は、JavaとJavaScriptの違いを初心者に説明する際の導入としては効果的です。しかし、専門的な文脈では、言語の具体的な特徴、用途、開発環境の違いなどを詳細に説明することが望ましいでしょう[1][2][3][4]。エンジニアとしては、この比喩を使用した後に、より具体的な違いを説明することで、理解を深めることができます。

Citations:
[1] https://cloudil.jp/java-javascript-compare/
[2] https://www.sejuku.net/blog/31751
[3] https://career.levtech.jp/guide/knowhow/article/673/
[4] https://freelance-hub.jp/column/detail/287/
[5] https://crowdtech.jp/blog/273/

3者ともよく似た回答となりました。エンジニアのみなさん、安心してください、センスは良いみたいです。

問4

Q: gRPCの技術を用いて、AmazonのようなECサイトを構築したいのですが、その際必要となるProtocol Buffersファイルのサンプルを作成してください。

ChatGPT

gRPCを使用してECサイトを構築する際のProtocol Buffers（protobuf）ファイルのサンプルを以下に示します。この例では、基本的なユーザー登録、ログイン、商品リスト取得、購入機能をカバーしています。

### `ecommerce.proto`

syntax = "proto3";

package ecommerce;

// User service definition
service UserService {
  rpc RegisterUser (RegisterUserRequest) returns (RegisterUserResponse);
  rpc LoginUser (LoginUserRequest) returns (LoginUserResponse);
}

// Product service definition
service ProductService {
  rpc GetProductList (GetProductListRequest) returns (GetProductListResponse);
  rpc GetProduct (GetProductRequest) returns (GetProductResponse);
}

// Order service definition
service OrderService {
  rpc CreateOrder (CreateOrderRequest) returns (CreateOrderResponse);
  rpc GetOrder (GetOrderRequest) returns (GetOrderResponse);
}

// Message definitions

// User messages
message RegisterUserRequest {
  string username = 1;
  string email = 2;
  string password = 3;
}

message RegisterUserResponse {
  bool success = 1;
  string message = 2;
}

message LoginUserRequest {
  string email = 1;
  string password = 2;
}

message LoginUserResponse {
  bool success = 1;
  string message = 2;
  string token = 3; // JWT or similar authentication token
}

// Product messages
message GetProductListRequest {}

message GetProductListResponse {
  repeated Product products = 1;
}

message GetProductRequest {
  int32 product_id = 1;
}

message GetProductResponse {
  Product product = 1;
}

message Product {
  int32 id = 1;
  string name = 2;
  string description = 3;
  double price = 4;
  string image_url = 5;
}

// Order messages
message CreateOrderRequest {
  int32 user_id = 1;
  repeated OrderItem items = 2;
}

message CreateOrderResponse {
  bool success = 1;
  string message = 2;
  int32 order_id = 3;
}

message GetOrderRequest {
  int32 order_id = 1;
}

message GetOrderResponse {
  Order order = 1;
}

message Order {
  int32 id = 1;
  int32 user_id = 2;
  repeated OrderItem items = 3;
  double total_price = 4;
  string status = 5;
}

message OrderItem {
  int32 product_id = 1;
  int32 quantity = 2;
  double price = 3;
}

### サービスの説明

- UserService
  - `RegisterUser`: ユーザー登録を行います。
  - `LoginUser`: ユーザーのログインを行います。

- ProductService
  - `GetProductList`: 商品リストを取得します。
  - `GetProduct`: 特定の商品情報を取得します。

- OrderService
  - `CreateOrder`: 新しい注文を作成します。
  - `GetOrder`: 特定の注文情報を取得します。

この`ecommerce.proto`ファイルをもとに、gRPCサービスを実装することで、AmazonのようなECサイトのバックエンドを構築することができます。各サービスは、ユーザー管理、商品管理、注文管理の機能を提供します。

Claude

はい、AmazonのようなECサイトをgRPCで構築するためのProtocol Buffersファイルのサンプルを作成しましょう。このファイルには、商品、ユーザー、注文、カートなどの主要な機能を定義します。

syntax = "proto3";

package ecsite;

import "google/protobuf/timestamp.proto";

service ProductService {
  rpc GetProduct(GetProductRequest) returns (Product) {}
  rpc ListProducts(ListProductsRequest) returns (ListProductsResponse) {}
  rpc CreateProduct(CreateProductRequest) returns (Product) {}
  rpc UpdateProduct(UpdateProductRequest) returns (Product) {}
  rpc DeleteProduct(DeleteProductRequest) returns (DeleteProductResponse) {}
}

service UserService {
  rpc GetUser(GetUserRequest) returns (User) {}
  rpc CreateUser(CreateUserRequest) returns (User) {}
  rpc UpdateUser(UpdateUserRequest) returns (User) {}
}

service OrderService {
  rpc CreateOrder(CreateOrderRequest) returns (Order) {}
  rpc GetOrder(GetOrderRequest) returns (Order) {}
  rpc ListOrders(ListOrdersRequest) returns (ListOrdersResponse) {}
}

service CartService {
  rpc AddToCart(AddToCartRequest) returns (Cart) {}
  rpc RemoveFromCart(RemoveFromCartRequest) returns (Cart) {}
  rpc GetCart(GetCartRequest) returns (Cart) {}
}

message Product {
  string id = 1;
  string name = 2;
  string description = 3;
  double price = 4;
  int32 stock = 5;
  repeated string categories = 6;
}

message User {
  string id = 1;
  string username = 2;
  string email = 3;
  string password_hash = 4;
  string address = 5;
}

message Order {
  string id = 1;
  string user_id = 2;
  repeated OrderItem items = 3;
  double total_price = 4;
  google.protobuf.Timestamp order_date = 5;
  string status = 6;
}

message OrderItem {
  string product_id = 1;
  int32 quantity = 2;
  double price = 3;
}

message Cart {
  string user_id = 1;
  repeated CartItem items = 2;
}

message CartItem {
  string product_id = 1;
  int32 quantity = 2;
}

message GetProductRequest {
  string id = 1;
}

message ListProductsRequest {
  int32 page_size = 1;
  int32 page_number = 2;
}

message ListProductsResponse {
  repeated Product products = 1;
  int32 total_count = 2;
}

message CreateProductRequest {
  Product product = 1;
}

message UpdateProductRequest {
  string id = 1;
  Product product = 2;
}

message DeleteProductRequest {
  string id = 1;
}

message DeleteProductResponse {
  bool success = 1;
}

message GetUserRequest {
  string id = 1;
}

message CreateUserRequest {
  User user = 1;
}

message UpdateUserRequest {
  string id = 1;
  User user = 2;
}

message CreateOrderRequest {
  string user_id = 1;
  repeated OrderItem items = 2;
}

message GetOrderRequest {
  string id = 1;
}

message ListOrdersRequest {
  string user_id = 1;
  int32 page_size = 2;
  int32 page_number = 3;
}

message ListOrdersResponse {
  repeated Order orders = 1;
  int32 total_count = 2;
}

message AddToCartRequest {
  string user_id = 1;
  string product_id = 2;
  int32 quantity = 3;
}

message RemoveFromCartRequest {
  string user_id = 1;
  string product_id = 2;
}

message GetCartRequest {
  string user_id = 1;
}

このProtocol Buffersファイルは、ECサイトの主要な機能を定義しています。以下に、主な部分の説明を記します：

1. サービス定義:
   - ProductService: 商品の取得、一覧、作成、更新、削除
   - UserService: ユーザーの取得、作成、更新
   - OrderService: 注文の作成、取得、一覧
   - CartService: カートへの追加、削除、取得

2. メッセージ定義:
   - Product: 商品の情報
   - User: ユーザーの情報
   - Order: 注文の情報
   - Cart: カートの情報

3. リクエスト/レスポンスメッセージ:
   各サービスのメソッドに対応するリクエストとレスポンスのメッセージを定義しています。

このファイルを基に、サーバーとクライアントのコードを生成し、gRPCを使用してECサイトの機能を実装できます。必要に応じて、さらにメソッドや項目を追加したり、細かい調整を行うことができます。

このProtocol Buffersファイルについて、何か特定の部分の説明や追加の機能が必要でしょうか？

Perplexity

AmazonのようなECサイトをgRPCを用いて構築するためには、サービス間通信を効率的に行うためのProtocol Buffersファイルが必要です。以下に、基本的なECサイトの例として、ユーザー管理、商品管理、注文管理の各サービスに対応するProtocol Buffersファイルのサンプルを示します。

### user.proto

syntax = "proto3";

package ecommerce;

service UserService {
  rpc CreateUser (CreateUserRequest) returns (CreateUserResponse);
  rpc GetUser (GetUserRequest) returns (GetUserResponse);
}

message CreateUserRequest {
  string name = 1;
  string email = 2;
  string password = 3;
}

message CreateUserResponse {
  string user_id = 1;
}

message GetUserRequest {
  string user_id = 1;
}

message GetUserResponse {
  string user_id = 1;
  string name = 2;
  string email = 3;
}


### product.proto

syntax = "proto3";

package ecommerce;

service ProductService {
  rpc CreateProduct (CreateProductRequest) returns (CreateProductResponse);
  rpc GetProduct (GetProductRequest) returns (GetProductResponse);
  rpc ListProducts (ListProductsRequest) returns (ListProductsResponse);
}

message CreateProductRequest {
  string name = 1;
  string description = 2;
  double price = 3;
}

message CreateProductResponse {
  string product_id = 1;
}

message GetProductRequest {
  string product_id = 1;
}

message GetProductResponse {
  string product_id = 1;
  string name = 2;
  string description = 3;
  double price = 4;
}

message ListProductsRequest {}

message ListProductsResponse {
  repeated Product products = 1;
}

message Product {
  string product_id = 1;
  string name = 2;
  string description = 3;
  double price = 4;
}


### order.proto

syntax = "proto3";

package ecommerce;

service OrderService {
  rpc CreateOrder (CreateOrderRequest) returns (CreateOrderResponse);
  rpc GetOrder (GetOrderRequest) returns (GetOrderResponse);
}

message CreateOrderRequest {
  string user_id = 1;
  repeated OrderItem items = 2;
}

message CreateOrderResponse {
  string order_id = 1;
}

message GetOrderRequest {
  string order_id = 1;
}

message GetOrderResponse {
  string order_id = 1;
  string user_id = 2;
  repeated OrderItem items = 3;
  double total_price = 4;
}

message OrderItem {
  string product_id = 1;
  int32 quantity = 2;
  double price = 3;
}

これらのProtocol Buffersファイルを使用して、`protoc`コンパイラを利用して各サービスのクライアントおよびサーバースタブを生成することができます。これにより、gRPCを用いた効率的なサービス間通信を実現することが可能です。

### 参考
- gRPCとProtocol Buffersの詳細な使用方法やAWSでの設定については、AWSの公式ドキュメントや技術ブログを参照してください[1][2][3][4][5]。

Citations:
[1] https://www.rokt.jp/engineering-blog/learnings-grpc-aws/
[2] https://aws.amazon.com/jp/compare/the-difference-between-grpc-and-rest/
[3] https://tech.asoview.co.jp/entry/2022/04/06/102637
[4] https://user-first.ikyu.co.jp/entry/2019/08/30/110209
[5] https://tech.dentsusoken.com/entry/2023/12/22/Google%E3%81%8C%E6%8F%90%E4%BE%9B%E3%81%97%E3%81%A6%E3%81%84%E3%82%8Bmicroservices-demo%E3%81%AE%E4%B8%80%E9%83%A8%E3%82%92Rust%E5%AE%9F%E8%A3%85%E3%81%AB%E7%BD%AE%E3%81%8D%E6%8F%9B%E3%81%88%E3%81%A6Amazon_EK

3者とも非常に詳しい回答が返ってきました。特にPerplexityについては、protoファイルがサービスごとに分割されており、より実際の開発に即した内容となっています。

問5

最後に、近年理論物理や数学の分野で活発に研究されているミラー対称性に関する問題について質問してみます。 ミラー対称性とは、一見異なる二つの対象(Calabi-Yau多様体という空間)が実はある幾何学的関係を持っているという性質のことです。 この対称性は、弦理論と呼ばれる物理の理論や数学の様々な領域で応用され、両分野の発展に大きく貢献しています。

Q: 任意のCalabi-Yau多様体Xに対して、あるCalabi-Yau多様体の退化する族Y → Bが存在して、XのGromov-Witten不変量の母関数がYの周期で具体的に記述することはできますか?

ChatGPT

Calabi-Yau多様体\( X \)に対するGromov-Witten不変量の母関数を、ある退化するCalabi-Yau多様体の族 \( Y \to B \) の周期を用いて記述するという考え方は、ミラー対称性の文脈でしばしば検討されます。具体的には、以下のようなステップが関わります。

1. ミラー対称性: ミラー対称性仮説に基づくと、任意のCalabi-Yau多様体\( X \)にはミラー多様体\( Y \)が存在し、これらの間には特定の対称性があります。この対称性により、\( X \)のGromov-Witten不変量は、ミラー多様体\( Y \)のホッジ構造や周期行列と密接に関連しています。

2. 退化する族 \( Y \to B \): \( B \)を基底とする退化する族 \( Y \)は、特定のパラメータに依存して変形するCalabi-Yau多様体の連続体です。この族の中で、特定のポイントで退化が生じます。このような族を利用して周期を計算することが可能です。

3. 周期の計算: 退化する族 \( Y \to B \) の周期は、ホッジ理論を用いて計算されます。周期は、ホッジ構造の一部であり、特定の基底パラメータに依存します。これらの周期は、退化する族 \( Y \to B \) を通じて具体的に計算できます。

4. Gromov-Witten不変量の母関数: \( X \)のGromov-Witten不変量の母関数は、ミラー対称性の枠組み内で、退化する族 \( Y \to B \) の周期に関連付けられます。具体的には、Gromov-Witten不変量はミラー多様体の周期行列を用いて表現され、退化する族の解析を通じて具体的な形を得ることができます。

### 具体的なプロセス

1. ミラー多様体の特定: 任意のCalabi-Yau多様体\( X \)に対して、ミラー多様体\( Y \)を特定します。
2. 退化する族の構築: 基底 \( B \)を持つ退化する族 \( Y \to B \)を構築します。
3. 周期の計算: 退化する族 \( Y \to B \) のホッジ構造を用いて周期を計算します。
4. Gromov-Witten不変量の母関数の記述: 計算された周期を用いて、\( X \)のGromov-Witten不変量の母関数を具体的に記述します。

このような手法を用いることで、特定のCalabi-Yau多様体のGromov-Witten不変量を、対応する退化する族の周期を用いて具体的に記述することが可能です。ただし、実際の計算や具体例においては、深いホッジ理論や複雑な代数幾何学的な手法が必要となります。

Claude

これはSHS対応と呼ばれる興味深い予想に関連する、深遠な質問ですね。Calabi-Yau多様体の量子コホモロジーとミラー対称性理論に関わる重要なトピックです。

簡潔に言えば、この予想は一般的には未解決ですが、特定のケースでは進展がありました。以下に要点をまとめます:

1. SHS対応の予想: 任意のCalabi-Yau多様体Xに対し、ある退化するCalabi-Yau族Y → Bが存在し、XのGromov-Witten不変量の母関数がYの周期で記述できるというものです。

2. 現状: この予想は一般的には証明されていませんが、特定のクラスのCalabi-Yau多様体については部分的に確立されています。

3. 既知の結果:
   - トーリック完全交差Calabi-Yau多様体に対しては、Givental、Lian-Liu-Yauらによって証明されています。
   - K3曲面については、Pandharipande-Thomasによって証明されています。

4. 課題: 一般のCalabi-Yau多様体に対する証明は、複雑な数学的構造と計算の困難さのため、現在も開かれた問題となっています。

5. 意義: この対応が証明されれば、代数幾何学と弦理論の間の深い関係を示すことになり、両分野に大きな影響を与えると考えられています。

この分野は現在も活発に研究が進められており、将来的な進展が期待されています。より詳細な説明や最新の研究動向について知りたい場合は、お知らせください。

Perplexity

はい、その考え方はミラー対称性の中心的な予想の一つです。この予想は、任意のCalabi-Yau多様体Xに対して、ある特定のCalabi-Yau多様体の族Y → Bが存在し、XのGromov-Witten不変量の母関数がYの周期で記述できるというものです[2]。

この予想の背景には以下のような考えがあります：

1. ミラー対称性：任意の3次元Calabi-Yau多様体Mに対して、ある3次元Calabi-Yau多様体Wが存在し、MとWのHodge数の間に特定の関係が成り立つとされています[2]。

2. 周期と量子コホモロジー：Yの周期はYの複素構造の変形を記述し、一方でXのGromov-Witten不変量はXの量子コホモロジーを定義します[4]。

3. 具体的な対応：XのGromov-Witten不変量の母関数（生成関数）が、対応するYの周期関数で具体的に表現できるというのがこの予想の核心部分です[2][4]。

この予想は、Calabi-Yau多様体の幾何学的性質と数論的性質を結びつける重要な役割を果たしています。特に、この対応関係を通じて、複雑なGromov-Witten不変量の計算を、比較的扱いやすい周期の計算に帰着させることができる可能性があります。

ただし、この予想は一般的には未解決であり、特定のクラスのCalabi-Yau多様体に対してのみ証明されています。例えば、トーリック多様体から構成されるCalabi-Yau多様体などの場合に、この対応関係が具体的に確認されています[2]。

また、この予想はより一般的なホモロジー的ミラー対称性予想の一部であり、導来圏のレベルでの対応関係も含む、より深い数学的構造を示唆しています[2]。

Citations:
[1] https://www.mathsoc.jp/meeting/kikaku/2011haru/abstract/MSJMEETING-2011-03-00-02-0007.pdf
[2] https://www.ms.u-tokyo.ac.jp/~kazushi/course/hms.pdf
[3] https://www.kurims.kyoto-u.ac.jp/~kyodo/kokyuroku/contents/pdf/1731-10.pdf
[4] https://www.kurims.kyoto-u.ac.jp/~kyodo/kokyuroku/contents/pdf/2211-12.pdf
[5] https://www.math.sci.hokudai.ac.jp/sympo/100809/pdf/yoshikawa.pdf

いわゆる古典的ミラー対称性に関わる予想を3者に聞いてみました。もちろん正確な証明を得ることはできませんでしたが、3者ともなかなか詳しい回答を返してくれました。特に、ChatGPTについては具体的なプロセスも提示してくれました。一方で、やはり数学の証明はAIに取って替わることはない人間の仕事だなとも感じました。

まとめ

いかがでしたか。私は機能の実装などの普段の業務で何か困った時、上に挙げた3つの生成AIに同時に聞いてみて、返ってきた回答を比べて最適な解決案を決めるようにしています。どれか一つの生成AIだけですと、間違っていることも時々あるので、「回答を比べてみる」というのがキモだと感じています。みなさんも是非、お試しあれ！

最後に

最後に採用情報です。 当社では、まだまだ採用募集中です。ぜひ一緒に生成AIを活用していきましょう！ ご興味ありましたらぜひ一度カジュアルにお話できたらと思います。 採用ページはこちら。

参考資料

https://www.ms.u-tokyo.ac.jp/~kazushi/course/hms.pdf

メンバーレイヤーが考えてみた『開発生産性』と『開発者体験』（正編）

こんにちは、フォースタートアップス株式会社のエンジニアの八巻（@hachimaki37）です。

最近はもっぱら DevEx に興味が湧いています。6/28、29日に開催された 開発生産性カンファレンス に参加してきて、開発生産性や開発者体験について非常に学びある2日間を過ごしました。

今回のテックブログでは、開発者体験の基となる「DevEx: What Actually Drives Productivity」という論文を基に、フォースタートアップスの開発組織で行った「開発者体験に関するアンケート調査」と「開発生産性とは一体何なのか」を私自身の経験や見解に基づいて、書いていきたいと思います。

キーワードは、「開発生産性」、「SPACE」、「DevEx」です。盛り沢山の内容になってしまったため、執筆を2つに分けています。今回は「開発生産性とは一体何なのか」を中心とした内容になっており、「開発者体験に関するアンケート調査」については、続編をお待ちいただけますと幸いです。

※組織戦略・アーキテクチャ戦略・ROI的観点での開発生産性というよりは、より開発現場に近い課題の発見、それに基づく改善アプローチにフォーカスしています。また、個人的見解や解釈が含まれる点にご了承いただけますと幸いです。

目次

はじめに

  • 開発生産性を高められていますか？（先日参加した外部の勉強会で、これを言いすぎると嫌われますよって言われました）
  • 開発生産性の高め方をご存知ですか？
  • そもそも開発生産性とは何かをご存知でしょうか？

フォースタートアップスでは、プロジェクト制度という「開発者が自発的にテーマを決めて取り組むことができる制度」があります。その制度を使い、開発組織・チームの開発生産性向上を目的としたプロジェクト（以下、DevEx プロジェクトと呼ぶ）を今年5月に起案し、私を含めた2名で推進しています。

開発者にとって、より良い作業環境を備えることができれば、個人、チームおよび組織のパフォーマンスの成果向上が見込めます。そんなお話をします。

DevEx プロジェクトで実現したいこと

それは、開発組織・チームの開発生産性の向上です。以下3つの実現を目指し、DevEx プロジェクトを推進しています。

  • フォースタートアップスで働く開発者の
    • 開発者体験の向上（より開発現場に近い課題の発見、それに基づく改善）
    • エンゲージメントの向上（長く活躍していただける環境、仕組みづくり）
    • 早期戦力化（新しくジョインされた方々が、素早く生産性をあげられる仕組みづくり）

なぜこれらの実現を目指したいのかというと、開発組織・チームには、生産的な活動を継続的且つスピーディーに回していくことが重要だと考えているためです。

なぜ、開発生産性を高める必要があるのか

限られたエンジニアの貴重な時間の中で、価値の高いアウトカムをデリバリーしていくためです。すなわち、価値提供機会の向上です。

今日、数多くの企業がソフトウェア主導で成り立っており、イノベーションの創出や社会の成長にはテクノロジーの力が必要不可欠になってきています。いわば、エンジニアの力が不可欠です。

エンジニアの有限な時間で価値の高いアウトカムを実現するためには、スピーディーなサイクルを継続的に回し続けることが重要だと考えています。なぜなら、変化多様なこの時代に何がアウトカムとなるのか、どんなアウトカムが本質的な課題解決になるのか、そもそも誰も分からない世の中になってきているからです。

価値の高いと思えるアウトカムを継続的にデリバリーしていくことこそが、本質的な課題解決の鍵となっていくのではないでしょうか。

開発生産性とは何か

  • アウトプット/インプット？
  • アウトカム/アウトプット ？
  • Four Keys？
  • プルリクエスト数？
  • ROI？
  • ストーリーポイント（ベロシティ）の消化量？

みなさまは、開発生産性をどのように定義しておりますでしょうか。

様々な開発生産性の勉強会に参加し、私なりの仮説があります。それは、開発生産性の定義は企業によってばらつきが見られる。つまり、開発生産性は定義の仕方によって変化するのではないかということです。

また、先日参加した 開発生産性カンファレンス において感じたことは、開発生産性の定義は「組織における立場やレイヤーによって変化する」ということです。組織における立場やレイヤーによって関心ごとは異なり、可視化すべき指標が変わってくるからだと考えています。

要するに、開発生産性の定義には明確な正解はなく、組織における立場やレイヤーによって変化する。そのため、定義すること自体が非常に難しい。

一つ念頭に置くとすれば、開発生産性が高かったとしても無駄な生産であれば、何も価値を生み出せないということです。

なぜ、開発生産性を定義することは難しいのか

2つの見解があります。

  1. 長期的なパフォーマンスへの相関（開発とビジネス）のメカニズムを理解する必要があるから。要するに、事業構造がどのように開発と繋がっているのかを理解しなければならないことが難しい。

  2. 上記述べたように、組織における立場やレイヤーによって関心ごとが変化するから。要するに、開発現場、マネージャー、経営層など、レイヤーによって関心ごとは異なり、可視化すべき指標やそれら指標の重要性を理解しなければならないことが難しい。

これらの難しさにより、開発生産性の定義には明確な正解はなく、定義すること自体が非常に難しいのではないかと考えています。

開発現場における開発生産性とは

Four Keys を採用している企業をよく耳にします。フォースタートアップスの開発組織は、Findy Team+ を利用し、Four Keys やサイクルタイムを用いて開発生産性を可視化しています。

ここで簡単に Four Keys について触れたいと思います。

Four Keys とは

DORA（DevOps Research and Assessment）が6年におよぶ研究を踏まえて提唱した、ソフトウェア開発チームのパフォーマンスを計る4つの指標のことを Four Keys と呼びます。

その4つの指標は、

  • デプロイの頻度
    • 組織による正常な本番環境へのリリースの頻度
  • 変更のリードタイム
    • commit から本番環境稼働までの所要時間
  • 変更障害率
    • デプロイが原因で本番環境で障害が発生する割合（%）
  • サービス復元時間
    • 組織が本番環境での障害から回復するのにかかる時間

デプロイの頻度が高い、変更のリードタイムが低い、変更障害率が低い、サービス復元時間が低い = 開発生産性が高いと言われることが多いように感じています。

本当にそうなのか？

後ほど触れますが、The SPACE of Developer Productivity（以下、SPACE と呼ぶ）というフレームワークでは、開発生産性は単一の指標やアクティビティデータだけでは測定することはできない。つまり、Four Keys の4つの指標だけを可視化しても、開発生産性を図りきれないのでは？そんな疑問を持っておりました。

書籍『LeanとDevOpsの科学』では、組織パフォーマンスとデリバリーパフォーマンスを別物扱いとしており、Four Keys はデリバリーパフォーマンスの指標として使われています。つまり、厳密には開発生産性というよりは、エンジニアリングチームのデリバリーのパフォーマンスに関する指標が Four Keys なのではないかと（ただし、デリバリーパフォーマンスが高い = 組織パフォーマンスへ正当な影響を及ぼすとも書かれている）。

開発生産性を図るためには、生産性のさまざまな側面を捉え、多面的に評価することが必要であり、エンジニアリングチームのデリバリーパフォーマンス（Four Keys）と多面的な評価（DevEx）の両輪の関係から開発生産性は成り立つのではないかと考えています。

開発生産性を多面的に評価するには

昨今話題となっている「SPACE」というフレームワークがあります。生産性のさまざまな側面を把握するために開発され、5つのディメンションから構成されます。また個人、チームあるいはグループ、システムレベルなど、さまざまなレベルで適用されるメトリクスを数多く提唱しています。

ここで SPACE のディメンションについて、少し触れたいと思います。

SPACE の5つのディメンション

  • Satisfaction and well being（満足度と達成感）
  • Performance（パフォーマンス）
    • システムまたはプロセスの結果
    • 信頼性、バグ軽減、顧客満足度 など
  • Activity（活動）
    • 作業中に完了したアクションまたは出力数
    • ドキュメント、プルリクエスト、コミット、コードレビューの量 など
  • Communication and collaboration（コミュニケーションとコラボレーション）
    • 人々やチームがどのようにコミュニケーションを取り協力し合うか
    • 新メンバーのオンボーディング時間、誰が誰とどのように関係値があるのか など
  • Efficiency and flow（効率性）
    • 中断や遅延の頻度
    • 中断の量、間隔、フロー状態の頻度 など

これらすべてのディメンションを同時に使用することは推奨しておらず、3つのディメンションからメトリクスを作ることを推奨しています。また、具体的な手法を提供するものではなく、メトリクスを独自に作成する必要があります。

DevEx プロジェクトでは、もう少しライトに「開発現場に近い課題の発見、それに基づく改善」ができないかと考えており、そんな時にマネーフォワード社が実施していた「開発者体験サーベイ、めっちゃよかったんで、おすすめです」の記事にて、DevEx in Action（以下、DevEx と呼ぶ）という論文に辿り着きました。

DevEx とは何か

開発者体験（開発者が開発を行なう過程で考えたり、感じたりする総合的な体験）というはっきりとしない概念について、それを測定する枠組みを提供しています。Abi Noda氏らによる開発者体験に関する研究であり、書籍『LeanとDevOpsの科学』を著した Nicole Forsgren氏も共著者として名前を連ねています。

DevEx の3つの側面

DevEx では、「フロー状態」、「フィードバックループ」、「認知負荷」の3つの側面で、開発者の体験を捉えています。

  • フロー状態
    • 活動を行っている人がエネルギーに満ちた集中力、完全な関与、楽しさの感覚に完全に浸っている精神状態を指す（ゾーン状態とも言い換えることができる）
  • フィードバックループ
    • 実行されたアクションに対する応答の速度と品質を指す
  • 認知負荷
    • 開発者がタスクを完了するための必要な精神的処理の量を指す

これら3つの主要な領域に焦点を当てることで、開発組織・チームは改善に向けた一歩を踏み出すことができます。

どんな成果が得られるのか

これら3つの側面が改善されると、誰にとって、どんな成果が得られるのでしょうか。以下、論文から抜粋した研究結果です。

Outcomes

When considering the outcomes of development work or the developer experience, many researchers and people think about productivity.8,21 In our years of experience, however, we have seen that the improvements in developers' work go far beyond personal productivity for individual contributors,16 to include team and organizational outcomes.7,11 This investigation considers outcomes at the developer, team, and organizational levels, which is supported by WDT.23

Developer outcomes

Developer outcomes are those that benefit an individual developer. In particular, prior WDT research shows that improved work design positively influences job performance, creativity,22 and learning5—three outcomes investigated in this study.

Team outcomes

Team outcomes are those that can benefit an individual developer but more likely accrue at the team level of work and are therefore operationalized and studied at this level. WDT also shows that outcomes such as quality benefit teams.22 In the context of DevEx, we want to capture how work design can impact the quality of the system the team can work in, and therefore capture this as code quality and technical debt.

Organization outcomes

Organization outcomes benefit a worker's employer.improvements in developer work positively affect an organization's profitability and its ability to achieve goals.

要するに、

  • 個人（開発者）の成果
    • 仕事のパフォーマンス、創造性、学習、燃え尽き症候群の軽減にプラスの影響をもたらす
  • チームの成果
    • コード品質、技術的負債にプラスの影響を与え、チームに利益をもたらす
  • 組織の成果
    • 組織の収益性と目標達成能力にプラスの影響をもたらす

「フロー状態」、「フィードバックループ」、「認知負荷」、これら3つの側面が改善されることで、個人の生産性を遥かに超え、チーム・組織へ正当な影響を与える。その結果、組織パフォーマンスの成果向上に繋がっていくのではないかと理解しました。

続編に向けて

いかがでしたでしょうか。開発生産性とは一体何なのか、なぜ開発生産性を高めなければならないのか（根幹の話）、開発生産性を高める上での課題は何なのか（ボトルネックの話）、そして開発生産性をどのように高めていくのか（手段の話）、少なくともこれらの方向性を整えていくことが重要なのかもしれません。

DevEx プロジェクトでは、DevEx の研究を基に「開発現場の開発者体験を定量化」することにしました。目的は、開発組織・チームの開発生産性を向上させるための課題発見です。 独自に開発者体験サーベイを設計し、フォースタートアップスの開発組織で「開発者体験に関するアンケート調査」を行いました。

次回のテックブログでは、「開発者体験に関するアンケート調査」を中心とした内容を予定しています。乞うご期待ください！

参考資料

文系出身でエンジニアは無理？そんなことないよ！

こんにちは！エンジニアの李です。 今年の4月にフォースタートアップス株式会社に新卒入社し、STARTUP DB（スタートアップデータベース）という国内最大級のスタートアップ情報を集約したプラットフォームの開発に携わらせていただいています。

目次

1. はじめに

  • 文系出身でもエンジニアになれるの？
  • エンジニアの楽しさとは？
  • フォースタートアップスのエンジニアはどんなことをしているの？

今回は、上記の3つの疑問を解消するような内容を中心に執筆してみました！ 最初にお伝えしたいことは、文系出身の私でもエンジニアとして活動できていること、フォースタートアップスのエンジニアは、約半数が文系出身で、学問関係なくめちゃくちゃ活躍していることです。

就活時代を振り返ると、いざ本当にエンジニアになろうと思った時、周りにエンジニアとして働いている方は全くいなかったので、情報が少なく非常に不安でした。 本記事を通して、そんな不安がちょっとでも解消されると幸いです！執筆自体が初めてのため読みづらい部分が多々あると思いますが、よろしくお願いします！

2. 自己紹介

大学では情報系とは全く関係ない言語学を専攻してました。 プログラミングを始めたのは、一年生の後期にコロナが流行り始めた頃です。「HTML・CSSができればフリーランスで月5万円稼げます！」みたいな動画を見つけたのがきっかけでした。実際はHTML・CSSだけできても案件を受注する力がなければ、月5万円稼ぐなんて到底夢のまた夢で難しい話でした。

ただ、実際に手を動かしてサイトを作ってみたり、検証ツールで普段自分が日常的にみていたサイトがどんなソースコードで動いているのかを知った時は、かなりワクワクしたのを覚えています。

大学3年時に、インターンの募集サイトで開発未経験でも募集していた学生ベンチャーを見つけて、10ヶ月ほど働いていました。Webサイトの画面を開発したり、WordPressの関数を作ったりしてました。

3. エンジニアの「魅力」

3.1 ゲーム感覚のような楽しさがある
個人的にエンジニアの業務には、カードゲーム、モンハン、推理ゲームのような楽しさがたくさんあると思っています。

「カードゲーム」
流行りの技術を取り入れたり、サービスの弱点を減らすような動きが常に行われています。 これは、最近流行っているデッキの傾向を把握したり、どんな構成で相手に挑もうかを考える部分に似ています！ 技術スキルが増えるほど、シナジーを発揮するのもあり、カードゲームでいう複数カードを揃えるとコンボが使えるようになる感覚に似ています！

「モンハン」
フォースタートアップスでは、アジャイル開発を採用しております。1週間のスプリントで開発する機能の優先順位を話し合って決め、スクラムボードから自分で対応するチケットを取っていきます。もちろん自分が全然わからないことに出くわすこともよくありますが、そんな時は上長に相談したり、一緒に考えて頂いたりします。

これは、モンハンでいう討伐クエストみたいだと思っていて、大型モンスターだったら上長ハンターに相談して弱点を伺ったり、攻略法を一緒に見つけにいく（例えば、氷属性っぽいから火属性使えばうまくいくんじゃないか）みたいな感覚に似ています！

3.2 思考の整理ができるようになる
私は、やらなければいけないことや目的がすぐに混線してしまい、頭の中の情報が散らかってしまうことがよくありました。

開発は常に情報過多で複雑です。情報の整理を常に行っているため、エンジニアスキルとして、思考の整理を学ぶことができます。

今では、悩み事ややらなければいけないことがあったら、それらをリストアップして関連付けや優先順位付けを行い、やるべきことと、やらなくて良いことを分けるような習慣がつきました。

3.3 貢献したことが目に見える
自分の書いたソースコードが価値に変わってユーザーに届くことで、ユーザーへの貢献が目に見えて積み上がっていきます。プログラムは実際に動くものだからより実感が湧きやすいです！

4. なぜフォースタートアップスに入社したのか？

学生ベンチャーでインターンをしていた経験があり、決まりきった仕組みの中で働くよりも、常に試行錯誤しながら効率化を図るような働き方が楽しいと思っていました。フォースタートアップスは少数のチーム体制であり、新卒でも裁量を持って働けるところに魅力を感じ入社を決めました。

5. フォースタートアップスの開発業務

フォースタートアップスで利用している技術スタックです。

5.1 インターンで学んだこと
入社から1ヶ月ほどは、開発課題に取り組みました。実際に使われている社内ツールを触り、ローカルに同等の機能を実装することが課題です。開発課題では、Rubyのプログラミング言語の理解やプロダクトに対する理解がかなり深まりました。また、わからないことがあったらすぐに上長に質問して教えていただける環境でしたので、楽しみながら開発課題に取り組むことができました！

開発課題を経てからは、社内ツールの機能改善や機能追加に携わらせていただきました。運用しているユーザー（社員）が目の前にいて、使い勝手や要件の詳細をすぐにヒアリングすることができました。要望や要件をもとに開発を進めるだけでなく、要件定義などの上流部分から携わらせていただけるので、非常にやりがいを持って働けました。

ユーザーの声をヒアリングするのは信じられないほどモチベーションに繋がります。

私が書いたソースコードを、上長がその場で丁寧に説明しながら修正してくださったことがありました。既存の関数を呼び出したり、冗長なソースコードを修正することで、私が書いた40行のソースコードがたったの4行にまとまりました。正直「こんなに書いたのに、、」という悲しい気持ちに少しなりましたが、ソースコードは常に入れ替わっていくものなので、自分以外の人にも意図が伝わるような可読性の高いソースコードを書くことが求められるような開発環境なんだ！と感動した覚えがあります。

5.2 フォースタートアップスならではのこと
5/15,16に開催された、「Climbers」というスタートアップ企業が集まる展示会にフォースタートアップスのSTARTUP DBがブースを出展し、参加しました。

セールスに関しては、ビジネスサイドが全て担当する企業も多いと思いますが、フォースタートアップスでは商談に同席してみたいと言えば、二つ返事でOKが出るくらい自由度の高い環境です。今回のイベントでは、実際のお客様に自分が開発に携わっているプロダクトを説明したり、お客様のニーズをヒアリングできる素晴らしい体験ができました！

6. 私が考えるエンジニアに「共通する」求められるスキルとは？

  • わからないことを「わかりません」と言える素直さ
  • わからないことを説明できるロジック
  • 要件の背景を探る推理力
  • 知らないことに対する好奇心

技術力は、経験に比例して伸びていくものだと考えています。そのため、技術力よりもエンジニアになりたいという気持ちの方が個人的には大事なのではないかと思います。

だからこそ「自分なんかが目指していいのかな？」なんて迷う暇があったら、今すぐエンジニアの世界に飛び込みましょう！

例えば、

  • 個人開発を始める
  • オフラインのエンジニアイベントに参加してみる
  • 未経験でも応募できるインターンに参加してみる
  • 企業説明会に参加してみる（フォースタートアップスでも歓迎します！リンクはこちら）

などはいかがでしょうか！