All Articles

1 year has passed

転職してから1年が経ったので振り返りと抱負を書いておく。
2020-11-05 に書いていたが、書ききれなかったので太字で追記している(2020/12/30)

転職してからの1年間

(時系列順ではない)

初期は、開発者として機能開発をやっていたが、1, 2ヶ月後くらいにスクラムマスターが必要となったのでやることにした。なぜやったかというと、やったことがないし、なれる機会がそうそうないんじゃないかと思ったから。やってみてダメだったら変わればいい。16 personalities の結果からは計画性タイプの人間なので性にはあっていると思う。playing manager に憧れもあったというのはほんの少し理由に入る。

スクラムマスターの難しいところは、いかにスクラムの流れに乗せられるかというところにあると思う。特に自分たちのようなスタートアップで顧客対応があったりすると、予想以上に作業時間が開発ではないものに割かれる。そしてそのコンテキストスイッチによるオーバーヘッドもある。これのせいでずるずるタスクが伸びると悲惨なので、スプリント期間を 2 週間から 1 週間にし、なるべく開発に割ける時間を明示的に言ってもらい、コミット頑張ろうというようにした。

また、開発タスクが中々流れないということにも悩んだ。これは、基本的に一日でやるタスクを開発レーンにおいてコミットしようねという約束で様子を見ている。何か邪魔するものがあるのなら排除するのが僕の仕事だけれど、それが家庭の事情だったりするともうつっこみきれない。
これは、今現在相対見積もりになっている。理由としては、コミットメントに重きを置きすぎて、メンバが燃え尽きてしまったり、体調を崩さないようにするため。スクラム関連の本読む限りは相対見積もりを推奨しているし、スクラムがまだ浸透しきっていないときにやるべきではないから。 また、相対見積もりを頑張ることで、チームでタスクの持ち回りがしやすくなった。個々人の見積もりだとタスクの透明性やスコープに共通認識が持ちきれないため、チームとしてタスクがあるものの、完成度は個々人によっていたため。今後は相対見積もりで消化できるポイントをベロシティとして記録しつつ、なるべく平準化されるようにスクラムを回していく。

ある月にいきなりコミットメント時期が来ているという通達があり、開発を急がないといけないこともあった。これはもう二度としたくないので、リリース日などは必ず自分から追っかけるようにする。余裕がないと、正直テスト書いている暇なくて動くものを結合で使ってもらうようになり、コードベースが荒れる。レビューしているのも時間がもったいないくらいだったので、ざっと見てマージするがバグが出る。そのバグ修正が割り込みとなって次の機能リリースが延びる。次のリリースがずらせない場合は更に地獄だ。バギーなものが量産されて、プロダクトが安定しなくなる。テストが終わらずにリリースができなくなる。そして新しい価値を提供できなくなるので客は離れる。いいことがない。

SRE と名乗っていきたいので、SRE本の輪読を始めた。自分が一通り読んでこうするのはどうかと発表するでもよかったが、チームとしてどうしていくかなので目線合わせが大事だなと思ったので、輪読にした。これは意外とうまくまわっていて、新しい取り組みが始まったり、こうあるべきだよねという発見がいくつもある。週に1度の開催で本自体が 80p くらい進んでいる。全員で読む納得感を共有できるのが思った以上に心にゆとりをもたせている。これを読み終えて次はSRE本 2 にいきたい。 (現在プロダクトリリースに追われてできていない。落ち着いたら再開する。そもそも追われてるこの状況がよくないのだが。。)

プログラマーとしてやったこと(以下2020/12/30追記)

  • エラー時に api コールを一意に判別したかったので、RequestID をロガーに持たせるようにした

  • 認可機能実装

    • migrate の仕組みも用意

  • セキュリティ周りの対応

    • kong いじったり、aws の設定いじったり
  • データ定義の整理( github で管理できるようにした)
  • elasticsearch 周り整理
  • あとは機能の設計とかレビューなど
  • postman e2e 構築

その他

  • 採用基準の洗い出し。must や want の整理
  • コーディングテスト作成
  • 技術面接
  • 業務委託の方にお仕事お願い、コミュニケーション

今後1年の抱負

より安定して、早くプロダクトをリリースしていくために以下に取り組む

  • 仕様を詳細に詰めて、業務委託の方にどんどんモノをしあげてもらう

  • プロダクトバックログの質を上げて、バグやレビューによる手戻りを減らす

    • 自分がちゃんと書いて成果を出して、他でもちゃんと書くようにさせる

  • 開発者が増えても問題ないように、テストの土台作りを強化していく

    • これは e2e やユニットテストで守っていく
  • リリース前のスモークテストは自分ができるように仕様は把握しておく
  • SRE として、安定・セキュリティなどにこだわっていく

  • チームメンバにどんどん機能を仕上げていってもらう

    • 雑用は自分が拾うでもよいかもしれない
  • 開発チームの中で一番安定していて、作るのが早いと言われるようになり、他のチームの見本になりたい

スクラムを完全にうまく回せるようにして、技術調査や新規プロダクトの開発など、技術に向き合う仕事にシフトする。

(ここらへんは現在と考えが変わっていない。強いて言うなら、技術と向き合うために残業をしないということを追加したい)

Published 5 Nov 2020

Software engineer at Tokyo. smith-30 on Twitter