読書メモ / Engineers in VOYAGE ― 事業をエンジニアリングする技術者たち

「Engineers in VOYAGE ― 事業をエンジニアリングする技術者たち」を読んだ。
Kindle でブックマークしたところをメモ書きとして残そう。

全体を通して

キャリアハックやウォンテッドリーなどに載っている社員インタビュー記事のまとめのような感じ。元々が社員インタビューとして始まったということだった。

同じ VOYAGE グループでも会社や事業によって、打ち手も文化も様々な事がうかがえる。
それぞれにあったやり方があるよね。無理に統一することないよね。うんうん。

管理画面には、いろいろな機能が継ぎ足し継ぎ足しされていて、文字どおり魔境になっていました。

初期は速度優先で管理画面は二の次に。動けばいいやで異常系の考慮がされていない。
そうこうしているうちにサービスが軌道にのってきたかと思ったら、問い合わせ対応やデータ管理と管理画面はコアなシステムだった！

っという自分の実体験と照らし合わせながら、うなずきが深かった。

特に、ある程度の人員規模になってくると、バグがあろうが使いづらかろうが「最適化されたオペレーション」が完成していたりするので、そこを維持するなり運用手順変更の計画を立てたりしながら進めるのは、単に開発するだけではない根気が必要である。

そして私は今、自社の管理画面改善を担当しているのだった。

「フルサイクル開発者」知らなかった言葉。Netflix のブログを翻訳した記事がこちらだそうです。 Netflixにおけるフルサイクル開発者―開発したものが運用する - VOYAGE GROUP techlog

ドキュメントは書けばメンテナンスをし続ける事になる。だから議論や経緯、仕様は issue へ。

メンテされなくなったドキュメントやコードコメントはむしろ誤解を生んで事態をややこしくすることもある。開発者が issue から経緯を追うのは習慣化しやすいように思った。

加えて、全員が同じぐらいの理解を万遍なく持つ事でメンバー入れ替わっても問題ないのかな。

一方コンシューマー向けサービスの場合は公開された仕様やドキュメントもあるわけで、このようなものは社内用にドキュメント書くなら、FAQで社内外から見れるようにしてしまう。というのも個人的にはアリかなと思う。

レガシーシステムとどう戦っていくか。15年物の「ECナビ」を「ビッグリライト」せずにこつこつと改善を積み重ねていく戦略を選んだお話。同じくECサービスのサービスリニューアルとシステムリニューアルを同時に行った経験があるがあれは大変だった。5年物でも大変だったので15年は...

同じ悩みを抱えた人が一定数いそうなのが第3章ではなかろうか。

SSG から小さく始めて、徐々に課題に立ち向かっていくお話。さらに詳しくは以下の記事も出ていました。

Web上に専用エディタを設けるのではなく Electron 製の専用エディタを開発する発想も面白かった

この「神ゲー攻略」の記事執筆専用のMarkdownエディタは、「神エディタ」と呼ばれています。神エディタを使うことで、ライターさんは、自分がMarkdownで書いている記事をわざわざアップロードしなくても見た目を確認できます。

外注システムから内製へ。力尽きたので割愛 😇

最終的には、ISO52184の性別表記の定義に従う形になりました。

サービス仕様を考える時に ISO にあたってる点が良い

APIを外部から叩いたときの挙動を規定するテストを、あえて実装とは別の言語で書くようにすることで、実装に入り込んだテストを書けないようにする

テストを切り出すことで第三者のテスト視点を入れるとかもできそう。

ななめ読みしたので割愛！