Table of contents

2024年3月

2月の気持ち的なピークは過ぎました。

業務の話

• メインの機能実装は一旦終わり細かい改修による作りこみの時期に入ってきた。 気持ち的にはちょっと楽だけど、逆にいうとちょっと緊張感が緩んでいる時期。

• 最近、レビューする立場としてサービス内容とは別として、コード品質・統一感の面でコメントしてしまう場面が多々あって、その点が悩みがち 細かい内容を言ってしまうことも多く、コード品質面では重要だと思っているのだが、一方でそこをこだわったところで機能・ユーザ観点の面ではそこ意味ある？っていう葛藤が頻繁に湧き出てくる 時間が有限を承知の上で、サービス面でもコード品質でも、両輪でこだわってベストを尽くす心持ちでやっているのだが、そのこだわり意味ある？ってもし言われてしまったら、それを相手に納得できる形で伝えられるかというと難しいかも入れない。

• あと、もっと技術的な内容を日々キャッチアップして、話すような人が周囲にいてほしいなぁ～

まぁ、こういいつつ今の仕事はモチベ高くやれてます。

業務以外の話

• ようやっと、ひとつ書きたかった技術記事書いた。 もう少し、技術記事のフォーマットを作って、もっと簡単にアウトプットできるようにしたい。

• 先月宣言した親知らずの処置を実際ししました！えらい！ といっても、2本中1本なのでもう1本も近日処置予定

2024年2月

今月は佳境だった・・・。

業務の話

ひたすら実装

先月の振り返りでも佳境の片鱗を見せていたが、今月は月末目標に向けてひたすら実装してた。

当初は2人で対応する計画ではあったのだが、機能が複雑&ドメイン周りの理解もない状態からのスタートなこともあり、開発期間に対してペースが遅れがちであった。

そのため、現状のままだと間に合わないと思ったので、途中から他の人のヘルプも求めて、 全体をおおまかに自分が取り仕切りながら最終的に5人程でなんとか主要部分に関しては今月で一旦間に合わせることができた。

また同時に、ある機能については自分が数カ月前に携わった内容でもあったため、実装には入っていないが実装担当の人の進捗管理を軽くしていた。

といっても、最初にタスク一覧をまとめて、タスク割り振って、自分も一部レビューに入ったぐらいであまり大したことはしてない・・・って思ったけど、文章に書き出してみるとこっちもまぁやっていたな。

業務以外の話

今月が佳境だったのでなにもできなかったです。

今年も2カ月過ぎているので、一旦やりたいことなどを見直してみる。

• サービス関連

  • データ分析 ❌

    興味はずっとあるんだけど、優先度は低くなりそうでペンディング

  • プロダクトマネジメント ⭕継続する

• エンジニアリング関連

  • コード設計 ⭕継続する

  • DB・SQL ⭕継続する

  • テスト ⭕継続する

  • 主要ライブラリの仕組み ⭕継続する

    実際に実務に使用しているもの優先

  • HTML・CSS・TSの基礎を勉強 🆕

    正直志向性はバックエンドなのだが、フロントの実装・レビューにだいぶ時間がとられるので

  • C・Rust周り🔺

    興味高いんだけど、どうしても優先度的には低めになってしまう

• 個人開発 🆕

  ネタは少し思い浮かんだ。 技術選定とかを考えないといけないが、Webアプリで使われるイメージがないので知識のないアプリ周りを調べる必要がありそう。

前回からのアップデートとしては、

• 個人開発でやってみたいネタがちょっと浮かんだりもした。

  ただ、Webではないアプリ向きな内容かなという印象で、知識ゼロからの情報収集からなので時間はだいぶかかりそう。

• 基礎的なフロントエンド周りの内容を押さえた方がいいかなぁという思いが出てきた。

  実装・レビューの際に適した内容かの判断に時間がかかりがちなのと、なにかサービスを作りたいと思う上で最低限のフロントエンドの実装力はやっぱり必要という考えがずっと頭の隅にあったこともあり、フロントエンドの方に意識的に目を向けようと思う。 こういいつつ、自分の志向性にあうCLIやバックエンドは自然と学習していく（それこそフロントエンドの勉強の合間とかにも）と考えている。

あと、技術記事ネタがいくつか浮かんでいるのでそろそろ書いていきたいですね。

2024年1月

端的にいうと、業務の仕事がだいぶ佳境に入っています。

業務の話

仕様由来で実装が大変

今、既存コードをベースに、新たな環境（リポジトリ）にリファクタしながら書き直す業務を行っている。 この既存コード及びそれに関わるサービス仕様が難しい（ある種のアンチパターン？）ゆえに、実装がだいぶキツイ状況になっている。

具体的には、こちらが自由に設定した質問に対してユーザに回答してもらう機能があるのだが、この質問フォーム作成の一例において、たとえば複数選択肢形式の場合、現状が以下のような仕様である。

• 複数選択肢を2段階の入れ子構造で自由に設定できる(質問数の上限などもない)
• 選択肢の順番も自由に設定できる（作成の際に選択肢をあるルールでソートとかもない）
• 上記フォーム構造をDBにjson形式で格納して、フロントではそのjsonをもとに質問内容を形成している。 また、その回答内容も別途違う形に整形したうえで、DBにjson形式で保存している

フロントはJavaScriptでDOM操作をバリバリやっており、json形式で保存されているフォーム構造の型が動的なせいで、バックエンドのデータ保存前のvalidate・整形もどう頭をひねっても手続き的に愚直に書くしかない。（ある程度宣言的な形で書いたりしたが、それにしても普段使わないような機能を使って実装しているので、正直保守面を考えたときちょっとしんどいだろうなと思う。）

このような実装になるのは、そもそも当時実現させた仕様（フォーム作成の設計）が、実装への落とし込みを考慮していない自由度が高すぎる仕様で、本当はもっと実際のビジネスフロー（利用方法）をもっと精査したうえで、実装難易度とのバランスも考慮した仕様への落とし込みが必要だよなぁと思わされる内容であった。

あと1カ月はこの内容で手いっぱいで他のやりたいことができない気がする。

このタスクが終わった後に、そもそも上記のような内容を実現させるとしたら、どうゆう設計・データ構造で構築すべきか、など考察してみたい。

業務以外の話

今年は毎月1つちょっとしたレベルでいいので、ちょっと先延ばしにしていることを取り組んでいきたいと思っている。 なので、ずっと先延ばしにしている歯医者の予約（親知らずの治療）をそろそろやります・・・。

来月はどうしようかな・・？