はじめに

ゴルフの練習では、どうしても早く球を打ちたくなります。

しかし、球を打つことだけが練習ではありません。クラブの本数を減らす、使える球数を決める、あえて球を打たずに素振りする。そうやって条件を制限すると、一つの動きや感覚に意識を向けやすくなります。

素振りでは、自分の動きや構えに向き合うため、球筋だけを追っていたときには気づかなかった違和感が見つかることもあります。

最近、これは文章作成やプログラミング、生成AIの活用にも似ていると感じました。

成果物を早く出したいときほど、すぐに書き始めたくなります。ただ、その前に短い「素振り」を入れて、目的や現在地を整理したほうが、限られた時間とリソースを有効に使える場合があります。

この記事では、私なりに考えた、技術者の仕事における『素振り』を、実務で使える形に整理します。

※本記事は個人の経験をもとにした整理メモです。手順やテンプレートは筆者が考えたもので、特定の開発手法や製品の公式な推奨ではありません。
※本文で参照しているGitHub公式ドキュメントの内容は、2026年9月9日時点で確認したものです。ドキュメントは更新されることがあるため、最新の内容は各リンク先でご確認ください。

先に結論

ここでいう「素振り」は、長い会議や完璧な計画を作ることではありません。

手を動かす前に、次の5点を短時間で揃えることです。

何のために取り組むのか
現在、何が分かっているのか
目指す姿とのギャップは何か
限られた条件の中で何を試すのか
何を見て次の判断をするのか

目的
  ↓
現在地
  ↓
ギャップ
  ↓
小さな実験
  ↓
結果を見て修正

重要なのは、準備だけで終わらず、次の小さな実験まで決めることだと思います。

その際、使える時間、環境、権限、予算、試行回数などの制約は、小さな実験を設計するための条件として扱います。

すぐに成果物を作りたくなる

技術者の仕事では、目に見える成果に意識が向きやすい場面があります。

文章を書いた
コードを実装した
AIに成果物を生成させた
チケットを完了した

そのため、「まず手を動かそう」という判断自体は間違いではありません。

一方で、次のような状態で始めると、進んでいるように見えて手戻りが増えることがあります。

誰のための成果物かが曖昧
完了条件が決まっていない
既に持っている材料を確認していない
分からないことと、まだ調べていないことが混ざっている
制約を考えず、最初から大きな完成形を狙っている

球を打ち続けながらフォームを直そうとすると、何が原因で結果が変わったのか分かりにくくなります。

仕事でも一度動きを止めて、自分が何をしようとしているのかを見直す時間が必要なのかもしれません。

制限すると、見るものを絞りやすくなる

ゴルフの練習では、あえて道具や球数を制限することで、一つのことに集中しやすくなる場合があります。

クラブの本数を減らし、一つの動きに集中する
球数を決め、1球ごとに試すことを明確にする
球を打たず、スイング中の感覚や違和感を確認する

これは開発業務にも置き換えられそうです。

ゴルフ練習での制限	開発業務への置き換え	フォーカスするもの
クラブの本数を減らす	使用する技術、ツール、変更範囲を絞る	今回確認したい一つの論点
練習球の数を決める	時間、試行回数、API呼び出し回数を決める	1回の試行から何を学ぶか
球を打たずに素振りする	コードを書かずに処理を追う、図にする、説明する	思い込み、違和感、理解不足

例えば、不具合調査で関連しそうなコードをすべて直し始めるのではなく、最初は失敗するテストを1件に限定します。生成AIへ何度も依頼する前に、試行回数を3回と決め、各回で変える条件を一つに絞ることもできます。

制限は、単に我慢することではありません。

選択肢を一時的に減らし、自分が何を試し、何を感じ、結果から何を考えたのかを見えやすくする仕組みだと捉えています。

特に生成AIを使うと、考える前にそれらしい成果物を作れてしまうことがあります。そこで、AIへ渡す前に自分の予想や違和感を短く書き、出力後に実際の結果との差を見るようにすると、自分の判断を残しながら使いやすくなります。

技術者の「素振り」を5つに分ける

1. 目的を一文にする

最初に、作業そのものではなく、作業後に得たい状態を書きます。

悪い例:
AIを使って設計書を作る

整理した例:
レビュー担当者が、変更範囲と主要なリスクを10分で確認できる設計書を作る

「AIを使う」「コードを書く」は手段です。

どんな結果になればうれしいのかを先に決めると、不要な作業を減らしやすくなります。

2. 現在地を事実で並べる

次に、今ある材料を確認します。

既存の文章、コード、仕様、ログ
確認できている事実
未確認の仮説
利用できる時間、環境、権限
自分が感じている違和感

この段階では、事実と解釈を分けて書くことが大切です。

事実: テストが3件失敗している
解釈: 認証処理の変更が原因かもしれない
未確認: 失敗はすべて同じ原因なのか

違和感をすぐに答えへ変えず、「何かがおかしい」という観測として残すと、調べる対象が見つけやすくなります。

3. 目指す姿との差分を出す

目的と現在地が並ぶと、埋めるべきギャップが見えてきます。

目指す姿: 読者がサンプルを再現できる
現在地: コードはあるが、前提条件と実行環境が書かれていない
ギャップ: 前提条件、バージョン、確認手順の説明が不足している

ここで大事なのは、「全部足りない」と考えないことです。

目的の達成に影響する差分だけを選ぶと、作業を小さくできます。

4. 小さな実験に変える

ギャップをすべて一度に埋めるのではなく、限られた条件の中で試せる形にします。

ここで、時間、環境、権限、予算、試行回数などの制約を使います。

例えば、実装前なら次のような行動です。

30分だけ既存コードを読む
失敗するテストを1件に絞る
本実装の前に短い検証コードを書く
記事本文の前に見出しだけ作る
AIには完成品ではなく、論点の洗い出しを依頼する

この小さな実験は、完成させるためだけではなく、次に何をすべきか判断するための情報を得る行動です。

5. 観測するものを決める

試した後に何を見るかも、先に決めておきます。

テストは通ったか
読者が迷いそうな箇所は減ったか
AIの出力は指定した形式を満たしたか
仮説を支持するログが得られたか
次も続ける価値があるか

結果が悪くても、次の判断材料が増えたなら、実験には意味があります。

文章・プログラム・AIでどう使うか

文章を書く前

いきなり本文を書かず、次だけを先に揃えます。

想定読者:
読後に分かってほしいこと:
自分が伝えたいこと:
根拠として使える材料:
未確認の点:
見出し案:
今回書かないこと:

ネタを集めることと、構造を作ることを分けると、「材料は多いが何を書きたいのか分からない」という状態を避けやすくなります。

プログラムを書く前

コードを書く前には、最低限、次を確認します。

利用者または呼び出し元:
入力:
期待する出力:
失敗時の扱い:
受け入れ条件:
既存コードへの影響:
最初に書くテストまたは検証コード:

例えば、認証処理の変更後にテストが3件失敗した場面を考えます。すぐに共通処理を書き換えるのではなく、まず5分だけ次のように整理します。

目的: 失敗の原因を切り分け、修正すべき箇所を決める
現在地（事実）: 認証に関連するテストが3件失敗している
現在地（仮説）: トークン検証の変更が影響した可能性がある
ギャップ: 3件が同じ原因で失敗しているか分からない
小さな実験の条件: 最初の30分は1件のテストだけを対象にする
小さな実験: 1件を単独実行し、トークン検証の前後のログを確認する
観測: 最初に期待値と異なる値が現れる箇所はどこか

この例では、「認証処理を直す」という広い作業を、まず「失敗がトークン検証の前後どちらで起きるか確かめる」という観測可能な行動へ変えています。ここで原因を絞れれば、関係のないコードまで変更する手戻りを減らせます。

設計を完璧にする必要はありません。

むしろ、分からない部分を短い検証へ変換できれば、本実装の前に大きな思い込みへ気づけます。

生成AIを使う前

生成AIでは、すぐにプロンプトを書くより、次を決めてから依頼するほうが整理しやすいです。

AIに任せたい作業:
人間が判断する部分:
入力として渡す情報:
期待する出力形式:
良い結果の例:
失敗とみなす条件:
渡してはいけない情報:
確認に使うテストケース:

この整理と重なる考え方は、GitHub公式ドキュメントにも見られます。

GitHub公式ドキュメントの「Prompt engineering for GitHub Copilot Chat」には、プロンプトを改善するための項目が8つ挙げられています。そのうち、今回の話と重なるのは次の5つです（2026年9月9日時点）。

公式ドキュメントの項目	内容	本記事との重なり
Start general, then get specific	まず目標やシナリオを大きく説明し、その後に具体的な要件を並べる	1. 目的を一文にする
Give examples	入力データ、出力、実装の例を示す	良い結果の例
Break complex tasks into simpler tasks	大きな作業を小さく単純な作業へ分ける	4. 小さな実験に変える
Avoid ambiguity	「これ」のような曖昧な指示語を避け、対象を特定する	入力として渡す情報
Experiment and iterate	望む結果が出なければプロンプトを直して試し直す	5. 観測するものを決める

残りの3つは「Indicate relevant code（関連するコードを開いて示す）」「Keep history relevant（会話履歴を関連するものに保つ）」「Follow good coding practices（既存コードを読みやすく保つ）」で、今回の5段階との直接的な対応というより、Copilotへ与えるコンテキストや既存コードの品質に関する項目です。

また、別ページの「Best practices for using GitHub Copilot」には「Check Copilot's work」という節があり、提案されたコードを実装前に理解すること、レビューすること、automated testsやlinting、code scanningなどの自動化されたテスト・ツールで確認することが挙げられています。

つまり、AIへの指示だけを工夫するのではなく、何を依頼し、何をもって良しとするかを人間側で整理することも重要です。

私が使いたい「5分の素振り」テンプレート

準備に時間をかけすぎないよう、まずは5分で次を埋めます。

## 目的
- この作業で、誰がどうなればうれしいか:

## 現在地
- 分かっている事実:
- 持っている材料:
- 感じている違和感:
- 未確認のこと:

## ギャップ
- 目的に対して不足しているもの:

## 次の小さな実験
- 使える時間:
- 使える環境・権限・予算:
- 今回あえて制限するもの:
- 今から試すこと:
- ここまではやらない:

## 観測と判断
- 何を確認するか:
- 自分が感じた違和感:
- 結果を見て次に決めること:

このテンプレートを埋めても次の行動が決まらない場合は、目的か現在地がまだ曖昧な可能性があります。

この原稿自体で試した例（Before / After）

このテンプレートを、今回の記事を作る過程にも当てはめてみました。

Before：最初に持っていた材料

最初は、次のような断片的なメモから始まりました。

球を打つだけでなく、素振りも大事
素振りをすると、自分の違和感に気づける
クラブの本数や球数を減らすと、一つのことへ集中できる
文章やプログラムも、書く前の構造化が大事
AIも、何に使い、どんな結果が出ればうれしいかを先に考えたい
時間とリソースには限りがある

考えていること同士にはつながりがありましたが、このまま本文を書き始めると、ゴルフの感想と仕事の一般論が並ぶだけになりそうでした。

5分の素振りに当てはめる

そこで、原稿を書く前の整理を次のように置きました。

## 目的
- 技術者が、すぐ成果物を作る前に短く立ち止まる意味を理解できる
- 制限を「不足」ではなく「フォーカスを作る手段」として捉えられる

## 現在地
- ゴルフ練習での実感と言葉はある
- 文章、プログラム、生成AIとの共通点も思いついている
- 一方で、開発業務でどう使うかという具体例が不足している

## ギャップ
- 読者が自分の作業へ持ち帰れる手順と例がない
- 「考えてから動こう」という一般論との差が見えにくい

## 次の小さな実験
- 条件:
  - 一つの記事で扱う
  - 特定の製品や開発手法に依存させない
  - 一次情報として確認できない素材は、事実の根拠として使わない
  - 例を増やしすぎず、文章・プログラム・生成AIに絞る
- 試すこと:
  - ゴルフの3つの制限を、開発業務の行動へ一つずつ置き換える
  - 読者がコピーできるテンプレートを一つ作る

## 観測と判断
- 抽象的な心構えではなく、次の作業を決められる内容になったか
- ゴルフの比喩と開発業務の対応に無理がないか

After：記事の構造が決まった

整理した結果、記事を次の流れに絞れました。

球を打ちたくなる気持ちと、成果物をすぐ作りたくなる気持ちを重ねる
クラブ、球数、球を打たない練習を、開発上の制限へ置き換える
目的、現在地、ギャップ、小さな実験、観測の5段階にする
文章、プログラム、生成AIの例を示す
読者が使えるテンプレートを残す

Beforeの段階では「準備も大事」という広い話でした。Afterでは、あえて制限して一つの論点へ集中し、自分の違和感を観測して次の行動を決めるという記事の軸が見えるようになりました。

実際に当てはめてみると、テンプレートの目的は立派な計画書を作ることではなく、散らばった材料から「今回は何を書くか」と「何を書かないか」を決めることだと分かりました。

なお、上の条件に書いた「一次情報として確認できない素材は、事実の根拠として使わない」については、公開前に本文の記述を公式ドキュメントと突き合わせて確認しました。その結果、引用元のページ名と項目名を原文どおりに書き足しています。

「素振り」が準備のしすぎにならないようにする

準備が大事だとしても、球を一度も打たなければ、本番に近い情報は得られません。

仕事でも、整理だけを続けると、準備が作業を避ける理由に変わってしまいます。

そのため、次のような制限を置くのがよさそうです。

素振りの時間を5分、15分、30分などに区切る
不明点をすべて調べず、最初の判断に必要なものへ絞る
小さくても必ず成果物か観測結果を残す
新しい事実が出たら、最初の計画に固執しない

目指すのは「考えてから動く」と「動きながら学ぶ」のどちらか一方ではありません。

短く整理し、小さく試し、結果を見てまた整えるという往復です。

まとめ

技術者の仕事における「素振り」を、次のように整理しました。

すぐに書き始める前に、目的を一文にする
現在地を事実・解釈・未確認事項に分ける
目指す姿との差分から、必要な改善を選ぶ
道具、範囲、試行回数をあえて制限し、一つの論点に集中する
時間とリソースの範囲で、小さな実験に変える
結果を観測し、次の行動を更新する

素振りは、成果物を作らない時間ではありません。

違和感に気づき、限られた条件の中で、次の一手を選びやすくするための時間です。道具や試行回数を減らすことも、自分の動きや考えにフォーカスするための一つの方法です。

文章、プログラム、生成AIのどれでも、まず5分だけ立ち止まってから始める。その短い往復を、自分の仕事の型として試してみたいと思います。

参考（公式情報）

いずれも2026年9月9日に内容を確認しています。

GitHub Docs: Prompt engineering for GitHub Copilot Chat
GitHub Docs: Best practices for using GitHub Copilot