Flagship_Tech Onboarding for Product Team #2

Tech Onboarding #2 for Flagship Product Team

Recap Activity (前回セッションの学び共有) Tech Onboarding #1 での実践的な学びを共有しましょう （同時多発的に、Slackに投稿をお願いします）。何件かピックアップしたものを説明してもらいます。 #pdt-tech-onboarding-202601 実践したこと 証跡の共有 目的 日常業務の中で実際に「使った」「意 可能であれば、GitHubやAIチャッ ト、思考整理のスクリーンショットを Slackに投稿してください。 「聞いた話」で終わらせず、実務につ 識した」ことは何ですか？ ながった事例として定着させること が目的です。

Prerequisites (事前宿題) セキュリティ設定 • SSH公開鍵の登録: GitHubアカウントに自身のSSHキーを登 録してください。 • 使用デバイス: MacBookで生成したSSHキーを使用してくだ さい。 当日の実施内容: • リポジトリの clone • 変更の commit • Pull Request 作成 • マージ

Prerequisites (前提事項) 本日必要な各種権限 • GitHubレポジトリの権限確認: https://github.com/flagship-llc/pdt-tech-onboarding-202601 本日使わないもの • Antigravity IDE • GitHub Desktop

• https://github.com/flagship-llc/pdt-tech-onboarding-202601

0. Opening (開発の解像度を上げる) 今日の真のゴール そのための前提 • 開発業務の解像度UP • GitHubはエンジニアだけのツールではありません。 デベロッパーが日常的に何をしているか、そのプロ セスを具体的に理解する。 • コンフリクト（衝突）やレビュー（指摘）は、より良い製 • 「わからない」からの脱却: 品を作るための「建設的な対話」です。 「開発のことは詳しくないから…」と遠慮せず、仕組 みを理解して会話に参加する。 • 品質への貢献: 開発プロセスに参加し、プロダクト改善に直接コミッ トする。 • 恐れずに触ってみることが、理解への近道です。

1. GitHubの世界観 思想とワークフロー

GitHubは単なる「コード管理ツール」ではありません。 衝突と意思決定 を安全に扱うための仕組みです。 — 1.1 GitHubの思想 PR = 提案 Review = 議論 Merge = 合意 Proposal) Discussion) Consensus)

1.1 GitHub 基本用語の理解 リポジトリ Repository) コミット Commit 「プロジェクトの保管場所」 「歴史のセーブポイント」 ファイルや変更履歴のすべてが保存されているデータベー 「何をしたか」というメッセージと共に保存される、変更の最 ス。プロジェクトの「本拠地」です。 小単位。いつでもここに戻れます。 ブランチ Branch main / master 「安全な作業用の並行世界」 「唯一の正解（本番環境）」 本番環境（main）から分岐したコピー。ここで何をしても、本 全員が共有する最新の安定版。ここにあるコードは常に動 番には影響しません。 く状態であることが求められます。

1.1 GitHub 基本用語の理解 プルリクエスト PR マージコンフリクト 「統合の提案書」 「変更の衝突」 「自分のブランチでの変更を、mainに取り込んでください」と 同じファイルの同じ箇所を、別々の人が同時に変更した場 いうリクエスト。ここでレビューや議論が行われます。 合に発生。どちらを採用するか、どう統合するかを人が判断 します。

pull_request_template.md 1.2 ワークフロー実習 (ディレクトリ構成と役割) README.md このリポジトリの目的。 groups/*.md (非プロダクトメンバー向け) 自分たちの「チーム紹介」や「やっていること」を記載。 apps/*.md (プロダクトチーム向け) Shopify Appの概要（解決する課題、ユーザー、今後の展望）。 pull_request_template.md PR作成時のテンプレート。ここが学習の核となります。 実施内容の手順はこちら： https://github.com/flagship-llc/pdt-tech-onboarding-202601

• https://github.com/flagship-llc/pdt-tech-onboarding-202601

(Recap) Markdown記法とSlackの簡易版 Markdown エンジニアが平時の文書管理に使う、かつ、AIがデータソースとして最も読みやすい構造化方式です。 機能 一般的な Markdown 太字 斜体 コード（インライン） 取り消し線 ※ Markdownでの改行は、行末に「スペース2つ」が必要です。 Slack (mrkdwn)

その他、よく使う Markdown記法 見出し # 見出しレベル1 ## 見出しレベル2 Bullet List - 順序なしリスト ● 文頭に* + -のいずれかを入れると順序なしリストになります ● 要点をまとめる際に便利です ● * + -の後には スペースが必要です Markdown記法チートシートから、まだ紹介されていないMarkdownを何か選んで使ってみよう！ https://qiita.com/Qiita/items/c686397e4a0f4f11683d

• https://qiita.com/Qiita/items/c686397e4a0f4f11683d

1.3 レビュー体験 (+ CodeRabbit) 人のレビューを補完する存在 CodeRabbitは、機械的・網羅的なチェックを行いますが、人のレ ビューを完全に置き換えるものではありません。 CodeRabbitの得意 人の役割 • 命名・可読性 • プロダクトの意図 • 潜在的バグ • 設計・リスク判断 • 一貫性のチェック • 「なぜ」の背景 "指摘をそのまま直すのではなく、考えるきっかけとして使う"

4. AIプロンプティング (思考パートナー) 「指示待ち」ではなく「文脈理解装置」 良いプロンプトは、良い仕様書のようなものです。AIに役割と文脈 を与えましょう。 基本フレームワーク ①役割 Role AIは何者として振る舞うべきか？ ②1 背景 Context): 必要な前提知識は？ ②2 制約 Constraints): 避けるべきことは？ ③出力 Output 欲しい形式（コード、表など）

まずはやってみよう！ 🚀 演習問題： 下記の「カンマ区切りの好きな食べ物一覧」が、スプレッドシートの セル A1 に入っています。 これを 「縦一列」に展開するための数式 をAIに聞いて、実際にスプレッドシートで実行してください。 AIとのやり取りが少なければ少ないほど良いプロンプトです！GOGO！！ ➡ 元データ りんご, カレー, もも, ハンバーグ, ポテト, 天ぷら, お寿司, チーズ, いくら, コーンスープ , お味噌汁

なぜプロンプトが重要なのか？ AIは「有能な右腕」 知識は膨⼤だが指⽰待ち AIは驚くべき知識を持っていますが、指 ⽰が曖昧だと期待通りの成果を出せませ ん。 「なんとなく」は通じないため、的 確な指⽰出し（マネジメント）が必要で す。 ⾔葉で超えるスキルの壁 プロンプトの質 = スピード 関数やコードを暗記していなくても⼤丈 夫。 「やりたいこと」を正しく⾔語化で きれば、AIがエンジニアリングを代⾏し てくれます。 良いプロンプトは、数時間の調査や作 業を「たった数秒」に短縮します。 試 ⾏錯誤の時間を減らし、本来の業務に 集中できます。

STEP 1: 現状理解 なぜ「⼀発」で正解が出ないのか？ 〜「空気を読んで」はAIに通用しない〜 情報の解像度を上げて「条件のガードレール」を引いてあげよう ツールの指定は明確か？ 「表を作って」だけでは不⼗分。 Excel？ Googleスプレッドシート？ CSV？ 曖昧さはAIを「迷⼦」 にさせる 「いい感じにしておいて」は⼈間同⼠の⽂ 脈があってこそ成⽴します。 AIにそれは通⽤しません。指⽰が少しでも 曖昧だと、AIは確率論で「推測」を始め、 期待外れの回答を⽣み出します。 データの場所はどこか？ 「このデータを直して」では通じない。 「シート1のA列にあるデータ」と住所を指定する。 例外（エッジケース）の無視 「空⽩セルがあったらどうする？」「全⾓半⾓は？」 細かいルールが決まっていないとAIは悩みます。

STEP 2: 基本フレームワーク ⼀発合格のための「⻩⾦の3要素」 〜プロンプトの構成要素を分解する〜 PROMPT DEFINITION ① 役割 AIの「⽴ち位置」や「専⾨性」を定義す る。 「あなたはGoogleスプレッドシートの達人です。初心者にもわ かりやすく教えてください 」 WHO PROMPT DEFINITION ② 背景‧制約 前提条件や守るべきルールを明確にす る。 「A1セルにあるカンマ区切りの値を、 B列に縦に展開して。余計 なスペースは削除してください 」 CONTEXT PROMPT DEFINITION ③ 出⼒形式 FORMAT 最終的な成果物の「形」を指定する。 「説明は省いて、コピーしてそのまま使える数式だけを出力して ください」

SUMMARY 「⾔語化」できる⼈は、AIを使いこなせる 01 「やりたいこと（仕様）」を定義する スキルがなくても⼤丈夫。AIを動かすために必要なのは、プログラ ムを書く⼒ではなく「何を作りたいか」を明確に⾔葉にする⼒で す。 02 呪⽂より「構造」を伝える 特定の関数の名前を暗記する必要はありません。「役割‧背景‧出⼒ 形式」という構造（フレームワーク）を使って意図を伝えましょう。 03 「対話」を恐れない ⼀発で正解が出なくても失敗ではありません。「ここが違うから、こ う変えて」と追加で指⽰を出せば、AIはすぐに修正してくれます。

明日からの期待 Ship Fast Review First 小さいPRを早く出す。 レビューは前提。 Ask AI まずAIに考えさせる。 "完璧なコードより、共有されている判断の⽅が価値がある。 GitHubもAIも、そのための道具です。"