はじめに
こんにちは！Qiita Engineer Festa 2023 に合わせてQiitaにもどってきたエイミです。
改めてになりますが、大学を卒業し、今年の春 株式会社Relic に就職、エンジニアになりました！
今回は特に就職/配属直後における技術的な勉強/キャッチアップ方法について話します。
いずれも、僕が実践していて効果を感じているものです！
目次
前提
- 話す内容は一部あるいは全部が、技術的なことに限らないものです！
- しかし、Qiitaに寄せて技術的なものに絞っています！
- また、状況の想定は就職直後・配属直後です！（例によって他の状況にも適用が可能な部分が多くありますが、前提はこの状況です）
PDCAとインプットとアウトプット
結論と最優先事項
- 最優先するのは量でありサイクルのスピードです
- 勉強方法/キャッチアップ方法の結論！
- PDCAのサイクルを回し、インプットとアウトプットの量と質を上げるとともに勉強/キャッチアップを行う
- 最優先するのは量でありサイクルのスピードです
- 要は志向して思考して試行する、Lean
- 弊社の Relic-ism のひとつ
- 最優先するのは量でありサイクルのスピードです
- 質は量から生まれます（＝量質転化）
関係性について
- 今回、インプットとアウトプットはPDCAのDoに当たるものです
- インプット・アウトプットはDoにあたることが多いです(*1)
- *1: まれにアクションとしてのインプット/アウトプットがあります
- ただインプット・アウトプットを行うだけでなく、それをPDCAサイクルの中で行うことを提案しているために、PDCAも併せて記述しています
PDCA
このセクションでは、PDCAを勉強/キャッチアップに寄せて説明しています
- 僕の考えているPDCAは、PDCAの中にPDCAがあるフラクタル的なPDCAです
- 例
- PDCAをうまく回すためのPDCAもあります
- P/D/C/Aのそれぞれをうまく回すためのPDCAもあります
- 今回の前提において、PDCAの意識よりも後述するインプット・アウトプットの実行が優先されます
Planする
- 計画のこと
- 勉強/キャッチアップにおいてもある程度粒度を変えつつ必要ですが、即時的に動く方が重要（量質転化させる）なので、最小限/自分が認識できないレベルでも良いことが多いです
- 計画する内容は状況/問題に応じます
- 参考: クネビンフレームワーク
- ※このフレームワークは誤った使い方/認識のされ方も多いので、もし使う際には有識者に相談することをお勧めします
- 詳細な計画よりも、ジャストインタイムの計画を心がけましょう
- 経験主義で行動し、必要になったタイミング（＝ジャストインタイム）で計画をしましょう
- 必要なときに必要な分だけ（＝ジャストインタイム）の計画をしましょう
- 予測主義で行動できるときは問題がシンプルだったり、自分の経験が十分にあるときです
Doする
- 実行すること
- 計画したことを実行します
- 今回は後述するインプット・アウトプットが当たる部分なのでそこに任せて他は割愛します
Checkする
- 検証/評価などのこと
- 実行した後にはいくつかの評価をする必要がありますが、PDCAに慣れている場合は無意識かである程度行われるため、量のために意識的に時間を取らなくても良いです。慣れていない場合はPDCAを成立させることを意識してやってみましょう
- Checkする主な例
- それが自分にとってどんな影響をもたらしたか（ポジティブ面を含む）
- それが自分にとってどんな成果をもたらしたか
- それが周囲にとってどんな影響をもたらしたか（ポジティブ面を含む）
- それが周囲にとってどんな成果をもたらしたか
Actionする
- 改善/対策などのこと
- Checkで行なった検証/評価を受けて、改善を図ります
- Actionする主な例
- インプット・アウトプットの手段の改善
- インプット元・アウトプット先の改善
- インプットプロセス・アウトプットプロセスの改善
- インプット・アウトプットの目的の改善
- インプット・アウトプットの手段の改善
インプットする
このセクションでは、PDCAのDoにあたるインプットの具体例を、僕が実施している順で挙げています
-
実施する際の注意
- 僕の場合、実施する際はそのインプットの内容を全て行うというよりも、各項目を最小限必要十分に行っています
- 全てをはじめから行うのは困難であることが多いので、はじめたての場合は以下の順序をおすすめします！
-
共通して、自分のバイアスに注意する
- 大抵過去の経験を元にインプットしていく
- インプット元・インプットプロセス・インプットの解釈にバイアスがかかる
- 特に解釈部分で、学びほぐし（Unlearn）が必要である
-
方法の目次（僕が実施している順）
コードを読む
- いくつかの読む方法があります
- 自プロジェクト/他プロジェクト
- PR経由
- レビューする
- 過去のレビューをみる
- ファイル経由
- PR経由
- 自プロジェクト/他プロジェクト
- どんな順序で読んでいるか
- 自プロジェクトのファイル経由で読む
- まずタスクに影響する実装から
- 次に似たタスクの実装を
- 自プロジェクトのPR経由でレビューする
- 割り振られた場合にレビューする
- タスクに余裕を作りながら関連しそうなものをレビューする
- 自プロジェクトの過去のPR/ファイルを読む
- 他プロジェクトに対して同様にする
- 自プロジェクトのファイル経由で読む
公式リファレンス/公式ドキュメントを読む
- 短期的に読み切れるものではないので、必要なときに読みます
- 実装に影響するものを読みつつ、以下のことを念頭におきます
- 同じ目的に対して自分の知らない実装方法があるかもしれません
- バージョンが一致しているか確認しましょう
- 同じ目的に対して自分の知らない実装方法があるかもしれません
- 「自分が何を知らないのか」は知ることが非常に困難です（特に、他者を介入させずにインプットしているとき）
- 同じ目的に対して自分の知らない実装方法があるかもしれません
- 知らない実装方法を知るためには、ChatGPTに網羅性を意識したプロンプトを送ることが便利です
- ChatGPTが使用不可な場合は、手段になる実装方法ではなく、目的とする達成したいことでGoogle検索をしましょう
- 英語で検索をかけたりするとなお良いです
- 最近は翻訳も高性能なので言語力が大きな障害になることが減っています
- 英語で検索・Webページにアクセスすることに勇気を持ちましょう
記事を読む
- いくつかの代表的なソースがあります
- 社内のナレッジが蓄積されているもの（以下、社内記事）
- Qiita
- Note
- Zenn
- 各企業のテックメディア
- 何を優先して読んでいるか
- 社内記事のプロジェクト関連範囲
- 気をつけていること
- 信憑性に欠けていることがあります（記事は2次以降の情報になるから）
- 技術的なことは公式リファレンス/公式ドキュメントが信頼がおけることが多いです
- 社内記事に関しては、技術的なことだけでなく自社/プロジェクトとして必要な情報もあります（今回のスコープ外ですが、読みましょう）
ChatGPTに聞く
- 大前提
- もっともらしい嘘には注意しましょう
- 最終的には公式リファレンス/公式ドキュメントを参照しましょう
- 機密でない情報だけにしましょう
- そもそも機密情報はモデルの学習時に少なかった特異的な情報になるので、聞いてもまともな答えは返ってこないことが多いです
- ChatGPTが得意なのは、量の多い情報です
- もっともらしい嘘には注意しましょう
- 何もわからないとき、とりあえず聞いてみると理解が深まることが多いです
- 代表例は、フレームワークのディレクトリ構造や、それぞれの利用用途です
- もっともらしい嘘には注意しましょう
- 「自分が何を知らないのか」を知ることに有用です
- 網羅的に出力させるプロンプトを使いましょう
- 最初のプロンプトで、
〜を実現する方法について、網羅的に複数の手段を教えてください - 出力された後に、
他に〜を実現する方法はありますか？
- もっともらしい嘘には注意しましょう
- ChatGPTに
本当に？と聞くと、誤った情報でも「正しいです」と答えたり、正しい情報でも「誤りがありました、訂正します。正しくは〜です」と答えて、正しいと提示した情報が誤っていることがあります- 試しに、何かに対して
本当に？と繰り返し聞いてみるとわかります
- 試しに、何かに対して
先人に質問する
- 先人は、何も先輩だけではありません
- 同期・後輩のだれしもが自分にはない何かの点で先人です
- 先人は多くのことを知っています
- 先人らを考えたとき、非常に多くのことを知っていて、自分よりも理解していることが多いです
- Slackチャンネルを活用しましょう
- あなたが質問することが周りにとっても助けになります
- あなたが質問することでナレッジが共有されます
- プロジェクトに特有のものもあるので、プロジェクト内でも質問する勇気を持ちましょう
- 毎日のMTGや、Slackなどさまざまな聞く機会があります
- 他者の介入によって、「自分が何を知らないのか」を知ることにも有用です
- 質問のコツ
- 認識の前提を伝える
- 一意に解釈されやすい文章を心がける(*2)
- 疑問の答えに当たる仮説を合わせて聞く
- エラーなどの場合はできるだけエラー全文を示す
- 必要に応じてスクリーンショットも添付する
- つまり、回答者が回答するに必要十分な情報を提供する(*2)
- その上、回答者が情報を認識するに必要なコストが少ないと良い（時間コスト・認知コスト）(*2)
- *2: この部分だけ取り上げても大きなトピックなので、需要があれば別途記事化します
アウトプットする
このセクションでは、PDCAのDoにあたるインプットの具体例を、インパクトが大きい順で挙げています
-
実施する際の注意
-
共通して、自分のバイアスに注意する
- 大抵過去の経験を元にインプットしていく
- インプット元・インプットプロセス・インプットの解釈にバイアスがかかる
- 特に解釈部分で、学びほぐし（Unlearn）が必要である
-
インプットするだけでは、知識などの獲得は難しいです
- 人に教えられるようなレベルでは、特にアウトプットが必要です
-
方法の目次（インパクトが大きい順）
発表/登壇する
- 色々なところに場があります
- 今こうやって僕がしているように、Qiitaがあります
- 様々な技術カンファレンスがあります
- 様々なLTイベントがあります
- 場を、その機会をぜひ活用してください
- これを聞いている誰しもに上記のような多くの機会がありますが、このような機会がない状況下の方は少なくありません
- 拙くても構いません、誰しもが最初は初心者であり未経験者です
記事を書く
- インプットで示したような場があります
- 社内記事
- Qiita
- Note
- Zenn
- レビューをしてくださる仲間もいます
- 学んだことを記録し、組織に還元しましょう
他者の質問に答える
- 自分が起点となって発信していなくても、自分の発言や文字として表出したものはアウトプットです
- 自分がわかるときは特に答えましょう
- わからない時でも少し調べて答えられる場合があります
- この場合、インプットとアウトプットをセットで行えるので一石二鳥です
- ただし、回答する情報の質には注意しましょう
- 主語を狭めて自分だけにしたり、ソースとなるURLを併記することが効果的です
PRでレビューする
- 自プロジェクトでは積極的に行いましょう
- ただし、フェーズによって求められる質や量が異なります
- プロジェクト内でその点の認識は合わせておくと費用対効果が高くなります
- 他プロジェクトであっても、PRを覗けるかもしれません
- ただし、自分のよく知る分野でないと以下のような懸念があります
- そもそも困難であり、時間がかかることにより本来のタスクなどに支障が出る
- 間違った情報を提供することにより、技術的な負債を生む
- 不用意な質問を過剰にすることにより、回答者に時間を取らせる
- 初心者であると強く感じるうちは特に、そこまで手を伸ばさなくてもいいと思います
- アウトプットはいろいろな方法ですると相乗効果が生まれることが多いですが、全てを達成することは非常に困難であるため欲張らないことも重要です
- ただし、自分のよく知る分野でないと以下のような懸念があります
共有する
- 今まで述べたアウトプットも共有にあたることがあります
- MTGや雑談に近い会話でも共有することができます
- 組織に還元することにつながります
- フィードバックを通した他者の介入により、「自分が何を知らないのか」を知ることにも有用です
さいごに
長くなりましたが、何度か言及してきたように部分的な実行でも一定の効果があります。はじめから全てをやるのは難易度が高い場合が多いです。
継続は力なり！ぜひ自分にあった方法を探して、継続的なPDCA、ひいては技術的な勉強/キャッチアップをしていきましょう！