はじめに
はじめまして。
26新卒のむらのと申します。
現在、インフラ系の技術を学習しています。
私はこれまで、インフラ系の技術に本格的に触れた経験がほとんどありませんでした。
Linux環境での操作、コマンド、ディレクトリ構造、権限、パッケージ管理なども、学習を進めながら少しずつ理解している段階です。
そんな中で、段階的に難易度が上がる課題に取り組む機会がありました。
最初は資料を参考にしながら進められる内容でしたが、難易度が上がるにつれて、自分で考えながら構成を進める必要が出てきました。
この記事では、具体的な課題内容や使用した環境の詳細には触れず、インフラ系の学習を進める中で気づいた
「完成形から逆算して考えることの大切さ」
についてまとめます。
段階的に難しくなる課題に取り組んだ
取り組んだ課題は、段階的に難易度が上がる形式でした。
大まかには、以下のようなイメージです。
- Level 1：基本的な説明や資料を参考にしながら取り組む課題
- Level 2：基本内容をもとに、少し発展的な内容に取り組む課題
- Level 3：それまでの理解を前提に、自分で考えながら構成を進める課題
Level 2までは、資料にやり方などが書いてあるため、資料を確認しながら進めることで形になる課題でした。
しかし、Level 3では、単に手順をなぞるだけではなく、
なぜこの操作が必要なのか
この設定は何のためにあるのか
を考える場面が増えました。
さらに、前の段階で学んだことをもとに、自分で構成を考え、必要な要素を判断しながら進める必要がありました。
ここで、ただコマンドや手順を覚えるだけではなく、
全体をどう組み立てるかを考える力
が必要になると感じました。
負けず嫌いで難しい課題に挑戦した
正直に言うと、Level 3に挑戦した時点で、自分の理解が完璧だったわけではありません。
むしろ、分からないことも多く、途中で詰まる可能性は高いと感じていました。
それでも、負けず嫌いな部分が出て、
できるところまでやってみたい
分からないからこそ挑戦したい
難しそうでも、まずは手を動かしてみたい
という気持ちで取り組みました。
この姿勢自体は、自分の強みだと思っています。
分からないことがあっても、最初から諦めずに手を動かす。
難しそうでも、まず挑戦してみる。
できない理由を探すより、できる方法を探す。
この行動力は、今後も大切にしたいと思っています。
ただ一方で、今回の経験を通じて、
勢いだけでは乗り越えられない場面もある
と実感しました。
1時間ほど詰まった
課題を進める中で、ある場面でうまく動作しない状況が発生しました。
最初は、
たぶんここを直せばいけるだろう
この設定が怪しそう
さっき触った部分が原因かもしれない
と考え、思いついた箇所から確認していました。
しかし、なかなか解決しませんでした。
確認しているつもりではありましたが、
振り返ると、原因を論理的に絞り込んでいたというより、
それっぽい場所を勘で当てにいっている状態
だったと思います。
大学時代の研究では、プロトタイピングを進める中でAIを活用する場面が多くありました。
エラー内容の整理や原因の候補出しをAIに手伝ってもらうことも多く、自分一人で原因を順番に切り分ける経験は、まだ十分ではなかったと感じています。
そのため、今回はAIに頼らず、自分でエラーの原因を考えながら進めることを意識して取り組みました。
結果として、1時間ほど同じところで悩んでしまいました。
うまくいかなかった理由
うまくいかなかった理由は、
目の前のエラーや直前に触った箇所だけに意識が向きすぎていたこと
だと思います。
もちろん、エラーメッセージや直前に変更した箇所を確認することは大切です。
しかし、インフラ系の構成は、複数の要素がつながって成り立っていることが多いです。
そのため、エラーが出ている場所だけを見ても、根本的な原因にたどり着けないことがあります。
今回のケースでは、最終的に必要な前提条件が揃っていないことが原因でした。
具体的には、期待する動作に必要な要素が環境側に不足していました。
しかし自分は、設定の書き方やコマンドの実行方法ばかりを疑っていて、
そもそも必要な前提条件が揃っているのか
という視点が抜けていました。
その結果、本来であれば早めに確認すべきポイントに気づけず、時間を使ってしまいました。
完成形から逆算して考えた
途中で、考え方を変えました。
「どこが悪いのか」を探す前に、まず
完成している状態とは何か
を考えるようにしました。
具体的には、以下のように整理しました。
最終的に何ができれば成功なのか
そのために必要な要素は何か
それぞれの要素は、どの状態になっているべきか
現在の状態はどうなっているか
完成形と現在の状態に、どんな差分があるか
そもそも必要な前提条件は揃っているか
このように、完成形から逆算して確認していくと、それまで見落としていた原因に気づくことができました。
それまでは、エラーの近くばかりを見ていました。
しかし実際には、原因はエラーが出ている場所そのものではなく、
その前提となる部分
にありました。
エラー対応は「原因探し」ではなく「差分確認」
今回の経験で一番大きな気づきは、エラー対応に対する考え方が変わったことです。
以前の自分は、エラー対応を
原因を探す作業
だと思っていました。
しかし、今回の経験を通じて、エラー対応は
期待する状態と現在の状態の差分を確認する作業
だと感じました。
いきなり原因を当てようとすると、どうしても思い込みが入ります。
たぶんここだろう
前も似たようなところで詰まったから今回も同じだろう
この設定を変えれば直るだろう
このように考えてしまうと、確認範囲が偏ります。
一方で、完成形から逆算すると、確認すべきポイントを整理しやすくなります。
特に初学者のうちは、知識や経験が少ない分、勘で原因を当てにいくのは難しいです。
だからこそ、
完成形を言葉にすること
現在の状態を確認すること
その差分を一つずつ見ること
が大切だと感じました。
今後意識したいこと
今後、学習や実務でエラーに詰まったときは、すぐに設定を変え続けるのではなく、一度立ち止まって完成形を整理したいです。
特に、以下の流れを意識したいと思います。
何ができれば成功なのかを言葉にする
現在の状態を確認する
完成形との差分を洗い出す
必要な前提条件が揃っているか確認する
原因になりそうな箇所を順番に確認する
思い込みで判断せず、事実ベースで確認する
今回、自分は負けず嫌いな気持ちで難しい課題に挑戦しました。
その姿勢は大切にしつつ、今後はただ勢いで進めるだけではなく、
詰まったときに構造的に考える力
も身につけていきたいです。
まとめ
今回の学習を通じて、難しい課題に挑戦することの大切さと、詰まったときに考え方を切り替えることの大切さを学びました。
負けず嫌いで挑戦する姿勢は、自分の強みだと思います。
ただ、技術学習では、
「これでいけるはず」
という感覚だけでは進めない場面もあります。
エラーに詰まったときは、目の前の問題だけを見るのではなく、完成形から逆算し、期待する状態と現在の状態の差分を確認する。
そして、必要な前提条件が揃っているかまで確認する。
この考え方を、今後の学習や実務でも大切にしていきたいです。