朝 9 時、チームメンバーが集まるオンライン会議室。 「昨日は React のユーザー一覧コンポーネントを作りました。今日は CSS のスタイリングをやります。困っていることは特にありません」 そんな機械的な報告が 15 分間続いて、「お疲れ様でした」で終了。

私は心の中で叫んでいました。「これって意味あるの？」 フロントエンドエンジニアとして 5 年間様々なチームで働く中で、デイリースクラムが「義務的な報告会」と化している現場を数多く見てきました。 本来はチームの連携を深め、問題を早期解決するための貴重な時間が、単なる進捗確認の場になってしまっているのです。

そこで私は、従来の「昨日・今日・困りごと」という 3 つの質問を根本的に見直し、チームを真のエンジンにする「3 つの問いかけ」を開発しました。 この新しいアプローチにより、チームの連携度が劇的に向上し、開発効率とメンバーのエンゲージメントが大幅に改善されました。 その具体的な手法と成果を、皆さんと共有したいと思います。

背景と課題

形骸化したデイリースクラムの実態

私が参加していた Web アプリケーション開発チームでは、深刻な問題が発生していました。 毎朝のデイリースクラムが、本来の目的を見失った「報告会」になってしまっていたのです。

典型的な形骸化パターン

makefileCopy code開発者A: 「昨日はログイン画面のバリデーション実装。今日はエラーハンドリング」
開発者B: 「昨日はAPIの接続テスト。今日はレスポンシブ対応」
開発者C: 「昨日はUIコンポーネントの修正。今日は新しいページ作成」

この繰り返しで 15 分が過ぎ、誰も他のメンバーの話を真剣に聞いていませんでした。 特にリモートワークが増えてからは、ミュートにして他の作業をしながら「聞いているふり」をするメンバーも現れました。

見えない問題の蓄積

情報の断片化

• 各自が個別のタスクを報告するだけで、全体像が見えない
• 関連する作業をしているメンバー同士が気づかない
• 同じような問題を複数人が別々に解決している

チーム感の欠如

• 「自分のタスクだけやればいい」という個人主義的な雰囲気
• 他のメンバーがどんな課題に取り組んでいるか関心が薄い
• 困ったときに「誰に相談すればいいかわからない」状況

チーム間の情報共有不足と重複作業の発生

フロントエンド開発において、この問題は特に深刻でした。

具体的な重複作業の例

API 連携の重複実装

javascriptCopy code// 開発者Aが実装
const fetchUserData = async (userId) => {
  try {
    const response = await fetch(`/api/users/${userId}`);
    return response.json();
  } catch (error) {
    console.error('User fetch error:', error);
  }
};

// 同時期に開発者Bも似たような実装
const getUserInfo = async (id) => {
  const result = await fetch(`/api/users/${id}`);
  if (!result.ok) throw new Error('Failed to fetch');
  return result.json();
};

この例では、2 人が同じようなユーザー情報取得関数を別々に実装していました。 もしデイリースクラムで「今日はユーザー情報の取得機能を実装する予定です」と共有していれば、片方が「私も同じことやってます！一緒にやりませんか？」と提案できたはずです。

CSS スタイルの重複とコンフリクト

cssCopy code/* 開発者Aのスタイル */
.button-primary {
  background-color: #007bff;
  padding: 12px 24px;
  border-radius: 4px;
}

/* 開発者Bのスタイル（同じ意図、異なる実装） */
.main-button {
  background: #007bff;
  padding: 12px 20px;
  border-radius: 6px;
}

デザインシステムの統一性が損なわれ、後でリファクタリングに多大な工数を要することになりました。

個人タスクの報告に終始する非効率性

タスク報告の問題点

従来のデイリースクラムでは、以下のような非効率性が常態化していました：

表面的な進捗報告

• 「作業をしている」という事実の報告にとどまる
• なぜその作業をしているのか、どんな価値を生むのかが不明
• チーム全体への影響や関連性が見えない

問題の隠蔽

makefileCopy code実際の状況: TypeScript の型定義で2日間ハマっている
報告内容: 「順調に進んでいます」

このような隠蔽により、本来なら 30 分で解決できる問題が数日間放置されることが頻発していました。

学習機会の損失

• 個人が直面した技術的チャレンジが共有されない
• 解決方法やベストプラクティスが属人化
• チーム全体のスキル向上が停滞

特にフロントエンド開発では技術の変化が激しく、個人の学習をチーム全体で共有することの価値は計り知れません。 しかし従来のデイリースクラムでは、そうした学習共有の機会が完全に失われていました。

試したこと・実践内容

従来の 3 つの質問から脱却した新しいアプローチ

私はまず、アジャイル本来の目的に立ち返ることから始めました。

従来の問題のある質問

markdownCopy code❌ 従来の質問:

1. 昨日何をしましたか？
2. 今日何をしますか？
3. 困っていることはありますか？

問題点の分析

• 過去と未来の報告に集中し、「今」のチーム状態が見えない
• 個人の作業に焦点が当たり、チーム連携の視点が欠如
• 困りごとを聞いても、表面的な回答で終わりがち

新しいアプローチの設計思想

私は以下の原則に基づいて、新しい問いかけを設計しました：

javascriptCopy codeconst designPrinciples = {
  teamFirst: 'チーム全体の価値創出を優先',
  futureOriented: '今日のチーム成果にフォーカス',
  collaborationDriven: '連携と支援を促進',
  learningCentered: '学習と改善を重視',
  actionable: '具体的なアクションにつながる',
};

「チームのエンジン」となる 3 つの問いかけの設計

新しい 3 つの問いかけ

markdownCopy code✅ チームエンジン型の質問:

1. 「今日、チームの誰かと一緒にできることはありますか？」
   → 連携と協働を促進

2. 「今日、チーム全体に共有したい発見や気づきはありますか？」  
   → 学習とナレッジの共有

3. 「今日、誰かからサポートが欲しいことはありますか？」
   → 支援とブロッカー解除

各質問の詳細設計

質問 1: チーム連携の促進

javascriptCopy code// 質問1が引き出す具体例
const collaborationExamples = {
  codeReview:
    '新しいReactフックのレビューを一緒にやりませんか？',
  pairProgramming:
    'TypeScriptの型定義、一緒に考えてもらえますか？',
  designReview:
    'UIコンポーネントのデザイン確認、お時間ある方いますか？',
  testing: 'E2Eテストのシナリオ作成、手分けしませんか？',
};

質問 2: ナレッジ共有の活性化

javascriptCopy code// 質問2が引き出す学習共有の例
const knowledgeSharing = {
  technicalTips: 'CSS Grid の便利な使い方を発見しました',
  toolsAndTechniques:
    'ESLint の新しいルールで品質が上がりました',
  problemSolving:
    'パフォーマンス改善で試した手法を共有します',
  bestPractices:
    'React のカスタムフックでコードが整理できました',
};

質問 3: 支援文化の醸成

javascriptCopy code// 質問3が引き出すサポート要請の例
const supportRequests = {
  technicalHelp:
    'GraphQL のクエリ最適化でアドバイスください',
  codeReview: 'アーキテクチャ設計の考え方を相談したいです',
  troubleshooting: 'ブラウザ互換性の問題で詰まっています',
  mentoring:
    'React Testing Library の使い方を教えてください',
};

ファシリテーション手法の改善と実践

効果的な進行方法

タイムボックスの最適化

markdownCopy code従来（15 分）:

- 各人の報告 3 分 × 5 人 = 15 分

改善後（15 分）:

- チェックイン（2 分）
- 質問 1 ラウンド（4 分）
- 質問 2 ラウンド（4 分）
- 質問 3 ラウンド（3 分）
- アクションアイテム確認（2 分）

視覚的な支援ツールの活用

私は Miro を使って、リアルタイムでチームの状況を可視化するダッシュボードを作成しました：

javascriptCopy code// デジタルホワイトボードの構成例
const dailyScrumBoard = {
  collaboration: {
    title: '今日の協働',
    items: [
      { pair: 'Alice & Bob', task: 'API設計レビュー' },
      { pair: 'Carol & Dave', task: 'CSS設計相談' },
    ],
  },
  discoveries: {
    title: '共有したい発見',
    items: [
      { author: 'Alice', topic: 'React 18の新機能活用' },
      { author: 'Bob', topic: 'Webpack設定の最適化' },
    ],
  },
  support: {
    title: 'サポート要請',
    items: [
      { requester: 'Carol', need: 'TypeScript型設計相談' },
      { requester: 'Dave', need: 'テスト戦略のアドバイス' },
    ],
  },
};

心理的安全性を高める工夫

「失敗共有」の奨励

markdownCopy codeポジティブフレーミングの例:

- 「昨日ハマった問題」→「みんなも気をつけたい発見」
- 「わからないこと」→「チームで解決したいチャレンジ」
- 「時間がかかりすぎた」→「効率化のアイデア募集」

「小さな成功」の共有

javascriptCopy codeconst microSuccesses = {
  technical: 'バグを1つ修正できました',
  learning: '新しい概念を理解できました',
  collaboration:
    'レビューで良いフィードバックをもらいました',
  efficiency: '作業時間を短縮できました',
};

リモートワークでの実践工夫

非同期情報共有の組み合わせ

• 事前に Slack でキーポイントを共有
• デイリースクラムでは対話と連携に集中
• 事後にアクションアイテムを文書化

エンゲージメント向上の仕掛け

javascriptCopy code// Slack Bot による事前準備
const preDailyScrumReminder = {
  message: `
🌅 今日のデイリースクラム準備
以下を考えてきてください：
1. 誰かと一緒にできそうなこと
2. チームに共有したい気づき  
3. サポートしてほしいこと
  `,
  timing: '30分前',
  channel: '#daily-scrum',
};

気づきと変化

Before/After：チーム連携度と問題解決速度の向上

新しいデイリースクラムの運用により、チーム全体の働き方が劇的に変化しました。

定量的な改善

Before（従来のデイリースクラム 3 ヶ月間）

• ペアプログラミング実施率: 週 2 回
• 技術相談・質問頻度: 日 1.2 件
• 問題解決にかかる平均時間: 2.3 日
• コードレビューでの学習共有: 月 3 件
• チーム満足度スコア: 3.1/5.0

After（新しいデイリースクラム 3 ヶ月間）

• ペアプログラミング実施率: 週 8 回（+300%）
• 技術相談・質問頻度: 日 4.7 件（+292%）
• 問題解決にかかる平均時間: 0.8 日（-65%）
• コードレビューでの学習共有: 月 15 件（+400%）
• チーム満足度スコア: 4.3/5.0（+39%）

連携パターンの変化

javascriptCopy code// Before: 個人作業中心
const oldWorkflow = {
  problemSolving:
    'individual → Google → StackOverflow → 時間消費',
  codeReview: '機械的なチェック → 最小限のコメント',
  learning: '各自が個別に調査 → 知識の属人化',
};

// After: チーム連携中心
const newWorkflow = {
  problemSolving:
    'チーム相談 → ペアプログラミング → 早期解決',
  codeReview:
    '学習機会 → 活発な議論 → ベストプラクティス共有',
  learning:
    'チーム全体で学習 → ナレッジ蓄積 → スキル底上げ',
};

コミュニケーション品質の劇的改善

対話の深化

従来の表面的な会話

makefileCopy code開発者A: 「React のコンポーネント作ってます」
開発者B: 「CSS やってます」
開発者C: 「API 接続してます」

改善後の価値ある対話

makefileCopy code開発者A: 「ユーザー認証のコンポーネントを作っているのですが、
         セキュリティの考慮点について相談したいです」
開発者B: 「私もセキュリティ関連やってるので、一緒に検討しませんか？」
開発者C: 「昨日JWT の実装で学んだことが役立つかもしれません」

技術的議論の活性化

javascriptCopy code// 実際に生まれた価値ある議論の例
const valuableDiscussions = [
  {
    trigger: 'React の状態管理で悩んでいます',
    outcome: 'Context API vs Redux の使い分けルールを確立',
    participants: 3,
    followUp: 'チーム全体での設計パターン統一',
  },
  {
    trigger: 'CSS の命名規則で迷っています',
    outcome: 'BEM記法の導入とスタイルガイド作成',
    participants: 4,
    followUp: 'デザインシステムの構築開始',
  },
  {
    trigger: 'TypeScript の型定義が複雑になってます',
    outcome: '型定義のベストプラクティス共有',
    participants: 5,
    followUp: '型安全性向上とリファクタリング',
  },
];

フロントエンド開発における協働効果の実現

コンポーネント開発の効率化

Before: 個別開発による重複

jsxCopy code// 開発者Aの実装
const UserCard = ({ user }) => (
  <div className='user-card'>
    <img src={user.avatar} alt={user.name} />
    <h3>{user.name}</h3>
    <p>{user.email}</p>
  </div>
);

// 開発者Bの類似実装
const ProfileCard = ({ profile }) => (
  <div className='profile-card'>
    <img src={profile.avatarUrl} alt={profile.userName} />
    <h2>{profile.userName}</h2>
    <span>{profile.emailAddress}</span>
  </div>
);

After: 協働による統一設計

jsxCopy code// チームで議論して設計した再利用可能コンポーネント
const UserProfile = ({
  user,
  size = 'medium',
  showEmail = true,
  onClick,
}) => (
  <div
    className={`user-profile user-profile--${size}`}
    onClick={onClick}
  >
    <Avatar src={user.avatar} alt={user.name} size={size} />
    <UserInfo
      name={user.name}
      email={showEmail ? user.email : null}
    />
  </div>
);

技術的負債の早期発見・解決

javascriptCopy code// デイリースクラムで発見された課題例
const technicalDebtDiscoveries = [
  {
    issue: 'webpack ビルド時間が10分を超えている',
    discoverer: 'Alice',
    supporters: ['Bob', 'Carol'],
    solution: 'バンドル分析とコード分割の最適化',
    timeToResolve: '2日（従来なら2週間放置）',
  },
  {
    issue: 'CSS の詳細度の競合が多発',
    discoverer: 'Bob',
    supporters: ['Alice', 'Dave'],
    solution: 'CSS-in-JS の段階的導入',
    timeToResolve: '1週間（従来なら1ヶ月放置）',
  },
];

ユーザー体験向上への集中

チーム連携が活性化されたことで、技術的な課題解決だけでなく、ユーザー価値の創出により集中できるようになりました。

markdownCopy codeUX 改善の協働事例:

- デザイナーとの連携強化 → UI/UX の一貫性向上
- QA エンジニアとの情報共有 → バグ修正の迅速化
- プロダクトオーナーとの対話 → 要件理解の深化

皆さんのチームでも、「一人で頑張る」から「チームで成長する」へのシフトができたら、どれほど開発が楽しくなるでしょうか？

他のチームで試すなら

段階的な問いかけ変更のロードマップ

私の経験を踏まえ、他のチームで実践する際の具体的なステップをご紹介します。

フェーズ 1：現状把握と準備（2 週間）

markdownCopy codeWeek 1: チーム状況の分析
□ 現在のデイリースクラムの録画・観察
□ チームメンバーへの匿名アンケート実施
□ 問題点と改善ポイントの特定
□ チームリーダー・PM との事前相談

Week 2: 導入準備
□ 新しい問いかけの説明資料作成
□ 試験運用の計画立案
□ チーム全体への説明と合意形成
□ 効果測定の方法確立

現状把握のためのアンケート例

javascriptCopy codeconst currentStateAssessment = {
  questions: [
    '現在のデイリースクラムで得られる価値は？（1-5点）',
    '他のメンバーとの連携頻度は？（週何回）',
    '技術的な相談をしやすい環境ですか？（1-5点）',
    '改善したい点があれば教えてください（自由記述）',
  ],
  targetResponseRate: '100%',
  anonymity: true,
};

フェーズ 2：段階的導入（4 週間）

Week 1-2: 1 つの質問から開始

markdownCopy code開始は最もハードルの低い質問 1 から:
「今日、チームの誰かと一緒にできることはありますか？」

進行方法:

- 従来の 3 質問の後に追加
- 最初は強制ではなく「任意参加」
- 良い事例が出たら積極的に称賛

Week 3-4: 全質問の導入

markdownCopy code全 3 質問を本格運用:

1. 連携促進の質問
2. ナレッジ共有の質問
3. サポート要請の質問

運用のコツ:

- 毎日全員が全質問に答える必要はない
- 「今日は特にないです」も立派な回答
- 小さな成功事例を積極的に共有

フェーズ 3：カスタマイズと定着（継続）

javascriptCopy code// チーム特性に応じたカスタマイズ例
const teamCustomizations = {
  juniorTeam: {
    focus: '学習とメンタリング',
    extraQuestion: '今日新しく学んだことは何ですか？',
  },
  seniorTeam: {
    focus: 'アーキテクチャと戦略',
    extraQuestion:
      '今日チーム全体の技術的方向性に影響することはありますか？',
  },
  crossFunctional: {
    focus: '部門間連携',
    extraQuestion:
      '他の部門との連携で必要なことはありますか？',
  },
};

チーム文化に応じたカスタマイズ方法

日本の組織文化への配慮

遠慮深い文化への対応

markdownCopy code工夫例:

- 「困っています」→「一緒に考えてもらえる方はいますか？」
- 「教えてください」→「アドバイスをいただけますか？」
- 事前に Slack で相談内容を整理してもらう

年功序列への配慮

javascriptCopy codeconst hierarchyAwareApproach = {
  seniorFirst: 'まずシニアメンバーから発言してもらう',
  mentorshipEmphasis: '教える・学ぶの相互関係を重視',
  respectfulLanguage: '敬語と丁寧な表現を維持',
  graduallyCasual: '徐々にカジュアルな雰囲気を醸成',
};

リモートワークチームでの工夫

非同期要素の組み合わせ

markdownCopy code朝のスクラム前（30 分前）:

- Slack で事前に 3 つの質問への回答を投稿
- 他メンバーの回答を確認して連携ポイントを把握

スクラム中（15 分）:

- 事前回答を基にした対話と合意形成
- 即座に決められることは決定
- 詳細議論が必要なものは別途時間確保

スクラム後（随時）:

- 決定されたペアワークや相談の実行
- 学習共有は専用チャンネルで継続

失敗パターンと継続のコツ

私自身が経験した失敗とその対策をお伝えします。

失敗パターン 1：形だけの変更

問題: 質問を変えただけで、本質的な改善に至らない

失敗事例

makefileCopy code新質問: 「誰かと連携できることはありますか？」
回答: 「特にないです」「今日は一人で作業します」
→ 結局従来と変わらない個人作業の報告

解決策: ファシリテーターの積極的関与

javascriptCopy codeconst facilitationTechniques = {
  proactiveConnection:
    '「AさんとBさん、同じような作業してませんか？」',
  knowledgeBridge:
    '「昨日Cさんが解決した問題と関連しそうですね」',
  encourageSharing:
    '「それ、他の人も知りたいと思います！」',
  followUpAction:
    '「じゃあ午後に30分、一緒に見てもらえますか？」',
};

失敗パターン 2：時間超過とグダグダ化

問題: 活発な議論が始まると時間が延びて、通常業務に支障

解決策: 厳格なタイムマネジメント

markdownCopy codeタイムキーピングルール:

- 各質問に最大時間を設定（4 分、4 分、3 分）
- 詳細議論は「パーキングロット」へ
- ファシリテーターは時間番人に徹する
- 長い議論は別途「深掘りタイム」を設定

失敗パターン 3：一部メンバーの独占

問題: 発言が活発なメンバーが時間を占有し、内向的なメンバーが参加できない

解決策: インクルーシブなファシリテーション

javascriptCopy codeconst inclusiveFacilitation = {
  roundRobin: '全員に順番に発言機会を提供',
  encourageQuiet: '「○○さんはどう思いますか？」',
  diversifyFormats:
    'チャット、投票、ブレイクアウトルームの活用',
  async: '事前のSlack投稿で全員の意見を確保',
};

継続のコツ

小さな成功の蓄積

markdownCopy code成功事例の見える化:

- 週次で「今週の連携成功事例」を共有
- 問題解決にかかった時間の短縮を数値で示す
- メンバーからの感謝の声を積極的に紹介

定期的な振り返りと改善

javascriptCopy codeconst continuousImprovement = {
  weeklyRetrospective: {
    what: 'デイリースクラムの効果',
    when: '金曜日の最後',
    how: 'KPT（Keep/Problem/Try）形式',
  },
  monthlyAdjustment: {
    what: '質問や進行方法の調整',
    when: '月末',
    how: 'チーム全体でのディスカッション',
  },
};

振り返りと、これからの自分へ

ファシリテーションスキルの重要性認識

この取り組みを通じて、私はフロントエンドエンジニアにとってもファシリテーションスキルが極めて重要だと確信しました。

技術者としての視点の拡大

Before: 「コードを書くことが最も重要」 After: 「チームが最高のコードを書ける環境を作ることも同じくらい重要」

特にフロントエンド開発では、デザイナー、バックエンドエンジニア、QA、プロダクトオーナーなど多様な職種との連携が不可欠です。 優れたファシリテーションにより、これらの連携を促進できることを実感しました。

対話設計の技術

javascriptCopy code// 身についたファシリテーションスキル
const facilitationSkills = {
  questionDesign: '目的に応じた効果的な問いかけの設計',
  timeManagement: '限られた時間での価値最大化',
  conflictResolution: '異なる意見を建設的な議論に導く',
  inclusiveLeadership: '全メンバーが参加しやすい場作り',
  actionOriented: '議論を具体的な行動につなげる力',
};

これらのスキルは、技術的な問題解決だけでなく、要件定義、設計レビュー、ユーザーテストの振り返りなど、様々な場面で活用できることがわかりました。

チームビルディング能力の向上実感

関係性の質の向上

デイリースクラムの改善により、チームメンバー間の関係性が劇的に向上しました。

変化の具体例

markdownCopy codeBefore:

- 業務上の最低限のコミュニケーション
- 困ったときに相談しづらい雰囲気
- 個人の成果に焦点が当たる文化

After:

- 積極的な相互支援と学習共有
- 「困ったときはお互い様」の文化
- チーム全体の成功を重視する価値観

心理的安全性の向上

javascriptCopy codeconst psychologicalSafety = {
  failureTolerance: '失敗を学習機会として捉える文化',
  questionEncouragement: 'どんな質問でも歓迎される環境',
  diversityRespect: '異なる意見や働き方への理解',
  supportiveAtmosphere: '互いを高め合う協力的な雰囲気',
};

特に印象的だったのは、新しく参加したジュニアエンジニアが「このチーム、質問しやすくて成長できます」と言ってくれたことです。

アジャイルマインドセットの深化

アジャイル本来の価値理解

markdownCopy codeアジャイル宣言の再解釈:

- 個人と対話 → デイリースクラムでの真の対話実現
- 動くソフトウェア → チーム連携による高品質な成果物
- 顧客との協調 → ユーザー価値を意識した議論
- 変化への対応 → 日次での迅速な方向修正

継続的改善の習慣化

javascriptCopy codeconst continuousImprovement = {
  dailyLevel: 'デイリースクラムでの小さな改善',
  weeklyLevel: 'スプリント振り返りでの中期調整',
  monthlyLevel: 'チーム運営方式の根本的見直し',
  quarterlyLevel: '組織全体への影響と貢献',
};

プロダクト思考の強化

デイリースクラムの改善により、単なる「機能実装」から「ユーザー価値創出」への意識変化が生まれました。

markdownCopy code思考の変化例:

- 「このコンポーネントを作る」
  → 「ユーザーの課題をこのコンポーネントで解決する」
- 「バグを修正する」
  → 「ユーザー体験の改善につながるバグ修正」
- 「新技術を導入する」  
  → 「チームの生産性向上とプロダクト品質向上のための技術選択」

皆さんも、日々のスクラムを通じて、単なる進捗管理を超えた「チーム成長のエンジン」を作ってみませんか？

まとめ

デイリースクラムの真価を活かしたチーム運営は、個人の成長とチーム全体の成功を同時に実現する強力な手法です。

私の経験から得られた核心的な学びは以下の通りです：

重要なポイント

1. 問いかけの力: 適切な質問設計がチームの行動と文化を変える
2. 連携の促進: 個人作業からチーム協働への転換が生産性を飛躍的に向上
3. 学習の共有: 日次での小さな知識共有が、長期的な技術力向上につながる
4. 支援文化の醸成: 助け合いが当たり前になる環境作りが持続可能な成長を生む

新しい 3 つの問いかけ（再掲）

markdownCopy code1. 「今日、チームの誰かと一緒にできることはありますか？」
2. 「今日、チーム全体に共有したい発見や気づきはありますか？」
3. 「今日、誰かからサポートが欲しいことはありますか？」

実践への第一歩

明日からでも始められることがあります：

• まずは 1 つの質問だけを既存のデイリースクラムに追加してみる
• チームメンバーと「理想的なデイリースクラムとは何か」を話し合う
• 1 週間だけ試験的に新しい形式でやってみる

小さな一歩から始めて、徐々にチーム全体の連携度と成長スピードを向上させていきましょう。

フロントエンドエンジニアとして、美しく機能的な UI を作ることと同じくらい、美しく機能的なチームコミュニケーションを作ることも重要です。 私たちの日々の対話が、より良いプロダクトとより良いチーム文化につながるよう、デイリースクラムの革新を一緒に実践していきませんか？