未経験者で採用されて、ひょっとしたら５日間で現場投入するかもしれないからという前提で訓練をしている。
何人かの例を記載する。
環境説明＋面談
Mac mini 21台常備試験・研修室
https://qiita.com/kaizen_nagoya/items/3fc572d06eafe15a4c35
環境の説明をしながら面談。
何が作りたいか、
どういう仕事をしてきたか（学生の場合は、どういう部活、または 習い事）
何が好きか（運動、読書、音楽、、、）
どういう計算機触ったことがあるか（PC,スマフォ、電卓、自動車、、）
制約条件
現場投入がすでに決まっていて、その際のOS、言語、環境などが決まっている場合には、面談の際に、興味があることと、今回の案件がどういう関係にあるかの切り口を示すようにする。
例えば、音楽が好きであれば、今回の言語で、どういう音楽系のソフトウェアが開発されているかなど。
仮説・検証（54）プログラムは音楽だ (A program is a music.)
https://qiita.com/kaizen_nagoya/items/33c9f33581e6886f8ad8
コンパイルまたは実行
コンパイル言語なら入力してコンパイル、スクリプトも入力して実行。
コピペだと動いてしまう確率が高いため、手打ちしてもらう。
１日目の午前中に、コンパイルエラーまたは実行エラーを目撃するのが肝。
検索
検索は午後でもよい。
ネットで検索して、エラーを取る。
ネットに該当するエラーがないという場合には、
検索の仕方が悪いのか確認する。
類似のエラーが多すぎる場合には、絞り込むために、その時のプログラムの関数名、システムの環境名などを合わせて入れることを説明する。
エラーの全文を入力してなかったり、検索語を手打ちしていて打ち間違えているようなら、検索はコピペするように説明する。
情報が多すぎたり、全くないときには、Qiita, researchmapなど特定のサイト名を入れたり、代表的な人の名前を入れたり、固有名詞を併記することを説明する。
記録
記録してなければ報告できない。
どんな些細なこともすぐに消すのではなく、統計などを取って過去と重複しているものは消すような仕組みが背景でうごいていてもよいか。
報告
検索結果に基づいてエラーが取れたら、報告の仕方を説明する。
gitlabのIDを持っていなかったり、twitterのIDを持っていなかったら、どちらかのIDを登録してもらう。
エラーをissuに記載し、解決したことをコメントで書き。closeしてもらう。
作業をすべてgitlabでしていれば、日報はスクリプトを走らせればいいことを説明する。ただし、gitlab上で作業していないときには、Wikiに次の４項目を書くことを説明する。
わかったこと
できるだけ具体的に書く。具体的に書こうとすればするほど、わからないことに気がつくかもしれない。
わからなかったこと
わからなかったことがない場合は、何もわかっていない可能性がある。
わかればわかるほど、わからないことがたくさんあることを知るようになることを説明する。
よかったこと
一つでよい。
改めるとよいこと
他人のことを書いてもよい。
最終的には自分がその人に代わってやらざるを得なくなることを、後で説明する。
文書履歴(document history)
ver. 0.01 初稿 20190601
ver. 0.04 URL追記 20230228
最後までおよみいただきありがとうございました。
いいね 💚、フォローをお願いします。
Thank you very much for reading to the last sentence.
Please press the like icon 💚 and follow me for your happy life.