この記事は約18分で読めます。
筆者プロフィール: ソフトウェアエンジニア。「知った気にならない。いつまでも学び続ける」を信条に、業務と個人開発の両輪で技術を磨いています。AI 駆動開発で複数の個人開発アプリを構築・運用中。
👉 ポートフォリオ: 筆者ホームページ
「教えること」ではなく、「相手が自立できる状態を設計すること」──それがOJTの本質だった。
はじめに
「後輩の指導を任されたけれど、何から手をつけていいかわからない」
「つい自分でやってしまい、いつまでも後輩が一人立ちしない」
こうした悩みを抱えるトレーナーは、決して少なくないのではないでしょうか。
私自身、ある研修を通して、まさにこの壁にぶつかっていた自分に気づかされました。この研修では、単なる「教え方のコツ」ではなく、後輩が自ら考え、自ら動き、自分の言葉で語れるようになるまでの"設計思想" を体系的に学ぶことができました。
本記事では、研修で得た学びと、実際に私が作成した 「6か月間のOJT育成計画」 を余すところなく共有します。後輩育成に関わるすべての方にとって、何かひとつでもヒントになれば幸いです。
1. OJTの本質──目指すのは「人が育つ風土」の定着
OJTというと「先輩が後輩にスキルを教える場」というイメージが強いかもしれません。しかし、この研修で最初に提示されたのは、もっと大きな視点でした。
OJTの最終到達目標は、一時的なスキル習得ではなく「人が育つ風土の定着」にある。
風土定着に必要な3つのレイヤー
人が育つ組織を作るためには、以下の3つの要素が重なり合う必要があります。
| レイヤー | 内容 | 具体例 |
|---|---|---|
| ①環境（組織） | 育成を支える仕組み | 戦略方針、人事制度、教育制度 |
| ②スキル（トレーナー） | 体系的な育成手法 | 本研修のような指導技術の習得 |
| ③マインド（最重要） | 育てることへの主体的な姿勢 | 自責思考への転換 |
特に印象的だったのは ③マインド の話です。
「自分が苦労したから、後輩にも同じ苦労をさせる」──この発想は、一見すると"鍛える"ように見えて、実は育成の放棄に近い行為です。研修では、これを 「より充実した育成環境を整備し、後輩の成長の可能性を広げる姿勢」 へと転換することが求められました。
過去の自分の苦労を美化するのではなく、その苦労を踏まえて 後輩にはもっと良い道を用意する。この自責思考こそが、育成の出発点なのだと強く感じました。
2. 【実践】6か月で「支援なし」の自立へ導くOJT計画
研修の課題として、私は以下のゴールを設定しました。
業務背景や目的を理解したうえで、6か月後までに後輩社員が上司の支援なしでシステムの仕様・設計を一人で説明できる状態にする。
このゴール設定には、3つの意図があります。
- 期限が明確：半期目標として管理できる
- 到達基準が具体的：「支援なしで一人で説明できる」は客観的に判断可能
- 深さがある：単なる作業習得ではなく「背景理解」まで含んでいる
ゴールが決まったら、次は 逆算して段階的に学習サイクルを回すロードマップ を設計します。
半期OJT育成スケジュール
以下が、私が実際に作成した6か月間の育成計画です。
【9月】フェーズ1：なぜ存在するのか？
テーマ：システムの存在意義、業務課題の解決目的を理解する
| 学習サイクル | トレーナーの行動ポイント |
|---|---|
| 調査する → 説明する → 修正する | 最初から答えを教えず、問いかけによって後輩自身の言葉でのアウトプットと気づきを促す |
ポイント：「調査しておいて」で終わらせず、説明の場とフィードバックの場をセットで設ける ことが重要です。週1回の定例で「調べた内容を自分の言葉で説明してもらう → 問いかけで気づきを促す → 修正は本人にやってもらう」という流れを回すことで、"調べて終わり"ではない深い学びに変わります。
【10月】フェーズ2：何ができるのか？
テーマ：実機でのテスト操作を通して機能概要を俯瞰する
| 学習サイクル | トレーナーの行動ポイント |
|---|---|
| 動かす → 疑問を持つ → 調査する → 聞く | 質問の前に「自分ではどう考えた（仮説）？」を確認。疑問を持つこと自体をポジティブに評価する |
ポイント：座学だけでは限界があります。実際に操作してもらい、「なぜこうなるのか？」という疑問を自然に引き出すことが大切です。そのためには 検証環境の用意 と、疑問を歓迎する姿勢 が欠かせません。
【11月】フェーズ3（前半）：どう作られているか？
テーマ：仕様書や設計書から設計思想を読み解く
| 学習サイクル | トレーナーの行動ポイント |
|---|---|
| 読み解く → 自分の言葉で書き起こす | 「全体構成図 → DB設計 → 処理フロー」のように全体から詳細へ読む順番を示し、形式だけの理解を防ぐ |
ポイント：「ドキュメントを読んでおいて」で終わらせないこと。読む順番を示す だけで理解度は大きく変わります。さらに、分からなかった部分を 歓迎する姿勢 を明確に示すことで、後輩が「分からない」と言える心理的安全性を作れます。
【12月】フェーズ3（後半）：作ってみる・直す
テーマ：実際のドキュメント作成や古い箇所の更新
| 学習サイクル | トレーナーの行動ポイント |
|---|---|
| 作成する → レビューを受ける → 修正する | 「記載内容は正しいか」「読み手にとってわかりやすいか」の2軸でレビュー |
ポイント：既存ドキュメントの更新や不足部分の補完を本人に任せることで、読み手から書き手へ立場が変わり、理解が一段深まります。レビューでは「正しさ」と「わかりやすさ」の2軸を意識し、指導者が書き直すのではなく 本人に修正させる ことが鍵です。
【1月】フェーズ4：点を線にして整理する
テーマ：業務背景から設計、機能の繋がりまでを1つの資料に整理
| 学習サイクル | トレーナーの行動ポイント |
|---|---|
| 構成する → 書く → 中間レビュー → 修正 | 目的・読者を明確にし、本文執筆前に「構成案（目次）」をレビュー |
ポイント：「理解したつもり」を防ぐ最も有効な方法が、自分の言葉で資料を作ること です。ここで重要なのは、いきなり書き始めさせるのではなく、構成案の段階でレビューする こと。早い段階で方向性を確認することで、大きな手戻りを防げます。
資料作成時のチェックポイント：
- 目的と読者を明確にしているか
- コピペではなく自分の言葉で書いているか
- 横の繋がり（データの流れ等）を意識できているか
【2月】フェーズ5：一人で説明する
テーマ：指導者の同席はあるが、自身の言葉でステークホルダーに説明
| 学習サイクル | トレーナーの行動ポイント |
|---|---|
| リハーサル → 本番説明 → 本人による振り返り | 事前に想定問答でリハーサル。本番では詰まってもすぐに口を出さず、待つ |
ポイント：最終的な自立の確認として、本人が一人で説明する場を設ける ことが重要です。
具体的な支援行動：
- 想定質問を準備し、リハーサルを実施する
- 事実の正しさだけでなく 伝え方 もフィードバックする
- 本番では必要以上に助けすぎない
- 本人のセルフレビューを先に行ってもらう
- 失敗しても責めず、次の機会につなげる
そして、この段階で最も大切な一言があります。
「一人でできるね」と明確に伝えること。
これは単なる評価ではなく、本人の自己効力感を高める 極めて重要なフィードバックです。「あなたはもうできる」と言葉にして伝えることで、後輩は自信を持って次のステップに進めるようになります。
3. OJTに潜む落とし穴──「氷山モデル」で深層原因を捉える
後輩がつまずいたとき、表面に見えるミスだけを指摘していませんか？
研修では、つまずきの原因を 「氷山モデル」 で分析する考え方が紹介されました。水面上に見えているのはミスや行動の結果に過ぎず、その下には3つの深層原因が隠れています。
つまずきの3つの深層原因と対処法
| 原因の層 | 状態 | 対処法 |
|---|---|---|
| スキル | 特定の知識や技術が不足している | つまずいた箇所を具体的に特定し、再度OJTを実施。伴走しながら成功体験を積ませる |
| マインド | 姿勢や考え方に課題がある | 「姿勢を改めなさい」ではなく、問いかけや対話で本人も気づいていない深層的な課題にアプローチする |
| モチベーション | やる気や前向きさが低下している | 過去の本人との比較で成長を承認する。目標が高すぎる・遠すぎる場合は再調整する |
OJTで大切なのは、見えているミスを叱ることではなく、見えていない原因を捉えること。
この考え方は、後輩育成に限らず、チームマネジメント全般に通じる重要な視点だと感じました。
4. 再認識した「4つの原則」
原則①：ゴールは具体的に定義する
「頑張る」「理解する」では、達成したかどうかを誰も判断できません。
- 一人称で（「後輩が〜できる」）
- できる状態で（「説明できる」「作成できる」）
- 客観的に判断できる形で（「支援なしで」「一人で」）
定義することが、育成計画の起点になります。
原則②：育成は一人で抱えない
育成はトレーナー1人だけで完結するものではありません。周囲の先輩社員も含めた支援体制 を構築し、「人が育つ風土」をチーム全体で作ることが重要です。
原則③：ミスは深層原因で捉える
知識・スキル・マインド・モチベーションの どこに原因があるのか を見極めることが、指導の質を左右します。
原則④：ペナルティで人は育たない
マインドに課題がある場合でも、罰で矯正するのではなく、対話や問いかけによって根本に向き合う ことが求められます。恐怖による行動変容は一時的なものに過ぎず、本質的な成長にはつながりません。
5. この研修を通じて最も強く感じたこと
この研修を通じて、最も心に残ったのは次の一言に集約されます。
OJTは「教えること」ではなく、「相手が自立できる状態を設計すること」である。
単に知識を渡すだけなら、説明会や資料配布でもある程度は可能です。しかし、後輩が本当の意味で「育った」と言えるのは、次の4つができるようになったときではないでしょうか。
- 自分で考える
- 自分で調べる
- 自分で整理する
- 自分の言葉で説明できる
ここまで到達して初めて、OJTとしての価値が生まれるのだと実感しました。
そして、後輩をその状態へ導くために、トレーナー自身にも覚悟と姿勢が求められる ということも、今回の大きな気づきです。
トレーナーに求められる5つの姿勢
| 姿勢 | 具体的な行動 |
|---|---|
| 焦らない | 成長のペースは人それぞれ。短期的な成果を急がず、計画に沿って伴走する |
| すぐ答えを言わない | 問いかけで考えさせ、本人の中から答えを引き出す |
| 本人の言葉を待つ | 沈黙を恐れず、後輩が自分の言葉でアウトプットするのを見守る |
| 失敗を次につなげる | ミスを責めるのではなく、振り返りの材料として活かす |
| 成長を明確に承認する | 「できるようになったね」「一人でできるね」と言葉にして伝える |
特に「すぐ答えを言わない」は、日々の業務の中で最も難しいことのひとつだと感じています。忙しいときほど、つい「こうすればいいよ」と答えを渡してしまいがちです。しかし、その瞬間の効率を優先するたびに、後輩が自分で考える機会を奪っている──そのことを、この研修で改めて突きつけられました。
6. まとめ──研修で学んだ5つのエッセンス
研修を通じて学んだことを整理すると、重要なのは次の5点です。
- OJTは継続性・計画性・一貫性を持って設計する
- ゴールは半期目標と結びつけて具体的に設定する
- 表面的なミスではなく、氷山モデルで深層原因を見る
- 問いかけ・レビュー・リハーサルを通じて自立を支援する
- 最終的には「人が育つ風土」の定着を目指す
今回作成した6か月間のOJT計画や支援方法は、単なる研修課題の回答にとどまらず、今後実際に後輩育成を進める際の土台 になると確信しています。
また、この学びは後輩育成だけに限りません。普段の資料レビュー、仕様整理、チーム内での情報共有など、「人に伝える」「人の成長を支える」あらゆる場面 に応用できるものだと感じました。
おわりに
後輩育成に正解はありません。相手が変われば、アプローチも変わります。
しかし、「自立できる状態を設計する」 という軸を持っているかどうかで、日々の指導の質は大きく変わるはずです。
- これからOJTを担当する方
- 後輩の育て方に悩んでいる方
- 「教えているのに伝わらない」ともどかしさを感じている方
そんな方々にとって、この記事が少しでも参考になれば幸いです。
育てることは、自分自身も成長すること。
後輩の成長を設計する過程で、トレーナーもまた育っていく。
その実感を持てたことが、今回の研修で得た最大の収穫でした。
付録
6か月間のOJT育成計画
OJT計画書 標準テンプレート
1. 基本情報
| 項目 | 内容 |
|---|---|
| 作成日 | yyyy/mm/dd |
| 作成者 | |
| OJT対象者 | |
| OJT指導者 | |
| 対象システム／業務 | |
| OJT期間 | yyyy/mm/dd ～ yyyy/mm/dd（全__週間） |
2. OJTゴール
ゴール文（記入欄）:
＿＿＿＿を理解したうえで、＿＿か月後までにOJT対象者が＿＿＿＿の支援なしで＿＿＿＿を一人で＿＿＿＿できる状態にする。
ゴール設定時の確認事項
- 達成期限が明確か
- 「できる状態」が具体的な行動として定義されているか
- OJT対象者と指導者の間でゴールが合意されているか
【記載例】
業務背景や目的を理解したうえで、6か月後までに後輩社員が上司の支援なしでシステムの仕様・設計を一人で説明できる状態にする。
3. OJT計画（フェーズ別）
フェーズ一覧
| フェーズ | 期間 | テーマ | 学習サイクル |
|---|---|---|---|
| 1 | 第__～__週 | なぜ存在するのかを理解する | 調査する → 説明する → 修正する |
| 2 | 第__～__週 | 何ができるのかを理解する | 動かす → 疑問を持つ → 調査する → 聞く |
| 3 | 第__～__週 | どのように作られているかを理解する | 読み解く → 書き起こす → レビューを受ける |
| 4 | 第__～__週 | 点の知識を線にして整理する | 構成する → 書く → レビューを受ける → 修正する |
| 5 | 第__～__週 | 一人で説明する | リハーサルする → 本番で説明する → 振り返る |
フェーズ1：なぜ存在するのかを理解する
期間： 第__～__週
目的：
機能や画面の説明に入る前に、対象システム／業務が何のために存在しているのか、どの業務課題を解決するためのものなのかを理解してもらう。
学習サイクル：
「調査する → 説明する → 修正する」
この期間で達成すべき状態：
- 対象システム／業務の存在意義を自分の言葉で説明できる
- 上記の学習サイクルを自力で回せるようになっている
備考欄：
フェーズ2：何ができるのかを理解する
期間： 第__～__週
目的：
実際にシステムを触りながら、どのような機能があり、何ができるのかを理解してもらう。
学習サイクル：
「動かす → 疑問を持つ → 調査する → 聞く」
この期間で達成すべき状態：
- 主要機能を一通り操作し、各機能の概要を説明できる
- 受け身ではなく、自分で疑問を持ち調査する姿勢が身についている
備考欄：
フェーズ3：どのように作られているかを理解する
期間： 第__～__週
目的：
システムの目的や機能を理解した後、それがどのような構成・設計で実現されているのかを学んでもらう。
学習サイクル：
「読み解く → 書き起こす → レビューを受ける」
この期間で達成すべき状態：
- 既存の仕様書・設計書・構成図の内容を自分の言葉で説明できる
- 必要に応じてドキュメントの作成・修正を担当できる
備考欄：
フェーズ4：点の知識を線にして整理する
期間： 第__～__週
目的：
ここまでに得た知識を断片的な理解で終わらせず、業務背景・機能・設計をつなげて説明できる状態にしてもらう。
学習サイクル：
「構成する → 書く → レビューを受ける → 修正する」
この期間で達成すべき状態：
- 自分の言葉で資料を作成し、知識を再構成できている
- 業務背景から設計までを一貫したストーリーとして説明できる
備考欄：
フェーズ5：一人で説明する
期間： 第__～__週
目的：
指導者の支援なしでOJT対象者本人がシステムの仕様・設計を説明する機会を設ける。
学習サイクル：
「リハーサルする → 本番で説明する → 振り返る」
この期間で達成すべき状態：
- 自分の理解を相手に伝えきることができる
- 「指導者がいなくても大丈夫」と本人が思える状態になっている
備考欄：
4. 指導・支援方法
支援方法1：「調査する → 説明する → 修正する」を回すための支援
対応フェーズ： フェーズ1
指導者の行動
| 項目 | 内容 |
|---|---|
| 事前準備 | 調査対象を絞り、調査範囲を明確に指示する |
| 説明の場 | 週1回の定例会等で、OJT対象者自身の言葉で説明してもらう |
| フィードバック | 説明時にメモを取り、後からフィードバックとして返す |
| 方向修正 | 誤りや不足があった場合、すぐに答えを伝えず問いかけで気づかせる |
問いかけの例
- 「○○の場合はどうなる？」
- 「その処理はなぜ必要だと思う？」
チェックポイント
- 「調査してみて」で終わらせていないか
- 説明の場とフィードバックの場がセットになっているか
- 正解を渡すのではなく、考え方を支援できているか
支援方法2：「動かす → 疑問を持つ → 調査する → 聞く」を回すための支援
対応フェーズ： フェーズ2
指導者の行動
| 項目 | 内容 |
|---|---|
| 事前準備 | 壊しても問題ない検証環境を用意する |
| 操作指示 | 代表的な正常系シナリオを複数実施してもらう |
| 疑問の収集 | 気になったこと・わからなかったこと・違和感があったことを書き出してもらう |
| 質問対応 | 最初に答えを教えず「自分ではどう考えた？」と仮説を確認する |
| 理解の深化 | 既存ドキュメントと操作で得た感覚を照らし合わせてもらう |
チェックポイント
- 「操作してみて」で終わらせていないか
- 疑問を持つこと自体を前向きに評価できているか
- 質問の前に仮説を持つ習慣をつけてもらえているか
支援方法3：ドキュメントを読み解き、作成・修正するための支援
対応フェーズ： フェーズ3
指導者の行動
| 項目 | 内容 |
|---|---|
| 読む順番の指示 | 「全体構成図 → DB設計 → 処理フロー」のように全体から詳細へ読む順番を明示する |
| 書き起こし | 読んだ内容をそのまま受け取らせず、自分の言葉で書き起こしてもらう |
| ドキュメント作成 | 既存ドキュメントがない場合や古い場合は作成・更新を担当してもらう |
| レビュー | 「記載内容が正しいか」「読み手にとってわかりやすいか」の2軸で確認する |
| 不明点の扱い | 分からなかった部分をマイナスとせず、一緒に読み解く時間を作る |
| テンプレート提供 | テンプレートや良いサンプルを渡し、本質的な理解に集中させる |
チェックポイント
- 「ドキュメントを読んでみて」で終わらせていないか
- 全体から詳細へ読む順番を示しているか
- 分からなかった部分を歓迎できているか
- 正しさと分かりやすさの両方をレビューしているか
支援方法4：自分の言葉で資料を作成してもらうための支援
対応フェーズ： フェーズ4
指導者の行動
| 項目 | 内容 |
|---|---|
| 目的・読者の明確化 | 資料作成依頼時に目的と読者を最初に明確にする |
| 構成案レビュー | 本文の前に目次レベルの構成案を提出してもらい、抜け・順番をレビューする |
| 中間レビュー | 4割程度の段階で方向性にずれがないか確認する |
| 最終レビュー | 初見の読者のつもりで通読し、理解不能箇所・論理の飛躍がないか確認する |
| 背景の確認 | 機能説明だけでなく「なぜこの機能があるのか」まで含まれているか確認する |
| 横のつながり | 機能同士の横のつながりやデータの流れも意識して整理してもらう |
| 作業時間の確保 | 資料作成に十分な作業時間を確保する |
| 修正の方針 | 指導者が本文を書き直さず、修正ポイントだけ伝え本人に修正させる |
チェックポイント
- 目的と読者を明確にしているか
- 構成案の段階でレビューしているか
- コピペではなく自分の言葉で書かせているか
- 早い段階で方向性を確認しているか
- 指導者が書き直さず、本人に修正させているか
支援方法5：一人で説明できるようにするための支援
対応フェーズ： フェーズ5
指導者の行動
| 項目 | 内容 |
|---|---|
| 想定質問の準備 | 相手から来そうな質問をあらかじめリストアップする |
| リハーサル | 想定質問を使ってリハーサルを実施する |
| リハーサル後FB | 「事実の正しさ」「話の順番・つながり」「声・スピード・専門用語」の観点でフィードバックする |
| 本番の同席 | 同席するが基本的に口を出さず、詰まっても数秒待ってから必要最小限の助け舟を出す |
| 振り返り | まず本人に「うまくいった点」「難しかった点」を言語化してもらい、その後に指導者の所感を伝える |
| 完了宣言 | 「一人でできるね」と明確に伝える |
| 課題の一覧化 | うまく答えられなかった点・曖昧だった点を一覧化し、次の課題につなげる |
| 再挑戦の機会 | 失敗しても責めず、必要であれば次の説明機会を作る |
チェックポイント
- 本番前に想定質問でリハーサルしているか
- 正確性だけでなく伝え方もレビューしているか
- 本番で必要以上に助けすぎていないか
- 本人のセルフレビューを先に行っているか
- 失敗しても責めず、次の機会につなげているか
5. 進捗管理
フェーズ別進捗記録
| フェーズ | 予定期間 | 実績期間 | 達成状況 | 備考 |
|---|---|---|---|---|
| 1 | 第__～__週 | 未着手／進行中／完了 | ||
| 2 | 第__～__週 | 未着手／進行中／完了 | ||
| 3 | 第__～__週 | 未着手／進行中／完了 | ||
| 4 | 第__～__週 | 未着手／進行中／完了 | ||
| 5 | 第__～__週 | 未着手／進行中／完了 |
定例振り返り記録
| 日付 | 対象フェーズ | OJT対象者の状況・所感 | 指導者のフィードバック | 次回までのアクション |
|---|---|---|---|---|
| yyyy/mm/dd | ||||
| yyyy/mm/dd | ||||
| yyyy/mm/dd | ||||
| yyyy/mm/dd | ||||
| yyyy/mm/dd |
6. 最終評価
ゴール達成判定
| 項目 | 内容 |
|---|---|
| 評価日 | yyyy/mm/dd |
| 評価者 | |
| ゴール達成状況 | 達成／一部達成／未達成 |
| 判定理由 |
評価観点別チェック
| 評価観点 | 達成度（◎○△×） | コメント |
|---|---|---|
| 業務背景・目的を理解しているか | ||
| 主要機能を説明できるか | ||
| 構成・設計を説明できるか | ||
| 業務背景・機能・設計を一貫して説明できるか | ||
| 指導者の支援なしで説明できるか | ||
| 質疑応答に対応できるか |
OJT対象者の自己評価
| 項目 | 内容 |
|---|---|
| 自分自身の成長を感じた点 | |
| まだ不安が残る点・今後の課題 | |
| OJTの進め方に対する感想・改善要望 |
指導者の総評
| 項目 | 内容 |
|---|---|
| OJT対象者の成長に対する所感 | |
| 特に評価できる点 | |
| 今後の育成課題・フォロー事項 |
今後のアクション
| No. | アクション内容 | 担当 | 期限 | 備考 |
|---|---|---|---|---|
| 1 | yyyy/mm/dd | |||
| 2 | yyyy/mm/dd | |||
| 3 | yyyy/mm/dd |
7. 本テンプレートの使い方
利用手順
- 基本情報（第1章） を記入し、OJTの対象者・指導者・対象システムを明確にする
- OJTゴール（第2章） をOJT対象者と合意のうえ設定する
- OJT計画（第3章） の各フェーズに具体的な期間・達成状態を記入する
- 指導・支援方法（第4章） の各チェックポイントを指導中に定期的に確認する
- 進捗管理（第5章） を週次または隔週で更新し、定例振り返り記録を蓄積する
- 最終評価（第6章） をOJT完了時に実施し、今後のアクションまで記録する
カスタマイズのガイドライン
| 変更が想定される項目 | カスタマイズの考え方 |
|---|---|
| フェーズ数・期間配分 | 対象業務の複雑さやOJT対象者の経験値に応じて増減・調整する |
| 学習サイクル | 業務特性に合わせてサイクルの内容を変更する |
| 支援方法の詳細 | 指導者の経験やチームの文化に合わせて具体的な行動を追加・修正する |
| 評価観点 | ゴールの内容に合わせて評価項目を追加・変更する |
| 定例振り返りの頻度 | 週次・隔週・月次など、状況に応じて調整する |
注意事項
- 本テンプレートはあくまで標準的な型であり、現場の状況に合わせて柔軟に調整すること
- フェーズの順番（目的の理解 → 機能の理解 → 設計の理解 → 知識の統合 → 自立した説明）は基本原則として維持することを推奨する
- 各フェーズの支援方法に記載されたチェックポイントは、指導の質を振り返るためのものであり、すべてを厳密に満たすことが目的ではない
関連記事
- 「「文章術のベストセラー100冊」のポイントを1冊にまとめてみた。」を読んで思ったこと — 相手に伝わる言葉・資料の作り方についてまとめた記事
- 2024年度上期 - 振り返り — 自身の成長や学びのプロセスを言語化して振り返った記事