ソフトウェアエンジニアリングの性質を考慮した学習方法について
こんにちは。42 Tokyoというエンジニア養成機関の 2022 年度アドベントカレンダー 23日目を担当します、スタッフのnopです。
プログラミングなどを学習している学生を3年ほど温かく（？）見守っているのだが、学生が費やす学習コストと課題解決の時間のコスパが悪いと思った時が何度かある。
極端な例だと、「10分で学ぶC言語」的な動画を閲覧したが課題をC言語で解決できなかったり、ドキュメントを全て読んだがどのように解決すべきかわからなかったり…
学習した時間は決して無駄ではないが、学習内容を課題解決に直結できず、遠回りしてしまう。遠回りしては、別のコンテンツ（ドキュメント、本、記事、フォーラム、動画など）をGoogleで検索して、「これだ！」というコンテンツに出会うまで、表示されたコンテンツを上から順に試し続けている。上から順に1つずつ試すので、最悪な場合、無限のコンテンツに学習コストをかけることになる。
「これだ！」というコンテンツに出会うには、結局上から順に当たるまで試すという運ゲーだと思っている人もいるが、法則も存在する。この法則を理解するには、まずソフトウェアエンジニアリングの性質を理解しなければならない。
ソフトウェアエンジニアリングとは、ある規則を未知の事例に応用する知的技能である。
それぞれのツールやコンセプト（プログラム、プログラミング言語など）には独自の規則が存在し、ソフトウェアエンジニアは自身の課題を解決するためにその規則を理解し、応用する。
自身が身につけた規則が応用可能かどうかを確認したい場合、実際に試すのが良い。例えば、あるプログラミング言語について理解したかどうか判断したい場合、まだ解決したことがない課題をそのプログラミング言語で解決してみる。未知の課題に応用できれば、理解しているという認識で問題ない。逆に応用することができないまま、理解したと勘違いした場合、未知の課題に対して手も足も出なくなる。
応用できるレベルにまで規則を理解する方法は、技術力の熟練度によって違うことは認識しておかなければならない。ある人は、ドキュメントを読むだけで規則を理解できる。ある人は、コードを読むだけで規則を理解できる。ある人は、何回もコードを模倣することで規則を導き出す。ある人は、その規則の仕組みの裏側を理解することで理解できる。ある人は、トライアンドエラーを何回も繰り返すことで理解できる。ある人は、自然界で類似しているコンセプトと認識を重ねることで理解できる。ある人は、抽象化と具体化を行き来することで理解できる。多種多様な方法が存在する。
すでに自分自身でどの方法が一番応用できるレベルにまで規則を理解できるか把握している場合、それが体感できるコンテンツを模索する。把握していない場合は、模倣する、適応する、実装する方法を1つずつ試し、応用可能なレベルまで規則を理解できるか判断するのが良い。
このことから、「これだ！」というコンテンツに出会いやすくなる法則は、規則を理解し、応用することが可能なコンテンツかどうかである。タイトルやサムネだけでは、判断ができない場合、パラパラとページをめくって確認したり、動画をところどころスキップして、確認したりする。
コンテンツを色々探しても判断できない場合は、階層分析を実施する。階層分析とは、習得済みの知的技能から、新たに習得したい知的技能にたどり着くまでに必要な知的技能を洗い出すために活用する課題分析手法である。
参考として、習得済みの知的技能が「プログラムの実行方法は理解している。」ことで、習得したい知的技能が「C言語でコマンドライン引数を受け付ける計算機を実装したい。」の場合、以下のように洗い出すことができる。
各知的技能を洗い出しても、コンテンツが見つからない場合や習得が難しい場合は、各知的技能をより細かく分解していく。
まとめ
ソフトウェアエンジニアリングやプログラミングなどは、ある規則を理解し、未知の課題に応用可能なレベルまで習得しなければならない性質を持っている。そのため、コンテンツを無作為に網羅的に学習するより、「規則を理解し、応用することが可能か」を軸にコンテンツを精査して学習した場合、学習コストと課題解決の時間のコスパが良くなる。コンテンツが見つからない場合は、階層分析を用いて学習すべき知的技能を洗い出し、各知的技能ごとにコンテンツを精査する。
最後に
42 Tokyoでは応用性が高い基礎（データ構造、アルゴリズムなど）が学べるので興味ある方はぜひ応募してみてください。
明日は、「多分Elixir」by @tacomeet が投稿されます。お楽しみに！
