2023年のふりかえり:はじめての機能リリースから始まった一年

現在、午後9時半過ぎ。紅白を見ながら2023年のふりかえりを書いてゆきたいと思います。

1月

前年の12月ごとから携わっていた機能をリリースしました。

小さな機能でしたが、はじめて関係各所と調整しつつ設計から実装までやったプロジェクトでした。

今年はいくつか機能の実装に携わりましたが、このときに上手くできたという成功体験が生きたと今では思います。

2月

大きめのプロジェクトの事前調整のようなタスクがあってあまり手を動かすことができなくなりそうだったので、個人でできそうな機能実装をしました( これが後に負担になるのですが。。。 )。

必要な機能は1〜2週間で実装してしまったのですが、お客さまとのコミュニケーションの準備が必要そうなので関係者にお願いして、とても大掛かりなプロジェクトになってしまいました(汗)。

3月

関係各所と話しながらお客さまとのコミュニケーションの設計をして、それを実装に落とし込みました。少々複雑な機能だったので半日ほどかけて4000パターンぐらいのユニットテストも書いてました。

既存の機能と実装コストを比較して雑に設計してしまった結果、4月にちょっとした出戻りをしてしまったのですが総合するとまあまあいい感じにできたんじゃないかと思います。

ただ、例の大きめのプロジェクトも進みだして。。。

4月

前述した出戻りとリリース、さらには「大きめのプロジェクト」の大きめの仕様変更で脳味噌がパンクしそうにになりました。

5月

お客さまとのコミュニケーション。「例の大きめのプロジェクト」も加速してきました。

6月

燃え尽きたぜ…真っ白にな…。「例の大きめのプロジェクト」。何も記憶ない。

7月

第二子が生まれました。

スクラムっぽい仕事のやりかたをとりいれました。Playwright をつかってE2Eテストのようなことも試しました。

8月

「例の大きめのプロジェクト」リリース。

9月

記憶ありません。たぶん「例の大きめのプロジェクト」の保守をしてたんだと思います。

あと、これまで雰囲気で ReactJS をさわってたのですが、わりと本格的に勉強しました。

10月

あまり記憶ありませんが。スクラムのポイント見積を「ちゃんと」するため、試行錯誤をしていました。

チームでポイントの見積は時間をかけてやって数字で表現できるのですが、実際手をつけてみると想定外のことがでてきます。このようなとき、見積で出した数字を変更しないと精度が悪くなってしまうという課題はあったのですが、それをチームとして合意するのに時間がかかりました(今もちゃんと合意できているのかと言うと微妙な感じはある)。

11月

チームの課題として「割り込みの業務が多いこと」であるという予想をたて、それを見えるようにすることを課題として取り組みました。

Daily meeting のやりかたや日常的なコミュニケーションを通して、見えなかった割り込み業務を明らかにすることができ、チームメンバーからもそれなりの評価をもらったと思ってます。

12月

テクニカルライティングチームの仕事を任せてもらえるようになりました。具体的には、textlint の導入と運用をやってゆくことになりそうです。

年末に軽いハッカソンのようなことをやって、自社の preset をつくったり、Google Spreadsheet にある正誤表から textlint で使う辞書ファイルの生成を自動化したりしました。

2024年の抱負

現在10時半前。 実装したい。

無知と怖いもの知らず

無知(むち)は、知識のないこと。または知恵のないこと。

無知 - Wikipedia

Bing Image Creator 便利ですね

背景

最近データベース設計について MySQL の公式ドキュメントを読みながら勉強しています。

分析系のインスタントな SQL は業務の中でずっと書いているので、人並に書けるだろうと思ってます。

ですが、ウェブアプリケーションから発行される SQL は、インデックスの設計などパフォーマンスを意識して考える必要があるとわかりました。

勉強を通して、なにもわからんという状況から、インデックスを完全に理解したという状況まで進めたと思っています。

何がおこったか

これまで負荷の高い SQL を本番環境で実行してしまっていました。無知って怖いですね。

まあ、パフォーマンスが悪いといっても、所詮 SELECT なんでロックをかけるようなことはなかったと思いますけど。。

まとめ

無知は罪というような主張もわかるし、常に知識を得るように努力しているつもりでもあります。

ただ、知識を得ることで慎重になりすぎてしまうということはもったいないことだとも思ってしまいます。

まとめとしては失敗を怖れずに、今できる最善をつくせるようにしないといけませんね。

テーブルをまとめることは悪いことですか?

悪いことだと思ってました。

まずはテーブルの分割について整理します

とりあえず、テーブル分割について2つの議論を整理しあす。

正規化

テーブル分割といえば正規化です。一言で言うとデータの重複を排除してデータの不整合を起こりづらくすることができます。

正規化こそ DB 設計の正義。インデクスさえ正しく設定できれば大勝利。正規化バンザイですね。

正規化はパフォーマンスとのトレードオフと位置付けられることが多いですが、適切にインデックスを張っていればだいたい回避できるらしいです。知らですが。

垂直分割

良くないです。テーブルの列で区切って、ID で join できるようにします。Web アプリケーションだと機能追加で発生しがちです。

テーブルを分割することでメモリに乗るデータを減らすことで高速化ができるというメリットもあるようだが、インデクスでを使うべきとのこと。

テーブルの垂直分割は悪なようです。後々困ります(私見)。

まとめ

  • 正規化であればインデクスで頑張りましょう
  • 垂直分割であればまとめてしまいましょう

参考文献 - 達人に学ぶDB設計 徹底指南書 初級者で終わりたくないあなたへ - 失敗から学ぶ RDB の正しい歩き方_

「やった方がいい」か迷うことはたいていやらない方がいい

「やらないよりはやった方がいい」「将来必要になるからやった方がいい」と迷ったとき、たいていやらない方がいいと思うようにしている。

まあ、気持ちはわからないでもないし、自分もかつて(今でも)そう考えることはある。

雑に書いてしまうと、こういった考えをするときは「思考停止してしまっていて考えるより動いた方が楽」もしくは「やらないことによって発生するリスクを大きく見積っている」のどちらかだ。

「思考停止してしまっていて考えるより動いた方が楽」については、まあそうだよねという感じでケースバイケースな気はする。 考えすぎて身動きできなくなるのもよくないので、「やる」場合どれくらいの手間がかかるか見積ってからやるようにしている。

「やらないことによって発生するリスクを大きく見積っている」については、将来「発生するリスク」というのは大抵大き目に見積ってしまうことが多い。 結局のところ上でいっていることと同じようになるのだが、問題が発生する可能性と発生した場合のインパクトを数値化してかけ算するなりして見積ってみるのが有効だと思う。

最後に、自分の経験によるのだが、「やった方がいい」と思ってことをやらなかったからといって大きな問題になったといことはない。 これは「やらざるをえない」状況になって着手したのか、単に「大きな問題」を忘れてしまったかのどちらかだと思うのだが。

失敗したとしても挑戦をほめる文化のありがたさ

「ああ、やっちまったな」というとき、「挑戦したことはほめられるべきだ」というようなフォローをもらってはっとした、という話。

人はだれしも失敗してしまうことはある。ただし、だれも失敗したいと思って失敗しているわけではない。

また、大抵の場合、新しいことに挑戦して上手くいかずに失敗してしまうのだと思っている(ときには繰り返し作業のなかでのケアレスミスということもあるが)。

そういったときに、当事者は自分を責めてしまって、「注意が足りなかった」「もっと計画していれば」「自分はなんて愚かなんだ」といった考えになってしまう。

もちろん、そのように反省することにも意味があるとは思う。が、原因を自分の内側にだけ求めることは、なぜ失敗したかを考えるための視野を狭くしてしまう。

原因は自分の中だけではなく、それをとりまく構造やシステムにもあることが多い。構造やシステムを改善することで人が失敗できないようにする考え方もある(フールプルーフ)。

そのため、失敗についてふりかえるとき、自分の内側と外側とに広い視野をもって問題がどこにあるのかを探すことが必要である。

そういったときに、自分にとって冒頭にあげた言葉はとても助けになったし、そういう文化のなかに身をおけることがありがたいと思った。

はじめに文章を書きましょうという提案

はじめに文章を書きましょう。

何かをする前に、まず文章を書いたらどうかという提案です。

「何か」とは何でしょうか。プログラミングや図解、概要文なんかもそうかもしれません。ポイントは、今考えていることをそのまま文章にしてみるということです。

プログラミング・図解・概要文は、書き出した文章を推敲すればいいです。まず、そのまま文章にしてみましょう。

そのまま文章にしてみて、曖昧な点や上手く文章にできないところがあったら、きちんと文章を書きましょう。大変ではありますが、そのあとのプログラミング・図解・概要文が書きやすくなります。

文章を書くのは面白いですね!

ふんわりはじめるユビキタス言語のつくりかた

ユビキタス言語をつくろうぜってなってやったことをまとめる。

継続的に 話す → 文章を書く → 図を描く → 話す → ... というサイクルを継続することが大事という結論に至った。

それぞれでどのようなことが大事なのかを雑に書いてみる。

話す

  • 肩肘はらずに話しやすい雰囲気が大事
  • 会話のなかにあらわれる助詞、接続語、比喩表現に気を配る
  • 少しでもわからなかったら質問する
  • ミーティングやチャットのやりとりから言葉を収集する
  • 言葉の関係性を意識する

書く

  • 主語を省略しない
  • 関係者に伝わる程度のレベルで抽象化した表現にする
  • 一文一義のようにシンプルな文章を心がける
  • 箇条書きや表も使用する

描く

  • 一通り文章を書いてから図に起こす(いきなり図を書かない)
  • 文章だけだと解釈に幅ができるのでそれを縮めるための図を描く
  • 図の内容と「書く」の内容が乖離していたら文章を追加する
  • 文章と図をみて会話する(「話す」に戻る)

まとめ

ふんわり大事だと思ったことをまとめた。