2023年の振り返り
去年も書いたの、今年も振り返り記事を書こうと思います。
2023年1月~3月
プロジェクトにも参加してましたが、この期間は正直泣かず飛ばずで皆無といって言いくらい良い思い出はないので割愛します。
2023年4月
この月は札幌で初めてのオフラインもくもく会を開催したのとリリース作業で四苦八苦したという 良い思い出と悪い思い出が両方あった月だったと思います。
余談ですが札幌オフラインもくもく会は今まで自分が主催した中で一番良いもくもく会だったと思っています。 もしかしたらもう一度くらい札幌でオフラインもくもく会を企画するかもしれません。
2023年5月~7月
この期間はJavaのサブ講師で色々と頑張っていました。 講師業務は今まで一度も経験したことなかったので、良い経験だったと思います。 またこの案件でJavaという静的言語に初めてさわったので、これもまた貴重な経験だったと思います。
2023年8月
人生で初めてコロナにかかりました。 治った後も、後遺症で結構大変でした。 ここだけの話、大きな病院で精密検査を受けないといけないほどの大事態にまで発展しました。 ただ検査の結果、大きな病気にかかっていないことが判明したので良かったです。 この一件で健康って本当に大事なんだという事をつくづく思いましたね。
2023年9月~12月
現在のプロジェクトでテスターとして打鍵作業をひたすらやってます。 人生初の客先常駐でかなり緊張しましたが、メンバーの皆さんも親切なのでその点は本当に安心しました。
（ただ色々とご迷惑をかけることもしばしばありますが💧）
2023年9月
RUNTEQ生主催の札幌オフラインもくもく会に参加しました。 自分が札幌でオフラインを企画した理由の一つに 「北の大地にオフライン文化を根付かせたい」という思いがあったので 企画していただいて非常に嬉しかったです。
2023年11月
悲願だった東京のRUNTEQ教室でオフラインもくもく会を企画しました。 当日、緊張しすぎてコミュ障が爆発してしまいましたが 参加者から「参加して良かった」と言ってくれたので、その点は安心しました。
最後に
今年1年を振り返ると、エンジニアのキャリアとしては 「正直いかがなものか？？」と思ってしまうのですが 札幌と東京でオフラインもくもく会を企画して無事開催できたので、もし2023年に対して点数をつけるとするならば 60点はつけたいと思っています。
（私は自分に対しての自己評価は基本的に甘めにつける主義なので🙇♂️）
またいくつか振り返りに書いた出来事の中で個別に記事を書いたものもあるので、そちらのリンクを貼っておきます。
札幌オフラインもくもく会
札幌オフラインもくもく会開催しました！！ - Doiya’s blog
Javaサブ講師
テスター
たかがテスター、されどテスター | ramble - ランブル -
RUNTEQ教室でのオフラインもくもく会
RUNTEQ教室でオフラインもくもく会開催しました！！ - Doiya’s blog
今回の記事は以上にします。皆様良い年をお過ごしください🙇♂️
RUNTEQ教室でオフラインもくもく会開催しました！！
本日(2023/11/25)、RUNTEQ教室でオフラインもくもく会を開催しまして、感想を述べたいと思い投稿することにしました。
これまでの経緯
2021年2月にRUNTEQに入り、これまで関西オフラインもくもく会（2022/06/26)と札幌オフラインもくもく会(2023/04/30)を開催しまして、いずれはRUNTEQ教室でやりたいという思いは前々からずっとありました。
二つのもくもく会に関しては以下の記事に記載しましたので、そちらをご参照ください。
それで今回東京に行くための都合が取れて、「ここしかない！！」と思い開催することに決めました。
どんな感じで開催したか
めちゃくちゃシンプルにしました。本当にただもくもく勉強する感じでした。 本当はレクリエーションを入れても良かったかもしれませんが、今の自分にはその時間と余裕がなかったですね。 なので、参加した方々は、あれで参加して良かったと思っていただいたかどうか不安は残りますね。
ただ、参加者の一人に「美味しい中華料理屋があるので、そこでみんなで昼食取るのはどうですか？？」と提案していただいて そこで何人かのメンバーとお話しできて良かった気はします。
反省
自分にとってはRUNTEQ教室で開催するのは悲願だったので、ちょっとエンジンがかかり過ぎてた感じはします。 もう冒頭の挨拶から噛み倒したり、言葉が思い出せなかったりして コミュ障が爆発した感じがします💧次やるときはもう少し落ち着いてやりたいと思いますね。
RUNTEQ教室の魅力
これまで地方でもくもく会を開催したから分かるのですが RUNTEQ教室はもくもく会の会場として非常に良い環境だと思いました。 自分がそのように思った理由を以下列挙しておきます。
無料で勉強できる環境を用意してくれる。（RUNTEQ出身者のみ）
まずはこれですね。他の会場だとまず場所を押さえて、そこの会場代を参加者同士で折半することになり お金がかかるんですよね。おまけに会場によって当たり外れもあるので、確実に勉強できる環境があるというのは 自分は非常に魅力的だと思いました。
直前まで参加者を募集できる。
上記と重なる所はあるのですが、他の会場だと参加人数を決めて予約をするので 少し早めに参加募集を打ち切るんですよね。ただRUNTEQ教室では定員は決まっていますが 定員に達していなければ、直前まで募集をかけられます。今回のもくもく会では 当日に参加表明して来てくれた方もいました！！（1名空きがあったので）
お世話になった人に会えるかもしれない。
もしかしたらお世話になった講師やCTと直接会える可能性があるのは魅力的だと思いました。 実際、今日2名CTの方がいらっしゃったので。
ざっとこんな感じですね。
地方勢からしたら、あの環境は魅力的なのでめちゃくちゃ嫉妬しましたよ笑
おそらく定期的にRUNTEQ教室では色々と催し物があると思いますので 関東近辺に住んでいる方で自分が行ってみたいイベントがあれば、適宜参加してみることをオススメします。
最後に
自分は18期(2021年2月入学)で結構古株なのですが、そこまでつよつよのエンジニアでもないので
「自分のような人間がもくもく会を開催してもいいのか」
「現役のRUNTEQ生もしくはつよつよエンジニアに委ねた方がいいのではないか」
という葛藤が正直ありました。
ただ今日参加者の一人（少し古い期の方）に
「現役のRUNTEQ生がもくもく会を開催すると、躊躇して参加するのを戸惑うけど 自分のような古株が開催すると、気にせず参加できる。」と言われました。
このことを聞いて、こんな自分でも開催して喜んでくれる人がいるのであれば
不定期にはなるかもしれないけど
自分がエンジニアを続ける限りオフラインもくもく会を開催し続けよう！！
そう心に決めましたね。
長々と書きましたが、以上です。失礼いたします。
エンジニアになって丸1年の振り返り
タイトルにも記載した通り、エンジニアになって先月末で丸1年が経ったので、節目として振り返りの記事を書きました。
前提
基本的に自分が経験したことをベースに書きます。 なので、エンジニアとしてもしかしたら相違する所はあるかもしれませんが その点をご了承した上で見ていただけると幸いです。
実現できたこと
一年間働けたこと
諺で「石の上にも3年」というものがあるかと思いますが、もし会社と相性が悪ければ自分は同じ会社に3年もいる必要はないと思いますが、弊社のことを知るためにも最低限「石の上にも1年」は必要だと思ってました。なのでまず丸一年やり切ったことは自分のことを褒めてあげたいです。
札幌オフラインもくもく会を開催できたこと
自分が札幌に引っ越した当時、北海道でオフラインもくもく会を開いた人がRUNTEQコミュニティ内でいなかったので こちらを実現できて良かったなと思います。あれから現役のRUNTEQ生も札幌でオフラインもくもく会を開催してくれたので 多少、北海道在住の方のコミュニティ形成に一役買うことが出来たのではないかと思っています。
札幌オフラインもくもく会に関しては、以下の記事で詳細に記載しているので宜しければご覧ください。
正社員になれたこと
私事で申し訳ないのですが、自分は数年間非正規で働いていたので 正社員になることを無意識に懇願していました。いつ正社員になったかは伏せますが 弊社で久々に正社員になることが出来たので 嬉しかったですね。
経験したこと
正直申し上げてまだ胸を貼って誇れる経験をしていないのですが、とはいえタイトルに「エンジニア」と記載したので 今から捻り出して列挙します💧
Javaサブ講師
まず真っ先に浮かんだのは、これですね。こちらに関しては以下の記事で詳細に書いているので もし宜しければご覧ください。
リリース作業
本番環境ではなく検証環境だけど、リリース作業を経験しました。 ここでGitで手痛い思いを沢山しましたね😰 おかげさまで多少はGitのことについて色々と勉強できたかなと思います。
またここで実務での開発の流れを知ることが出来ました。 弊社はざっくりとこのような流れで作業しています。
1 要件定義 2 設計（詳細設計） 3 製造 4 単体試験 5 結合試験 6 検証環境リリース作業(自分が経験したのはこちらです。） 7 総合試験 8 本番環境リリース作業
また上記の作業をする前に、手順書（ドキュメント）を書くんですよね。 自分も検証環境のリリース作業の際、手順書を書いて弊社の品質管理担当の方にレビューをしてもらいました。
自分が一番実務と個人開発の違いを感じたのはこちらでして
実務ではドキュメントを書く機会がかなり多いんだなと思いました。
（他の会社がしてるかどうかは分かりませんが）
その他
「自分が知らない作業を依頼された場合、このように対応してください。」 と指摘されたことがあるので、そちらを記載しておきます。
①何を行う作業なのか ②これを行うことでどうなるのが正解か ③どうすれば目的を達成できるか おまけ 自分がやらかしたミスを報告する場合 何をしたのか、何をもってやらかしだと判断したのか、などは最低限伝えるようにする。
反省点
自主学習をあまりしていなかった
色々あってモチベーションが低下した時期がありまして これはもう懺悔するレベルであまりやってなかったです。
但しJavaサブ講師案件の時は人に教えないといけなかったので、この案件期間中は結構やってました。
2年目は「1 実務に関係あるもの 2 やってみたいこと」の順で自主学習をしたいですね。
また弊社では資格試験を受けている人も結構いるので、何か資格の勉強をするのもありかなと思ってます。
やりたい事
東京（できればRUNTEQ教室）でオフラインもくもく会を企画したい
ガチでやりたいです！！ 今まで大阪・北海道でオフラインの主催をしてきたので、
そろそろあそこでやりたいですね。
また「東京で働いているエンジニア」または「関東近郊在住でエンジニア転職を目指している方」がどのようなことを考えて日々を過ごしているのか知りたいのも理由の一つですね。
これはもう本当に有言実行したいので、近々実現に向けて動いていきます。
最後に
この1年、色々と悩んだり苦労したことの方が多かったです。（今も結構色んなことで悩んでます😅） 正直、大した実績も作れていないけどまずは1年間なんとかやり切ったことを他人から称賛されることはなくても 最低限、自分は自分のことを褒めてあげたいと思っています。
今回の記事は以上です。長文駄文失礼しました。
参考
コミットメッセージとgitignore
表題の件で学んだことがあるので、振り返りも兼ねて書きます。
コメットメッセージ
コメットメッセージって「fix:〜」って書くやないですか。このfixの部分をPrefixというらしいんですけど どのように使い分けたらええのか以下の記事に記載があったのでまとめておきます。
Prefix一覧
feat: 新しい機能 fix: バグの修正 docs: ドキュメントのみの変更 style: 空白、フォーマット、セミコロン追加など refactor: 仕様に影響がないコード改善(リファクタ) perf: パフォーマンス向上関連 test: テスト関連 chore: ビルド、補助ツール、ライブラリ関連
あと理由づけを以下のように明確にした方が他のメンバーのことを考えると良いらしいです。
✖️chore: hogeを追加 ◯chore: ネットワーク通信するため、hogeを追加
gitignore
まずそもそも論、「gitignoreとは何ぞや？？」からなんですけど
gitignoreとはGitリポジトリ配下において、管理対象（追跡対象）から外すディレクトリや、ファイルを設定するための仕組みのことです。こちらに記載すると ローカルリポジトリ、リモートリポジトリの両方でのGit管理対象外になります。
ex .DS.Storeの場合
①touch .gitignore #gitignoreファイルを作成
②.gitignoreファイルに.DS.Storeファイルを追記
③git logなどのコマンドを打つと対象から外れていることが確認できると思います。
④ここからコミットメッセージを書いたりプッシュしたりする。
ちなみに.DS.Storeには以下のような情報があり、共有する必要がないのでコミットしないです。
・mac側で作成された独自の形式の隠しファイル ・Finderやリモート上アクセスする全てのフォルダに.DS_Storeそれぞれ作成される ・独自のメタ情報（例えば、フォルダ内のアイコンの位置や表示設定などが保存されているデータ）
ちなみに
うっかり不要なファイルをGitHubなどにプッシュしてしまった場合どうすればいいか？？
以下のように対処する。
ex .DS.Storeの場合
①touch .gitignore #gitignoreファイルを作成
②.gitignoreファイルに.DS.Storeファイルを追記
ここまでは一緒です。ただし
既にGit管理しているファイルはただ.gitignoreに追加してもキャッシュが残っているため反映してくれない。そのためキャッシュを削除する必要があります。
以下のように記載します。
③git rm -r --cached . -r : ディレクトリを再帰的に削除する→下層にあるディレクトリにも適用される —cached : インデックスからの削除だけを実行する（ワークツリーのファイルは保持する） ④git logなどのコマンドを打つとキャッシュが削除されていることを確認できると思います。 ⑤ここからコミットメッセージを書いたりプッシュしたりする。
ここまでするとgithubなどの画面上を確認してみても、不要なファイルが表示されなくなっていると思います。
参考
不要なファイル.DS_Storeを.gitignoreで管理対象外にする - やなぎにっき
git clone 素早くする方法
実務でファイルが多すぎて、なかなかgit cloneに時間がかかるという事象が発生しました。
その時に検索して使用したコマンドを記載します。
depth
こちらを指定すると、その数のコミットの歴史だけに限定したデータを取得する。
（別名：shallow cloneと呼ぶらしい。）
コマンド例
git clone --depth=1 https://gitlab.〇〇.co.jp/〇〇/〇〇.git
--depth=1と指定すれば、最後のコミット履歴のみ取得できる。
（それ以前の履歴は取得できない。）
git logなどで確認できると思います。
コミット履歴が多くなると、容量が多くなるみたいなので、もし最新のコミット履歴のみで良い場合は 上記のコマンドを試してみてはいかがでしょうか？
参考
Java サブ講師案件
今年の5月から7月まで対応した案件なのですが、色々思い出もあるので 振り返りも兼ねて記事を書いてみました。
どういう案件か
Javaのサブ講師を約3ヶ月間する。
(RUNTEQでいう技術サポーター的な感じだと思います。）
対象
自分（汗）
この案件で感じたことは自分の中で結構貴重だと思うので未来の自分に向けて書く感じです。 なので講師案件の仕事内容などはあまり記載しないのでその点はご了承ください。
仕事内容
とはいえ、どのような業務をしたかというとざっとこんな感じです。
日報などのコメント 質問対応 レビュー対応 その他、事務的作業
案件が決まった時の率直な感想
不安
何故なら、この案件が決まるまでJavaをほとんどしたことがなかったから。
なので受講生と一緒に一生懸命メイン講師の授業を聞いていましたよ。
実際どうだったのか
案の定、大変でしたよ。
まず受講生の質問に答えられないことがほとんどですからね。
とはいえ、何とか答えないといけないと思い、自分で後日調べたり
他の講師陣に質問して、受講生の質問に答える努力はしましたよ。
あと、初めて習った単元のレビュー対応をするって聞いた時は
冷や汗をめっちゃかいた記憶があります。
こちらも他の講師陣に相談しつつなんとかしました。
意識したこと
３つ意識したことがありますね。
・高圧的な対応をしない。
過去に自分が受講生の頃、上手い返答が出来なかったからなのか、講師やサポーターと言われる人たちに高圧的な対応をされたことがあり、それが今でも思い出すほどトラウマに残っています。（具体的にどのようなことを教えている学校でいつの頃に言われたのかは伏せさせていただきます。）
そのためどれだけ苦戦している受講生がいても、自分は優しく見守って教えるということは相当意識しましたね。
一緒に考える。
自分のクラスにもう一人サブ講師の方がいて、その方が非常に優秀で、ある時その人の対応を見る機会があったのですが
その方は「最後まで受講生の疑問点を一緒に考える。」という姿勢を感じたんですよね。
そうか。講師というのはすぐに解消することも大事だけど、自分でも分からない問題があれば、最後まで粘り強く考えてあげるのも大事なんだなということを学びましたね、
（このことを学んだのは、講師案件の最後の方だったので、もう少し早めに気づきたかったですね。）
・分からないことは素直に分からないという。
先ほど話した事と矛盾したことを書くのですが
どれだけ調べて聞いても分からない問題っていうのは正直あったんですよね。
このときは知ったかぶりをするのではなくて、潔く「自分では分からないので、メイン講師に聞いて下さい。」と言ったことは何度かあります。
一番重要なのは受講生が分からないことを解消することだと思ったので
このとき、自分が知ったかぶりして間違ったことを教えるくらいなら、別の方を頼ることの方がいいのではないかと判断しましたね。
評価されたこと
正直、案件が終わったときは全く評価されないと思ったんですよね。なぜなら経験不足もあると思うのですができないことの方が多かったので。ただ意外とお客様に評価されたことがあって
分からないことは素直に分からないと言ってたこと。
自分、最初この話題をお客様に言われたとき、怒られると思ってたんですよね。
だって、講師っていう職業は「受講生の疑問点を何としてでも解消すること」だと思っていたので
自分はその役割をあまりできていなかったので、注意されるのかなと思いましたね。
お客様曰く
「なかなか最初の頃は講師という面子やプライドがあって、知ったかぶりをする人が多いのだが
あなたは素直に分かりませんと受講生に伝えたり、日報のコメントであの質問は勉強になりましたと書いていたので
正直な人だなと思い、その姿勢は素晴らしいと思う。」
と言われました。
世の中、意外な所を評価してくれることもあるのだなと思いましたね。
ちなみに「日報のコメントであの質問は勉強になりました」に関して補足をすると
自分で分からない質問があったとき、他の講師陣に質問したりして、その受講生の質問に答えることが出来たときなどに素直に勉強になったと思ったので、コメントさせてもらった次第です。
最後に
一番嬉しかったことでも書きますか。
それは受講生に最後に「ありがとう」と自分達に言ってくれたことですね。
色々苦労したこともあったのですが、その言葉で疲れが取れたのは正直あったので、言われたときはすごく嬉しかったですね。
また機会があれば、やってみたい気持ちはちょっとありますね。
（結構、苦労したのでめちゃくちゃやりたいかというと微妙な所ですね汗）
エンジニアコミュニティ
RUNTEQのイベントで「エンジニアコミュティのいい所」というものがありまして 発表されたのは松井さんというAWSに詳しいつよつよエンジニアの方です。 以下はそのイベントの議事録です。
・エンジニアコミュニティに参加すると、客観的に自分の立ち位置がわかる。 ・コミュニティで技術などの材料を集めて、その材料を個人で調理する。（学習する。） ・コミュニティ活動している人ほど、評価が高い。 ・100回の参加より1回の登壇 ・アウトプットしない人は知的な便秘 ・コミュニティの開発は仕事ではないので、最悪失敗しても許してもらえる。 ・自分より初心者は絶対いるので、「こんなこと誰でもわかるやろな」的なことでも問題ない。 ・好きなコミュニティ、続けられるコミュニティを見つけることが大事
コミュニティ活動のフェーズ
①コミュニティを探す。（検索する。） ②コミュニティに参加する。 ③LT会などに登壇する。 ④コミュニティの中で開発をしてみる。（イメージとしてはチーム開発みたいな感じ）
有名なコミュニティ
松井さんが紹介されたオススメ記事
