開発者の一日
すべての企業はソフトウェアを開発しています。それは外向けのアプリケーションであれ、社内アプリケーションであれ、その両方であれ同じです。すべての企業はソフトウェア開発をより効率的に行いたいと考えており、それは企業の成功と直接的な相関があります。GitLab は、開発、運用、セキュリティを含むアプリケーションデリバリープロセス全体を支える機能を提供することで、すべての企業がより良いアプリケーションを作る手助けをするポジションにいます。かつては、企業のソフトウェア開発を構想からデプロイまで支える単一のソリューションは存在せず、企業は特定の機能のために特定の製品を購入したり、メール、スプレッドシート、ドキュメントなどの手作業の方法を使って開発を追跡したりしていました。
「開発者の一日（Day In The Life of a Developer）」の目的は、企業の現在の開発プロセスを理解し、改善の機会を探し、そしてそれらの発見をステークホルダーに伝えることです。これらの改善機会は、エグゼクティブブリーフという形で伝え返すことができ、そこでは、顧客と共にそれらの改善を行うパートナーシップにおいて、どこに、どのように、どの程度の労力で取り組む必要があるかについての処方的なガイダンスを共有できます。
「開発者の一日」は、現在のプロセスがどのように機能しているか、改善できる領域はどこにあるかについて、より深いディスカバリーを可能にする企業によるデモンストレーションです。デモは通常、適切な参加者と、プロセスに関する活発なディスカッションを伴う 90 分のミーティング内で実施できます。
プロセス
- 「開発者の一日」の機会を見極める
- 参加候補者を教育し、ワークショップへのコミットメントを得る
- 「開発者の一日」の準備をする
- 初期の顧客向けピッチ
- 「開発者の一日」を計画する
- 「開発者の一日」のデモンストレーション
- エグゼクティブブリーフィング — 発見事項を要約する
- このフレームワークに貢献する
機会を見極める
「開発者の一日」は GitLab のフィールドチームと見込み客・顧客双方のコミットメントを必要とします。この時間投資に対する適切なリターンを確保するため、機会は以下の基準を満たす必要があります。
- アカウントの総アドレッサブル市場が少なくとも 100 GitLab ユーザー以上であること
- 見込み客または顧客が、ソフトウェアデリバリーパフォーマンスの向上に注力していること
- 経済的バイヤー（economic buyer）との関係を構築していること
- チャンピオン（champion）を特定し、関係を構築していること
- 企業のステークホルダーにとって重要なボトルネックや開発機会を理解するため、Proof of Value（PoV）の前に「開発者の一日」を提案することを推奨します。これにより、ディール成立に PoV が必要な場合に、価値ドライバーの成功基準について合意する機会も得られます。
「開発者の一日」がカスタマーサクセスマネージャー（CSM）によって実施される場合、以下の基準を満たす必要があります。
- チャンピオンを特定し、関係を構築していること
- アカウントの総アドレッサブル市場が少なくとも 100 GitLab ユーザー以上であること
- 顧客がソフトウェアデリバリーパフォーマンスの向上に強い意欲を示していること
機会が適していることを示す主な指標は以下のとおりです。
- 特定の日付までに以下のいずれか、または複数を達成する具体的なイニシアチブがある
- 特定のアプリケーションのモダナイゼーション
- 重要な新規アプリケーションの市場投入
- ソフトウェアデリバリー能力の変革または客観的な向上
- DevOps 機能のモダナイゼーション
- 顧客が現在 GitLab の一部の機能を使用しており、プラットフォームをより活用することがソフトウェアデリバリーの成果をどう推進するかに関心を持っている
- カスタマーサクセスにおいては、現在のソフトウェアデリバリープロセスのボトルネックを特定することで、新たなユースケースへの拡大や現状の採用改善の機会を「開発者の一日」によって発見できる
- 既存顧客が、ソフトウェアデリバリーパフォーマンス向上のために GitLab の「開発者の一日」アプローチを採用することに関心を示している
「開発者の一日」のスコープは常に明確に定義する必要があります。スコープが明確であることで、適切な人がチームに含まれ、注力すべき内容についての合意に時間を失うリスクが減ります。このため、GitLab がファシリテートするアセスメントのスコープは常に DevSecOps の領域内である必要があります。
教育とコミットメント
成功する「開発者の一日」には、ソフトウェアデリバリーのステークホルダーと、開発プロセスを構成する各種プロセスを経験している担当者のコミットメントが必要です。アセスメントプロセスとそれが組織にもたらす価値を理解しなければ、主要参加者は「開発者の一日」の成功を確保するためのコミットメントを欠くことになります。見込み客や顧客に、便益、プロセスの詳細、必要なコミットメントについて教育してください。
「開発者の一日」は高度なディスカバリーワークショップであり、初期の機会ディスカバリーと技術ディスカバリーが既に実施されていることが想定されています。
主な便益
- 現在の「開発者の一日」または「プロダクションへの道のり」のディスカバリーとドキュメント化
- ソフトウェアデリバリーパフォーマンスの進捗を測定するための合意されたベースラインを確立する
- 手作業の構成接点や引き継ぎ、その他のボトルネックを特定する
- プロセス改善ロードマップを作成する
- 価値デリバリープラットフォームの投資対効果を理解する
- DevSecOps ライフサイクル内で従来サイロ化していた機能間のコラボレーションを促進する
見込み客や顧客がプロセスとその便益を理解した後、ファシリテーション付きのワークショップやインタビューをスケジュールすることで、ステークホルダーおよびワークショップ参加者からのコミットメントを確認します。アセスメントの所要時間を見積もり、文書化されたソフトウェア開発プロセス、推奨事項、リードアウト（読み上げ）が提供されることへの期待を設定します。
必要な時間的コミットメントは？
上記の目標と便益に焦点を当てた場合、最小限の有用な「開発者の一日」を完了するのに必要な時間は組織によって異なります。ワークショップは網羅的な議論や調査を必要とすべきではありません。各種参加者やステークホルダーの可用性とコミットメント次第ですが、デモンストレーションとディスカバリーは 90 分から 2 時間程度で実施できます。
準備
アカウントチーム
ピッチ前に、アカウントチームは以下を行うべきです。
- エグゼクティブスポンサー、ステークホルダー、参加者を特定する
- ビジネス目標を特定する
- 「開発者の一日」のデモ用にアプリケーション/プロジェクトを特定する。これは重要なステップで、明確な始まりと終わりがあり、遅延を測定できる可能性のある単一のフローにディスカバリーを集中させるためです。プロジェクトは、ビジネスが改善したいと考えている、構想からデプロイまでをカバーする重要または典型的な開発プロセスを反映したものでなければなりません。
SA
通常、ディスカバリーを通じて、開発の観点から見た顧客の目標と現在の開発プロセスについてはある程度知識があります。「開発者の一日」のゴールは、構想から本番デプロイまでの開発プロセス全体を理解し、その全体を通して改善領域を探すことです。
「開発者の一日」の準備として、すでに把握している顧客に関する情報を整理し、より詳しく知りたい領域を特定します。これには、ミーティングに対する GitLab のゴールを含めるべきであり、それはカスタマーサクセスプランと整合している必要があります。
学びたい項目のリストに対して事前に質問を準備します。質問は GitLab Value Framework から引用できます。
ワークショップ中のリアルタイムコミュニケーション用に、社内コミュニケーション媒体（例: Google Doc や Slack）を選びます。これによりチームが質問の調整をしやすくなります。
ピッチ
SA が行う最初の顧客向けピッチでは、主要ステークホルダーを特定し、ステークホルダーの賛同を得ます。顧客向けピッチには以下を含めるべきです。
- 「開発者の一日」とは何か？
- 「開発者の一日」には何が含まれるか？
- 「開発者の一日」の主要参加者は誰か？
- 顧客にとって「開発者の一日」のおおよその期待されるアウトカムは何か？
ピッチの出発点として活用できるリソースは以下のとおりです: 顧客向けピッチデック 社内ピッチデック
顧客との計画ミーティング
「開発者の一日」の計画は、適切な期待値、フォーカス、関係者がそろえば 1 時間以内で完了できます。以下は「開発者の一日」を計画する際に考慮すべき点です。
「開発者の一日」を定義する
- アプリケーション開発に関わるチームメンバーは誰か？
- 構想からデプロイまでの開発を示すために、どのアプリケーションをデモするか？
- どのようなコンテキストや条件が考慮されているか？
- 開発プロセスを通じた作業を発生させる、トリガーとなる出来事は何か？
「開発者の一日」のデモンストレーション
- 人
- プロセス
- ツール
- ワークフロー
- 質問
人
「開発者の一日」のファシリテーションを支援するため、複数の GitLab チームメンバーが参加する必要があります。これらのメンバーの役割は、概ね以下のとおりです。
- ファシリテーター — ソフトウェア開発プロセスに精通したチームメンバー。セッションを主導し、議論がトピックから逸れないように、適切なレベルとペースで進むようにする責任があります。
- アカウントリーダー — 望ましい将来の状態について議論する際に、顧客/見込み客の長期的な戦略ビジョンが考慮されるようにする責任があります。また、現状について追加のコンテキストを提供することもできます。
- 書記 — セッションを文書化し、後で現在の状態を示す概略図を作成するために使われる主要な指標を、その場で記録することを主な目的とするチームメンバー。
プロセス
実施するプロセスはハイレベルでは以下のとおりです。
- なぜここに集まっているのか？（チャンピオンが主導）
- 計画ミーティングで設定された期待を再確認する
- 「開発者の一日」の開始点と終了点
- 現状
- 見込み客や顧客がデモするための初期プロセスの「ウォークスルー」 — ベストプラクティスは、顧客環境に対する（おそらく限定的な）我々の理解に基づいた現状図を共有して「開発者の一日」の議論をファシリテートすることです
- 人、プロセス、テクノロジーを記録する
- 分析を行い、ボトルネックや改善領域を特定する
- 時間は限られています — 準備中に選択したディスカバリー質問のリストを使用し、GitLab が支援できる領域に集中・「ダブルクリック」してください。GitLab が影響を及ぼせない領域に深く入り込むのは避けます
- 見込み客や顧客がデモするための初期プロセスの「ウォークスルー」 — ベストプラクティスは、顧客環境に対する（おそらく限定的な）我々の理解に基づいた現状図を共有して「開発者の一日」の議論をファシリテートすることです
- 将来の状態を設計する
- 期待を見直し、チームが目指す目標について整合させる
- 「正しい仕事（right work）」を決定する（最適な将来の状態のためにどのプロセスとステップが必要か）
- プロセスやステップが本当に不要であれば取り除く
- プロセス全体時間とリードタイムを最適化できるなら、プロセスやステップを追加する
- 最適化されたワークフローを作成する
- 可能な限りすべてのプロセスブロックで、リードタイム（LT）、プロセスタイム（PT）を短縮し、より高い完了・正確率（%C&A）を達成することを目指します
- 該当する場合は、開発プロセスを改善するために GitLab の機能を活用する
- リーンの対策ツールや改善ツールを使う
- 顧客に学んだ内容の優先順位付けを依頼し、見落としがないか確認する
- 変革計画を策定する（おそらく非同期で完了させる）
- 「開発者の一日」セッションの最後に、ドラフトのアウトプットのレビュー日を提示する準備をしてください。ただし最終リードアウトの日付には commit しないでください。タイムラインを守ることは、案件の勢いを維持し、チャンピオンの信頼性を確保するために重要です。場合によっては、顧客から得たフィードバックがリードアウトの全面的な再検討につながることがあり、当初の計画よりも時間がかかることがあります。
- 顧客に提示する「開発者の一日」リードアウトを作成する。リードアウトには、現在の開発プロセスのレビューとプロセス改善の提案が含まれます。
- 各プロセスブロックの変革に対して、測定可能な目標、提案する対策、実行方法、オーナー、タイムライン（後にステータスも）を記録する
ツール
- リモート:
- Zoom、MS Teams、または Google Meet
- 図表作成ツール
- 現状と将来の状態の可視化のための FigJam または LucidChart
- FigJam はまだ Okta に接続されていません。Google アカウントでログインしてください。読み書きアクセスを持つ
FullFigJam ライセンスを保有していることを確認してください（読み取り専用モードの場合は、フルライセンスをリクエストする必要があります）。 - LucidChart は IT 管理アプリケーションです。LucidChart アクセスがあるか不明な場合は、ブラウザの Okta インターフェイスに移動して “Search Your Apps” を選択し、
LucidChart SSOが利用可能か確認してください。利用可能であれば LucidChart があなたに割り当てられており、Okta から起動して、チームが共有している任意の LucidChart ドキュメントで共同作業ができます。利用できない場合、LucidChart SSOはまだ割り当てられていません。 - Okta で
LucidChart SSOが割り当てられていない場合は、“access-requests” プロジェクトに移動し、“Lucid Chart” をリクエストする Issue を提出してください。Issue をマネージャーにアサインし、IT::to doラベルを追加します。アクセスリクエスト Issue の例を参照してください。 - アクセスリクエストが緊急の場合は、Slack チャンネル
#it_helpにアクセスリクエスト Issue のリンクを貼り、it-helpを @ メンションして、なぜ緊急なのかを記載してください。
- FigJam はまだ Okta に接続されていません。Google アカウントでログインしてください。読み書きアクセスを持つ
- オンサイト:
- 付箋
- ペン
- 大きなホワイトボード
ワークフローの例
- 構想からプロダクションへ
- プロダクションインシデントへの対応
- ツールチェーンのアップグレードとメンテナンス
構想からプロダクションへ
プロダクションインシデントへの対応
ツールチェーンのアップグレードとメンテナンス
エグゼクティブブリーフィング — 発見事項を要約する
「開発者の一日」プロセスの一環としての最終ミーティングは、発見事項と次のステップのプレゼンテーションです（エグゼクティブプレゼンテーションと呼ばれていますが、双方向のディスカッションが想定されています）。このミーティングのハイレベルなトピックは以下のとおりです。
- 計画段階のアウトカムの要約。どのプロセスをマップ対象としたか、どのような目標が作成されたか
- 現状マッピングの要約
- 提案された将来の状態のマッピングの要約
- 主要な差異、期待されるプロセス・ビジネスの便益のハイライト
- 推奨事項のウォークスルー
- 変革計画のウォークスルーと合意の獲得。変革計画は、最良の結果を得るためにプロフェッショナルサービスと共同で構築すべきです。案件におけるプロフェッショナルサービスのポジショニング方法についてはこちらを参照してください。
- 次のステップを定義し、レビュー日を提案する
エグゼクティブブリーフィングのテンプレート例はこちらから確認できます。顧客のニーズに合わせて適宜修正してください。
最終ミーティングの前に、チャンピオンや主要ステークホルダーとエグゼクティブブリーフィングをレビューして、追加のフィードバックを集めることをお勧めします。その上で、より広いチームに共同で提示し、合意を得ることを目指します。
顧客/見込み客からのよくある質問
顧客にとってのメリットは？
- ソフトウェアデリバリーライフサイクルの現状、将来像、改善領域を含む、無料でハンズオンのコンサルティング分析
- 業界の同業他社との比較における自社の位置に関する競合分析。このレポートには 4 つの DORA メトリクス（DevOps パフォーマンスの良い指標として広く認められている）の最新ベンチマーク値が含まれます State of DevOps Report 2024。
- 将来像に到達するための戦略的計画とともに、見える/見えにくい課題を克服する方法に関する推奨事項
顧客にとっての典型的なアウトカムは？
- TBD
通常どのチームが関与しますか？
- アプリケーション開発チームから始め、品質エンジニアリングチーム、アプリケーションセキュリティ、そして運用チームへと進みます。
始めるのに最適な場所は？
- 最もビジネス上重要なアプリケーション、または市場投入までの時間要件が短い代表的なアプリケーションを選びます。
これは私たちのチームから多くの時間を要します。または、私たちのチームは他のプロジェクトで忙しいです。
- 「開発者の一日」のフォーカスされたディスカバリーには、デモを含めて約 1.5 時間かかります。
トレーニングとイネーブルメント
貢献方法
コラボレーションとイテレーションの精神に基づき、このフレームワークの継続的な改善にご協力ください。貢献方法は以下のとおりです。
- このページを改善するためのマージリクエストを作成する
- #customer-success および #solutions-architects Slack チャンネルでご自身の経験を共有する
- ピッチデックへのフィードバックや更新を提供する、または独自のバリエーションへのリンクを提供する
- ファシリテーションの録画、要約ドキュメント、その他の成果物へのリンクをこのページに提供する
- #value-stream-discovery Slack チャンネルで共同作業する
bfd74782)