この記事は裏freee Developers Advent Calender 2018の24日目です。

こんにちは！かつてfreeeに在籍しニャンちゅうと呼ばれていた者です。

最近ではトシと呼ばれています。自分の寿憲（としのり）という名前がとても好きなのと、ニャンちゅうと呼ばれることでキャラ付けに下駄を履かせていただいていた過去の自分を乗り越え、純粋にエンジニアとして闘争したいという思いからニャンちゅうはアイコンにとどめることにしました。

エンジニアとして成長したい方向性と今のロール

自分がエンジニアとしてどう成長したいかを表現する局面でかつてこんな風に書いていました。

技術寄りでサービスを考え、作り、変え、大きくしていくことができるエンジニア（になる）

時期によって担当するプロダクトの方向性を考えるPdM的な役割も担いサービスを考えることもありました。しかし、ここ1年くらいはそういうことは少なく、上記の「作り、変え」にあたりインフラも含めてどう設計するとよいかを考えることが多いです。

9月からはメルペイという会社で信用を創造して、なめらかな社会を造るべくその足がかりとしての決済システムを開発しています。

メルペイではマイクロサービスを開発するチームの1つでテックリードをしています。きっと組織によって「テックリード」の位置付けは異なると思いますし、少なくともfreeeにかつていた（？）テックリードとは異なります。

メルペイのテックリードの役割はこの記事で触れられているとおりこんな感じです。

エンジニアたちにとって開発の妨げになっているものを取り除くほか、全体設計や技術にある課題を解決する。

エンジニアと立ち話。Vol.19 @foghost（メルペイBackend）ちょっとお話いいですか？

メルペイに転職したのは自分が技術で解決したいと思うものが会社の方向性と合致しているからです。そこでどう貢献するか形は色々とある中、テックリードとして技術課題に立ち向かうのは自分がエンジニアとして成長する上でもとても重要なことだと捉えています。

とはいえ、ロール以前にGoやGCP、最初から全体的にマイクロサービスなどそもそも技術的に初めてしっかりと触れることが多く、想像以上に難しい・わからんと感じる局面が多いです。

全方位的に完璧を目指すのは現実的でない雰囲気な中、何を解決すればメルペイ（特に自分が担当するマイクロサービス）をリリースでき、安定して運用をできるのかを考えそのときそのとき一番大事っぽいことに集中して取り組む必要があります。

来年よりいい感じでチーム開発を進めるために、注意し続けたいことや改善したいことをまとめます。

設計

方針的な実装と詳細な実装、アーキテクチャを暫定的にでも決定しないと実装できないところとそうでないところをきちんと分けないと進みません。

マイクロサービスに対し、入社前はそのマイクロサービスのドメインをきっちり深め運用までしっかりしていく必要がある一方であまり他のサービスのことを知らなくてもよいというイメージがありました。

そのイメージの正誤はおいておいて、他のサービスの設計にどうしても依存せざるを得ないケースがあります。さらに複数のサービスが関係することもあり、設計・仕様の調整を待っていては進まんみたいな状況もありえます。

ただ、本当にそれが決まり切らないと全ての作業が無駄になるということもないので、影響を受ける部分とそうでない部分の境界を見極める、影響を受ける部分を分離するということが大事そうです。

仕様を決める時点で複数のサービスが拘るならその部分はその後も他のサービスの影響を受けるかもしれませんし、自サービスの都合で自由に変更し辛いかもしれません。

このあたりの設計を考える上では今年Clean Architecture 達人に学ぶソフトウェアの構造と設計に最も影響を受けました。

本にも出てくる「できる限り決定を遅延できる設計」というのは自由にコントロールできない部分がありかつ不確実なものに立ち向かう上では肝に銘じたい言葉です。

一方で、今の技術スタックに十分に馴染みのないまま考えて実装の現実味がない部分もあったので実装力にある程度裏付けされた設計ができないと辛いです。

個人開発でコード書けば済む部分もあれば、ある程度大きめのコードベース・複雑な前提で試さないと現実味がいつまで経ってもわかない部分もあります。なので、調整系のタスクの優先度が高いにしても自分で実装するのも必ず残すよう心がけます。

意思決定

「こういう設計で行こう！」と決めないと進まないという思いと、詳細な実装を進める上で困るようであれば自由に変えてよいのではという思いは同居しています。

しかしそのふわっとした感じだと、メンバーに決まってるのか決まってないのかようわからん、とモヤモヤが生じることもあります。

やり方まで押し付けるのは嫌な一方でどこかのタイミングで結論（それが未来永劫変わらないというものではない）を出さないといけないし、そうせざるをいけないといけないこともあります。

その上でやるべきことは

• そう決定した根拠を整理し、 腹落ち感があるまで 説明したり議論したりする
• 根拠はその仕様を決めないといけない背景・コンテキスト、仕様面、技術的制約、社内外問わないコミュニティの動向、社内的な議論を構成要素とする
• 腹落ち感がありそうかなさそうかリアクションを見てわかる程度の関係を構築する

だと感じていて、全てが技術そのものに閉じるわけではなさそうです。

あと決定するにあたっては、自分のサービス的にはとても重要だけども他のサービスにとってはの優先度は異なるケースで、適切に「こういう仕様でないと困りそう」だったり、「こういう仕様をそっちのサービスで検討してないと困ると思うよ」だったり議論をリードしたり検討を促すことも大事そうです。

AはBがやると思っていて、BはAがやると思っていた、など認識の齟齬や浮いてしまっていた仕様にも気づけます。

プロジェクトマネジメント

不確定な要素が多いが期限があるものにどう向き合うべきか？これはこれまでエンジニアが向き合ってきたものの中でも最も手強い課題の1つではないでしょうか。

細かい工夫はいろいろとできるとは思うのですが、とにかくチームが意識して追うべきものと前提が揃ってないときつそうです。

と言いつつこれがまだまだできてなさそう。

アジャイルな感じでJIRAでチケット管理しているのですが、もうちょっといい感じにしたいのはこの辺りです。

• バーンダウンチャートの残StoryPointが0になる = リリースできてる状態
  • リリースまでに必要なタスクが全てチケットになっている
  • 必要な作業が出てきたら足して見積もる
  • 遅れてると足すことが悪いように自分でも感じてしまうけど必要なものは必要
  • ただそれが過剰でないかは議論の余地があるのでまずはチケットにする
  • 各チケットの粒度が多少違ってもレビューを含む・含まないは最低限揃っている
• バーンダウンチャートではバージョンのフィルターをかけて増減を追う
• 「各Sprintにはバージョンに直接貢献しないがやるべき作業（研修や同僚の評価など）がある」のでStoryPointを入れてチケットにする
  • バージョン以外の作業も含むチームのベロシティはスプリントあたりどれだけStoryPointを消化できるかがわかり、次Sprintに積むチケットの量を考える基準になる
• 厳密にはやらないもののSprintのプランニングで積むチケットはやりきるというコミットでやりきるべき、逆に差し込まれたタスクはやらなくていい or その場で判断しなくていい、差し込まれないように 誰か が守るべき
  • そのために自分はPRレビューを最優先する（Todo -> InReview -> Doneのブロッカーを作らない）
  • Sprint内やまたいで滞留しているチケットに対してアクションをとる
  • 自分が実装タスク持つとほぼその週で終わらん…！
• StoryPointで各チケットに工数を入れ、便宜的に2StoryPoint = 1人日としているが関心事はあくまでも
  • 1SprintでこなせるStoryPointを最大化すること
  • 1Sprintの平均ベロシティからプランニング時に積めるチケットの妥当なStoryPoint合計を見ること
  • n人いるので2 * 5（営業日） * n = 10n StoryPointには必ずしもならない（なることもある）
  • 相対値であり、大きければ大きいほど不正確・作業内容の変更リスクが大きいのでプライニング時に毎回見直す

前職でアジャイルな見積りと計画づくり ~価値あるソフトウェアを育てる概念と技法~を教えてもらって読んで1度サービスのリリース（直前）までチームリードしたことはあるものの、そのときの経験がまるっと活かせるものでもありませんでした。

ただ言えるのは、これそのものがなんとなく場当たり的にやるのでは身につかない専門性ある技術なのと、バーンダウンチャートのリリース予測がパッと見計算間違いではって思えるようなものでも的確に現実の問題を明らかにしていることです。

「自分が全ての問題を解決しきる」のが目的でも求められていることでもないので、厳しかったり答えが見つけられないなら助けを求め、その結果を全体に還元できるように尽力します。

なかなか痺れる毎日ですが日々闘争し、いいサービス出します。