1. アウトプットの大切さ
勤めていた会社ではアウトプットする機会がいくつかありました。
一つは会社が運用しているブログで、もう一つは月一回開催される勉強会です。
他にも社内チャットやチームで運用しているナレッジベースがありましたが、そちらはアウトプットというよりは情報共有に近いものでした。
一応ブログにはノルマがありましたが必須ではないので、更新頻度は人に依りました。
勉強会は持ち回りと立候補制での発表がありました。
私は未経験で入社したこともあり学んだことは積極的にブログの記事にしました。2記事/月のペースでした。
また、勉強会でもできるだけ積極的に発表するようにしました。
（ただそれでも勉強会で発表できるような内容を勉強して資料準備する時間が必要なので実際に発表したのは1年で3回でした。）
ブログの記事を書いたり、勉強会のスライドを作る作業は大変でしたが、やってみてアウトプットの大切さをとても実感できました。
良く言われると思いますが、頭で理解しているつもりでも実際に他人に説明すると浅い理解の部分が浮き彫りになります。
また資料の準備段階で、
「こんな質問が来るかもしれない」、
「自分がこの記事を読む場合はここについて詳しく書いておいてもらえると助かる」、
などと考えることもできます。
アウトプットする行為は慣れないと大変でしたが、一度慣れるとハードルも低くなりメリットの方が圧倒的に多いことに気付きます。
これらの経験から Sier から現職に転職した後も自分でブログを運用してアウトプットは継続しようと思いこのブログを始めました。
転職後の技術についてや書評、その他学んだことを記事にしていく予定です！
2. バージョン管理の方法・大切さ
元々メカトロニクス技術者として働いていましたが、当時の資料管理はよくある
・20230917_〇〇について.pptx
・20230917_〇〇について_最新.pptx
・20230918_〇〇について_最新.pptx
状態でした。
Sier に転職してからは、Git でのバージョン管理が当たり前だと知りました。
そのため、git add -A や git commit -m "コメント" は転職して一番最初に覚えたといっても過言ではないと思います。
そうして、Git でのバージョン管理を知り、実務で使用する中でバージョン管理の大切さや他の方との業務の進めやすさを学びました。
GitHub だとプロジェクトごとにリポジトリがあるので、あのプロジェクトのあの資料の最新が欲しい時にさっと見つけることができます。
また、メカトロニクス技術者時代だと、「あの資料更新したいけど最新ファイルを勝手に更新するのは良くないよなぁー」で、コピー&ファイル末尾に「_〇〇編集」などしていましたが、Git 管理だと、「ブランチを切って、編集して、プルリクエスト上げよう」と最新ファイルを汚すことなくレビュー依頼ができます。
ただ、プログラムファイルなどのテキストファイルの管理のし易さを知ると、エクセル、パワーポイント、ワードなどのオフィスファイルの管理のひと手間（いちいちローカルにプルしないといけない）は面倒に感じてしまいます。
ここをもっとうまくできればなぁと思わなくもないです。
3. 自分の作業記録を残すことの大切さ
上記の上に Git (ツールは GitHub) 管理していて、プロジェクトごとにリポジトリがあったので、作業記録は Issue として各リポジトリに残していました。
入社直後から先輩に、「メモとしてIissue を使ってくれていいからね」と言っていただいていたので本当にメモのように使っていました。
先輩はもう少し絞って要点のみ残されていました。
私は失敗したことも成功したことも、ただの作業記録も全て残していました。
Issue にすべて残していると、①数年後同じ作業が来たときのナレッジになる、②他の作業の割り込みがあり、数週間後作業を再開するときにどこまで進んで、何を考えていたのかの復習時間が極端に短くなる、③他の人への共有が楽になる、④書いて忘れることができるので他の作業に集中しやすい、というメリットがあると感じました。
Issue に作業記録を残すデメリットはないのではないかと思うくらいです。
転職後も GitHub など使用可能であれば、作業記録を残していこうと思います。
4. コミュニケーションツールの使い方
コミュニケーションツールとして、Slack を使っていました。
最初は、チャンネル、スレッド、メンション、ダイレクトメッセージ、、など何それ？状態でしたが、使ってみるとこんなに便利なものがあるのかと感じました。
（プライベートでも友人とプログラムを作成しようとしていますが、そこでも Slack を使っています。）
対面のコミュニケーションと両方のいい所取りをすることで作業効率が抜群に上がると思います。
- 対面のコミュニケーションは速さ（同期的な情報共有）があったり、親密なコミュニケーションが取れます。
- コミュニケーションツールでは距離・場所に依存しないコミュニケーション、非同期の情報共有、少し関係がある人への緩い情報共有ができます。
これらをケースバイケースで使い分けることが大切だと思います。
ただ、Slack の通知の最適化には苦労しました。
すべて通知していると通知地獄になりますが、通知しすぎないと急ぎの通知を見逃したりします。
関係しているプロジェクトはスレッド含めて全ての通知を受け、関係ないものは通知を一切受けないようにしていました。
ただ、これがベストな設定かは分かりません。
また、通知が来るたびに応答していると、通知に反応するだけで半日が終わったりします、、
自分の作業効率がベストになるように、通知は最適化していきたいですね。
5. 納品資料をきちんと定義してドキュメントとして作成することの大切さ
これはとても当たり前ですが、納品資料をきちんと定義し、資料を作成して納品することが大切だと感じました。
元々他の業者が担当されていた案件の更新を引き受けることが何度かありましたが、この当たり前のことを当たり前にされているところは意外と少なかった印象です。
前述の Issue への作業記録もそうですが、何かに記録を残す行為は作業に加えてひと手間工程が増えます。
納期まで時間が無かったりすると省いてしまう工程になりやすい気がします。
当たり前のことを当たり前に実行できるだけでも評価されるように思います。
6. IT スキル
インフラエンジニアだったので以下を学ぶことができました。
特に中小企業でしたので一人が担当する範囲が広く幅広く経験できました。
・Windows Server (Active Directory, WSUS, ファイルサーバー)
・Linux サーバー (RedHat 系)
・ネットワーク機器 (ファイアウォール、スイッチ、無線 AP)
コメント