IT企業向け新入社員研修の日記。
1日目〜20日目はこちら

21日目

【講義内容】
・JavaScript
Javaとは全く関係ないのだけれど、プログラミングをある程度理解していた方がJavaScriptも理解しやすいだろう、ということで、今年からこのタイミングで学ぶことになった。1日で多くを理解するのは難しいけれど、JavaScriptの概要とJavaと異なる点などを重点的に。fetchを使った非同期通信あたりも軽く触れてみる。できるようになると個人開発、とかグループ開発でも重宝すると思うので、チャレンジしてみよう。

【講義以外】
・コードを読む
自分が書いたコードだけを読んでいるとどうしても視野が狭まる。他人が書いたコードや、演習の模範解答を読むと学べることがきっと多いので、時間があれば自分以外の人が書いたコードを読むようにしましょう。

・自動化
プログラミングとは、手動だと面倒なことを自動化することに意義がある。けど、プログラムを書くのが面倒なことも多い。その場合、プログラムを自動で作るプログラムを書くと効率化されたりする。メタプログラミングと呼ばれたりも。そういう思考も持てるようになると良いかも。

・１人前になる
１人前になって、周りの人から認めてもらうことができれば、休みなどは割と融通が効きやすくなる。自分が休みたい時にいつでも休めるように、早い段階で色々と勉強して１人前になろう。

【感想】
JavaScriptをこのタイミングでやるのは正解かも。ただ、テキストに非同期通信がなかったので、その辺りはもっと触れるべきだったのかな。jQueryも軽く触れたけれど、それ以外のフレームワークも積極的に使いたいところ。

22日目

【講義内容】
・Java（総復習）
今までの内容を踏まえて自主学習。テスト勉強や未提出の演習への取り組みなど。

【講義以外】
・PC操作
PC操作がまだ慣れていない人は、プログラミングよりもそっちを優先して早く身につけよう。PCはエンジニアの仕事道具。料理人でいう調理器具のようなもの。包丁が使えない料理人をプロの料理人とは呼べない。エンジニアとして働くならPC操作を真っ先に身につけよう。

・プログラミングの土台
個人的には、「PC操作」「論理的思考力」「興味（好奇心）」の3つがプログラミングを学ぶ上での土台になっていると思う。長い目で考えれば、土台がない状態でプログラミング言語を必死に学ぶよりも、土台を強くする方に力を入れたほうが何かと近道になる。数年後にどんなエンジニアになりたいかをイメージし、今やるべきことはなんなのかを考えて行動してほしい。

・視野を広く
焦ることは、集中力を上げることにはつながるけれど、気持ちに余裕がなくなると視野を狭めることになる。視野を広く持ち、目の前のことに追われるだけにならないように注意しよう。気持ちに余裕を持って将来のために今できることはなんなのかを考えれるようにしよう。

・Web系の技術
HTML、CSS、JSに苦手意識を持つ人が多いらしい。けれど、これは純粋に触っている時間の違いではないかと思う。長い時間かけて接しているとそれなりに仲良くなれる。苦手意識を持っている人が多いということは、逆にいうと自分の得意分野にしてしまえば強みになるので、今のうちに触ってみると良いかもしれない。

【感想】
丸一日自主学習だったけど、思ったよりも静か。もっと教えう感じでも良いのだけれど。静かな方が集中できる人もいると思うので、それはそれで良いのだけれど、静かすぎて後半は眠そうにしている人も多かった。全体の集中力とモチベーションを上げつつ効率的な学習に導く手法を色々と試してみたい。

23日目

【講義内容】
・Java（単元課題1日目）
オブジェクト指向を活用した簡単なWebアプリの作成。

【講義以外】
・練習と経験
タイピングなどの、体で覚える系の技術は、練習をしないと伸びない。経験を積んだところで伸びないので、ちゃんと身につけようと思うなら、明確に上手になるという意識を持って練習する時間を作ることが大事。スポートやアートなど、おそらくどの分野でも同じ。経験は、気づきを得るためには重要だけど、スキルを身につけることにおいてはあまり役に立たないので、経験をきっかけとして練習をすることが大事。

・勉強も同じ
勉強も、ただただ長時間やっていれば身につくものでもない。明確に、この部分を理解したいという意思を持って勉強をしなければ、身につくものも身につかない。身につけたい技術があるのなら、経験に頼らずに、身につける意識を持って練習に取り組もう。

・気持ちや体調の波
人間なので、気持ちや体調に波があるのは仕方がない。いつも同じモチベーションを保てるのなら良いけれど、なかなかできないのが普通の人。体調が良い日に、できることをできるだけやっておいて、気分が乗らない日があっても大丈夫なように調整しておくのも一つの手。

【感想】
単元課題は基本、発展があるけれど、初日で発展まで終わらせる人がちらほら。優秀な人が多い。

24日目

【講義内容】
・Java（単元課題2日目）

【講義以外】
・アウトプットする
モヤモヤしているとき、煮詰まっている時は、人に話したり、紙に書き出したりなど、アウトプットすることで思考が整理されて問題が解決されることがある。なので、頭がごちゃごちゃしている時には積極的にアウトプットしてみよう。

・ゴールをイメージ
何かに取り組むときは、いつまでにどのくらいまでを終わらせるのかをイメージしておくと効率が上がることがあるので、演習や課題に取り組むときは、目標を決めて取り組んだ方が良いよ。

・振り返り
何かを経験した後は、それを振り返ることが大事。経験だけでは成長の伸び率はそれほど大きくはならない。経験の後に振り返りをすることで、成長の幅が多くなる。仕事をする時には、まずは納期に間に合わせることを優先して、終わった後に時間をとって振り返ってみることが大事。

・コードを見てディスカッション
課題を提出した後は、研修生同士でコードを見せ合いながら、どうすればより洗練されたコードを書けるかをディスカッションしてみると良い。人に見てもらう事で自分にはない発想や書き方を得られるはず。

【感想】
復習や課題の日はみんな静か。わちゃわちゃと騒ぎするのも良くないけれど、眠気覚ましとして適度に話したりしてほしいな。けどみんな課題を提出して、追加で出した発展の問題まで取り組んでいる人も多くて素晴らしい。

25日目

【講義内容】
・SQL
この日からデータベース。初日はSQL。
2日かけてやる内容、ほぼ1日で終わらせてしまった。
比較的みんなついてこれている。ように思う。コマンドライン操作から早めにGUIツールを導入したことと、あらかじめSQL文を用意しておいたから早く進めることができたのかもしれない。

【講義以外】
・悩むと考えるの違い
悩むとは、問題を複雑にしている。考えるとは、問題をシンプルにすること。問題解決をするには、違うアプローチを考えることも重要だけど、それ以上に問題設定がそもそもあっているかを考え直すことがとても大事。「イシューからはじめよ」を勧めた。

・タイピング練習のコツ
まずはホームポジションを覚えることが大事。それから、見ないで打つ練習。自分にあったタイピングゲームを見つけて、コツコツと練習しましょう。

・振り返りのコツ
KPTという振り返りのフレームワークがある。演習や課題提出後の振り返りの際に活用してみてください。また、振り返りは大事なので、そこそこ時間をかけても良いと思う。その分、他の作業で時間を効率化できるようにして振り返りに使える時間を増やすと良いかと。

・わかりやすいコード
日が経つと、自分で書いたコードですら覚えていない。なので、わかりやすいコードを書く技術はすごく大事。プログラムを書くことにある程度慣れてきたら綺麗なコードを書く技術も勉強することをお勧め。

デバッガの使い方
プログラム書くことに慣れてくると、プログラミング力＝デバッグ力と言っても過言ではない感じになってくる。今のうちにデバッガの使い方に慣れておこう。デバッガの使い方に限らず、コードを読む以外でプログラムのバグを発見する手法を身につけておこう。

【感想】
最初からコードを用意しておいて、それを動かしながら講義するスタイルも悪くなさそうだ。コードにコメントを書きながら講義を受けている人が多分多いみたいで、それは結構有効な講義方法かもしれない。

26日目

【講義内容】
・SQL、DBMSの機能
1日目でSQLの講義をほとんど終えてしまったので、あまりやることがなかった。ので、DBMSの機能について紹介。インデックス、ビュー、ストアドプロシージャ、トランザクションなどについて説明。

【講義以外】
・おすすめの本
7つの習慣：読むの大変だけど、20代で読んでおくと良いかも。
死ぬこと以外かすり傷：会社員でありながらひたすらに自分のやりたいことをやる働き方もあると知れる。
サピエンス全史：歴史から学ぶことの本質を知れる
武器になる哲学：哲学を勉強すると納得できないことを減らすことができる。
SPY FAMIRY：最近ハマっている漫画。

【感想】
この日初めて、日報からコメントを広げることができなくて、フィードバックをすることができなかった。。なのでお詫びにスピーチという形でおすすめの本を紹介した。もっとトーク力を磨かなければ。でももう一回ぐらいやってもいいかも。

27日目

【講義内容】
・DB設計、正規化
テーブル設計と、正規化について講義。その後は名刺を使って、テーブル設計を考えるグループワークを実施。
正規化は毎年みんな苦戦する分野。今年も、多くの人が理解に苦しんでいた。

・３分間スピーチ（フリーテーマ）
自由すぎて意外と難しいよね。

【講義以外】
・体調管理
ただの風邪だとして時期的に色々と敏感になるので、体調管理は気をつけよう。

・スピーチ
憂鬱な気持ちもあると思うけれど、最後なので悔いが残らないように楽しんで取り組んでください。

・時間の使い方
自由な時間があっても、効率よく使えないとすぐに時間は過ぎていく。前日に、次の日にやるべきことを洗い出して整理しておくと、時間を有効に使いやすい。

・本の読み方
自分のレベルにあった本を読もうよ思わなくても良い。自分のレベルに合わない本を読むと、今の自分には何が足りないのかを知ることをができる。なので、自分のレベルなど気にせずに直感で読みたいやつを読めば良い。
個人的には、本を読みながら気になったところには線を引いたり、ページを折り曲げたりして、読み終わった後に振り返ってメモにまとめるのがおすすめ。続けていれば、どこかで役に立つ時が来る。

・人に説明する
人に説明すること前提で何かを学べば、それは必ず将来役に立つし、自分の理解度を深めるのに役に立つ。人に説明することを意識して学習をしてみよう。

【感想】
正規化のグループワークで思った以上に時間がかかって、演習の時間が取れなかった。やはりDB設計はもっと時間が欲しいな。レシートを使ったテーブル設計もやりたい。

28日目

【講義内容】
・JavaとDBの連携
JDBCを使ってJavaからDBに接続する方法を解説。

・３分間スピーチ
今回は時間をオーバーしたり、時間が足りなかったりと、やり直しになる人が多い。
また、PC操作がおぼつかない人も。PC操作に関しても、本番と同じ環境でしっかりと準備をするように。

【講義以外】
・凡ミスを減らすには
半分はおそらく意識の問題。責任感が高まれば高まるほど意識が高まるので、凡ミスは減る。それでもミスする時はミスするので、それは個人的には諦めている。ツールやプログラミングなどのIT技術を使って、ミスを防ぐ方向で考える方がきっと良いと思う。

29日目

【講義内容】
・DAOとDTO
DBアクセス処理を実装するときのクラス設計の話。
・DB設計についていくつか補足説明
外部キー制約の話。論理削除と物理削除の話。
・JavaEEにおけるDB接続の解説

・３分間スピーチ
それなりに順調に。

【講義以外】
・本番環境での準備
人前で発表をするときには、本番環境での準備を念入りにすること。
練習ももちろん大事だが、練習以外でも成功させるための準備は全て手を尽くすこと。

・やることの洗い出し
1日自由な時間があると、有効に使うのは意外と難しい。前日のうちに、次の日に何をやるのかを決めて洗い出しておいた方が良い。ので、次の日の総復習のために今日中にやることを洗い出しておきましょう。

・時間を奪わないために
スピーチにでやり直しになると、自分が嫌な思いをするだけでなく、みんなの時間を奪ってしまうことにもなる。自分の時間を有効に使うために、そして人の時間を奪わないためにも念入りに準備をしよう。

【感想】
そろそろ研修が折り返し地点。早いような遅いような。なんとも言えない感覚。

30日目

【講義内容】
・DB連携の総復習

【講義以外】
・リフレッシュ
全体的に疲れが見える。連休が終わり、やることも多く、内容も難しくなってきた。一気に疲れが出てくるのもわかる。疲れが溜まると、集中力も持続しないし、精神的にも落ち気味になってくるので、疲れている時は無理せず早く帰ってリフレッシュしよう。体調管理も大事な仕事。

・周りへの影響
疲れていると怠けたくなる気持ちもわかる。けれど、怠けているのが周りに伝わると、その気持ちは周りに伝染して全体の空気感に影響を与える。

・技術への興味と人への興味
エンジニアとして成果を出せるのは、技術への好奇心が高い人と、人への好奇心が高い人。技術への好奇心が高い人は、自分から進んで色々と新しい技術を勉強することができるので、長期的には大きく伸びる。人への好奇心が強い人は、ユーザーを観察してユーザーが求めているものを察知することができるので、良いシステムを設計することができる。両方を兼ね備えている人は強い。

【感想】
みんな疲れていて静か。もっと教えあって高め合える空気になってほしいけれど、ちょっとだれてきている感じがあるかもしれない。

31日目

【講義内容】
・DB連携単元末テスト
・DB連携単元末課題
DBを使ったちょっとだけ本格的なWebアプリの開発

【講義以外】
・汎用的な知識や考え方
Javaでしか使えないメソッド名のスペルなどを細かく覚えたとしても、言語が変わった瞬間に使えなくなるので、あまり意味はない。DBに接続する流れや、デバッグのコツなどは、言語が変わっても使える技術。言語や時代に左右されない根本的かつ汎用的なスキルを身につけることを意識して学習すると良いかと。

・目標を決める
今日の時点でどこまで終わらせるのか、目標を決めておくと集中力が持続しやすいと思う。是非とも目標を決めて取り組もう。
その上でやるべきことを洗い出して作業に取り掛かることで効率を上げることができるはず。

・仮眠
お昼後は眠くなる。お昼休憩に昼寝するのもあり。ご飯を食べると眠くなるので、食べないというのも一つの手段。あるいはロビーで思い切って10分〜15分ぐらい寝るというのもあり。

・エンタメとアートの違い
エンタメ→多くの人の共感を得ることが大事。分かりやすさと、顧客に寄り添うことが大事。
アート→自分のやりたことを徹底的に貫き通す。一部の人に深く突き刺さることが大事。
どっちが良い悪いという話ではなく、それぞれの特性がある。ビジネスはどちらかと言えばエンタメより。技術力が身についてくると、アートに近いことができるようにもなってくる。

【感想】
全体的に静かで全然質問がない。これな良くない。来週に質問について色々と話をしよう。

32日目

【講義内容】
・DB連携単元課題2日目

【講義以外】
・報告について
単元課題の報告の質が悪いので、改善をはかる。
1. チャットと口頭での報告→OK. そのまま続けてください。
2. 時間→遅い人がちらほら。自分が上司の立場になった時、帰る直前に報告に来たらどう思う？時間に余裕を持って報告をしましょう。
3. 報告の精度→悪い。1日目の進捗が２〜３割にも関わらず、2日目に提出するという報告が散見される。普通に考えて、1日目の進捗が２〜3割なら、2日目の進捗は4〜６割だと考えるのが妥当。しかし、それでは提出はできないはず。提出できないなら、事実をそのまま伝え、いつまでに提出できるか、現状の改善策も合わせて報告する。提出できるなら、その根拠となる理由も同時に報告する。いずれにせよ、誰が見ても同じ解釈ができ、納得できる内容の報告をすること。

・質問について
課題の日だが質問が少ない。期限が2日しかない単元課題の1日目で、全く質問がないのに進捗率が２〜3割というのは、何をしていた？と言われて怒られても文句言えない。質問をした結果で２〜３割だというのなら、対応策を考える流れになってもおかしくないが、質問なしで進捗率が4割以下の場合、そもそもの取り組み姿勢に問題がある。積極的な質問をして、期限に間に合わせるための行動を取ること。あるいは、事前の相談があれば対応策を考えることもできる。相談もなく、質問もなく、蓋を開けたら進捗が悪いのが最も良くない。

・報連相と質問
報連相と質問について深く考えるのが嫌なら、技術を徹底的に磨くこと。
質問なしに自分の力だけで期限内で作れるなら、誰も文句は言わない。技術に自信がないなら、報連相と質問の技術を磨くこと。

・集中の切り替え
集中に入るための自分なりのルーティーンみたいなものがあると良いかも。

・下を見ない
自分より下を見て安心してしまうと成長が止まってしまう。成長という観点から見れば、下をみることにあまり意味はないので、自分よりも上を見て取り組むようにしましょう。

・ライバル
同期にライバルがいると成長しやすい。一緒に切磋琢磨できる仲間を見つけましょう。会社が異なれば研修が終わるとなかなか会えない。今のうちに繋がっておいて、定期的に会うのも刺激があって良いと思う。

・フライング
仕事を成功させるための真理と言ってもいいかと。一般的には良くないイメージがあるかもしれないけれど、仕事は結果を出してなんぼ。始まる前にどれだけフライングするかが、結果に直結する。スタートする前からゴール直前の状態までフライングしてしまえ。

【感想】
かりゆしウェアを着てみた。研修生から、誰かわからなかったという声が多発。服装でイメージってかなり変化するんだね。

33日目

【講義内容】
・フレームワーク
フレームワーク概要、SpringFramework
疎結合やらDIやらの話を中心に。

【講義以外】
・添付忘れにご注意
最近ちらほら日報の添付し忘れが出てきている。今一度送る前と送った後の確認をしましょう。

・進捗率の出し方
プログラムを作成するとき、どのようにして進捗を出している？
まずはロジックツリーを使ったり、紙に書き出してやるべきことを洗い出してみよう。その中で、全体の作業量（機能）に対してどこまで終わっているかを見極めて進捗率を出そう。
進捗率を出すとき、全く動かしていないプログラムも完成したとみなして進捗に含めるのはやめよう。実際に動かして動くものに対してだけ進捗に含める方が良いよ。

・応用力と抽象化の力
2桁の数の掛け算のやり方を、全部個別に調べようとする人はいない。掛け算九九と筆算の知識があれば、何桁の数値の掛け算でも時間をかければできる。プログラミングも、基本となる知識をおさえておけば、あとは組み合わせで実現できるものがほとんどなのだけど、個別の事象に対してネットでやり方を見つけようとする人がいる。これは「84✖️63」のような個別の計算の方法をネットで調べているようなもの。そんなものを調べたところで意味はない。基本を理解し、基本の知識の組み合わせで成立させることができるところまで落とし込むことが大事。

・リファクタリングのタイミング
リファクタリングは、早い段階でやっておいた方が良い。ただし、実際の業務だと納期もあるので、納期ギリギリの段階でリファクタリングをするのは現実的ではない場合も多くある。タイミングを見極めて、やった方が良い時に適度にリファクタリングをしていこう。

・問題解決の手法
問題解決をするときは、問題がある箇所を徐々に狭めていくことが大事。どのファイルに問題があるのか、どのコードに問題があるのかを、徐々に狭めていけるように問題解決に取り組もう。

・プライドを捨てる
プライドがあると成長の邪魔になる。素直になる。できないことはできない、わからないことはわからないと認めるところから、成長は始まる。できないことを認めてすぐに質問しよう。

34日目

【講義内容】
・Spring Web MVC
MVCの考え方と、Springを使った場合の画面やコントローラの作り方。

【講義以外】
・目的と手段パート２
演習問題、単元課題において目的と手段が逆転しているように思う。演習や課題をやる目的はプログラミングの理解を深めること。そして、質問力や報告力などの、社会人としての基礎スキルを鍛えること。演習や課題を提出すること自体が目的になっていては本末転倒なので、気をつけよう。
演習や課題をやっている中でエラーが出たり、うまくいかないことはあるはず。その時にまずやるべきは原因を知ること。原因を知らないまま、解決策を求めて解決後に提出するのが最も良くない。理解を深めることができなければ、そもそもの目的を達成できない。
演習や課題が提出できなくても、最終的にプログラムが自分の力である程度書けるようになっていれば評価は高いし、逆に提出ができていても自分の力でプログラムが書けなかったら評価は低い。目的と手段を見失わないようにしよう。

・空気作り
質問しやすい空気、しにくい空気というのは確かにある。が、空気というのは自分で作るもの。環境に求めるものではない。自分が働きやすい環境は自分で作っていくもの。働きにくいと思っても、働きやすい環境を会社に求めても解決しない。自分で働きやすい環境を作るように動いていくことが大事。

・スキルの掛け算
今の時代はスキルの掛け算でその人の人材価値が決まる。プログラミングだけそこそこできる人はたくさんいるけど、プログラミングができて営業ができて経営もできる人は多くない。希少価値が高い人になれば会社から重宝されるし、自分のやりたいこともやりやすくなる。

【感想】
フレームワークに入ってから、演習時間での質問が増えた。内容が難しいからなのか、危機感なのか、業務意識の変化なのか。こういう変化は急に起きるので、何が要因なのかわからない。

35日目

【講義内容】
・Spring Web MVC + Spring JDBC
1日前に実施した内容と、2日前に実施した内容を足したもの。よって、新しい知識はほぼない。。ということで、講義として話すべきものはなかった。テキスト見ながら頑張ってください。

【講義以外】
・マークダウン記法
メモを取るときにすごく便利な書き方。NotionやVS Codeのプラグインでもサポートしてるので、マスターして使えるようになると便利やで。

【感想】
テキストが前年度よりもかなり情報量が追加されている。親切になってありがたい気もするし、ここまで書かなくていいのでは？と少し思ったりもす流。

36日目

【講義内容】
・Springの便利な機能
トランザクション管理、ロギング、バリデーション、メッセージリソースについて。バリデーションは結構便利よね。

【講義以外】
・楽しもう
エンジニアになるならプログラミングは楽しまないとやってられない。プログラミングを楽しもう。

・好奇心と探究心
サンプルのプルグラムをそのまま動かすのではなく、色々といじってみてどんなエラーが出るのか、動きがどう変わるのかを試せる人は理解のスピードがすごく早い。けど、そういうアドバイスをしてもやらない人はやらないし、何も言わなくてもやる人はやる。結局のところ、好奇心と探究心の問題。理解を深めようと思ったら、好奇心や探究心を芽生えさせることが大事。

・ながらタイピング
タイピングのスピードは大事だが、話を聞きながらタイピングしたり、話しながらタイピングする、ながらタイピングができるかどうかが重要。ながらタイピングができるなら、講義を聞きならがメモを取ることもできるので効率的。それができない人は、PC操作している時には話を聞いていないし、話を聞いているときはPCでメモが取れない。それは理解が遅くなって当たり前。研修の講義は今日でほぼ終わりなので、今更感があるけれど、今後のエンジニア人生を考えると、タイピングスキルは早めに磨いておくべき。

・チャレンジ
人間は失敗の数が成長の量と比例する。失敗の数を増やすにはチャンレンジの数を増やすしかない。いろんなことにチャレンジしよう。IT業界なんて、大きく失敗したところで誰も死なない。気軽に色々挑戦してください。

・やりたいことが決まらない
やりたいことは、なくても構わないと思う。与えられた環境で楽しんでそれなりの成果を出していれば、自然と色んな知識が身につき、できることも広がっていく。やりたいことがなくても仕事を楽しむことはできる。そういうタイプの人間もいる。

・スペルミス
フレームワークのエラーやうまく行かないことの原因の7割ぐらいはスペルミス。

・リーダーについて
来週からグループディスカッションが始まる。グループのリーダーを決めてもらう。リーダーの仕事は、ゴールを決めること、チームビルディング、トラブルシューティング。コミュニケーションが一番の仕事かもね。責任もあるが、学べることは多い。研修は失敗しても誰にも文句は言われないので、思い切ってやってみるのもありかもね。

【感想】
フレームワークのこの辺の細かい知識は普段から触ってないと案外覚えていない。Springを使って開発も一つやってみるべきかな。

37日目

【講義内容】
・フレームワーク総復習
・グループディスカッション
この日からグループディスカッションを実施。６人１グループに分かれ、それぞれのグループでディスカッションを行います。テーマはグループ開発で開発する成果物に対する要件定義。

【講義以外】
・IT業界の知識は他の業界でも役に立つ
IT技術は、IT以外の業界で働いても役に立つ。IT業界でスキルを磨いて、他業種の仕事で活かすことも長い目で見るとアリかもね。

・プログラムの書き方の議論
コードの書き方について、色んな人と議論してみてください。自分では気づかなかった発想を知れたり、自分の考えをまとめたりすることができる。是非色んな人と相談しながらコードを書いてみてね。

・自己評価と他人から見た評価
個人開発の期間で復習をしたい人は、事前に相談ください。という話をしたら、相談に来て欲しい人は相談に来なくて、意外な人が相談に来ている。面白いね。自己評価と、他人から見た評価は差があるということでしょう。

【感想】
初めてのグループディスカッション、みんな四苦八苦している。議事録を取るのも大変だし、意見をまとめることにも苦労している。２週間あるので、色々試行錯誤して成長してくだされ。

38日目

【講義内容】
・フレームワーク単元課題
・グループディスカッション

【講義以外】
・議事録重要
基本設計をするとき、議事録の内容だけを頼りに設計資料を作ったことがある。議事録の内容が粗かったらできなかった。議事録を細かく書くと、意外なところで役に立ったりするので、参加していない人が見てもわかる内容を心がけて。

・Excel力
Excelはエンジニアでもそうでなくても、実務では何かとよく使うツール。使いこなせて損はない。せめて機能を一通り知って、ショートカットキーを覚えておくだけでもかなり仕事の効率アップにつながるので、時間がある時に勉強してみてね。

・チームの協力
議事録を書くには、発言している人が議事録を取りやすい形で発言してあげることも大事。話すスピードや話の構成を意識してみよう。

・論理的に伝える
論理的に伝えるには、結論→理由の順番で、1文を簡潔に伝える。
話始める前に準備していること、そして相手目線で話すこと。

・雑談のきっかけ
休憩時間に雑談するのが苦手な人は、ディスカッションで人と話すことに慣れてください。

【感想】
復習をしたいと相談に来る人が多くて、なんやかんや3分の１ぐらいは課題をやらずに復習をする感じになった。意外とみんな不安がっているのね。

39日目

【講義内容】
・フレームワーク単元課題2日目
・グループディスカッション

【講義以外】
・頭の切り替え
実務になると、開発をしながら途中で会議が入ったりすることがよくある。ので、自分なりの頭のスイッチ切り替える方法を今のうちに試行錯誤しておくのは良いかもね。

・後悔しないように
研修も残り1ヶ月。後悔しないように過ごしてください。ディスカッションで、言いたいことを言えずに終わるのは良くない。自分が言いたいことをちゃんと伝えるようにしよう。

・情報共有
ディスカッションで議事録を書く人と、それ以外の人で情報共有が出来ていないとのこと。Zoomの画面共有などを有効に使ってください。

・Excelのセル結合
議事録を書くときにセル結合して書いてる人が多い。否定はしないけれど、、セル結合はコピペしにくかったりと、色々と面倒な場面が多いので、使わなくていいなら極力使わない方が良いよ。

・フレームワークの利点
フレームワークを使うことのメリットを感じてもらえたのであれば、それでOK。

・フレームワークでの問題解決
フレームワークを使っていると実行時エラーが多く出るので、問題解決に時間がかかるという意見も。しかしこれは、自分が知らない技術を触るときの問題解決にも通ずるところなので、問題解決力の向上のためのツールとしてフレームワークの課題を有効に使ってほしい。

【感想】
最近、お昼ご飯をどうするか悩む。食べにいくところが全然なくて、１階の食堂か近くのコンビニしかないので、流石に飽きてきた。

40日目

【講義内容】
・開発工程（開発工程の説明、開発手法の解説）
・テスト工程
・Git
・グループディスカッション

【講義以外】
・準備で仕事を効率化
家に仕事を持ち込むのはよくないかもしれないけれど、仕事を効率化するために準備をしておくことは大事。仕事で使うであろう技術を事前に勉強したり、会議などでの発言内容を事前に考えておくことが大事。たくさん仕事をして仕事を覚えようとするのではなく、仕事を効率よくするための勉強に時間を使おう。

・意思疎通（ディスカッション）
チーム間で意思疎通できていないと、開発の時にうまくいかなくなる。自分の伝えたいことを伝え、相手の意見を引き出し、最後に認識を合わせる時間を作ると良いかも。お客さんと話をした時にもお互いの認識が合うように今のうちに訓練しておこう。

・作業ログ
開発をするとき、作業のログをテキストで残しておくと、後々役に立つことが多いので、おすすめ。

【感想】
・Gitの講義、色々と難しい。。
自分自身、もっとGitについて勉強せねば。

41日目

【講義内容】
・総合確認テスト
これまでの研修内容の全範囲のテスト。研修開始時よりも成長していることを実感してください。
・グループディスカッション

【講義以外】
・個人開発
来週からは個人開発。個人の作りたいものを作る。
ノルマや制限は特にない。強いて言うなら「手を抜かない」「楽しむ」ことが条件。この2つを満たして、自分にとってプラスになる時間として有効活用してほしい。

・名前の決め方
システムの名前って重要。コンセプトとか、思いが大事。いい名前をつけてね。

・目的を見失わないように
ディスカッションをしているとき、話がそれたり、目的を見失って細かい話になりがち。目的を見失わないようにしよう。ファシリテーション能力を持った人がうまく舵取りをしよう。

・1日のスケジュール管理
個人開発やグループ開発では、個人での時間管理が重要になってくる。自分で1日1日目標を立てて効率よく作業を進めよう。

・スケジュール管理
スケジュール通りに進めることが正しいという風潮もあるが、実にウォーターフォール的。それが悪いとは言わないけれど。大体の物事は予定通りには進まない。予定外のことが何かしら起きる。コロナがその最たる例。想定外のことが起きても、その状況に合わせて柔軟に対応して、目的達成のために行動できるかが大事だと思う。アジャイル的な思考法。スケジュールは目的達成のためのツールで、現状が良いか悪いかを把握するためのツールぐらいに考えても良いと思う。

・ディスカッションに全員参加すること
議事録で名前が出てこない人がいる。議事録で名前が出ない人は、議事録しかみていない人からしたら参加していないのと同じ。ディスカッションに参加しているなら、積極的に発言すること。参加して発言しているのなら議事録に残すこと。

・印刷プレビューの確認
Excelで作成した資料は印刷して確認することも多い。印刷プレビューも確認すること

【感想】
今週からグループを決めてグループディスカッションが始まった。まだ１週間だけど、グループの色が早くも出てきたかな？