＜エムスリー Advent Calendar 2020 まで残り3日となりました。Advent Calendar本編に先んじて新卒1〜2年目メンバーが執筆します。＞
こんにちは，エムスリーエンジニアリングGの榎田です．新卒2年目です．普段このブログには業務とあまり関係しないことばかり書いているので，今日は業務の話を書きます．
普段は Docpedia というサービスの開発をするアプリケーションエンジニアと，チームプロダクトの本番デプロイ作業やインフラ作業などをするSREエンジニアの両方をやっています．フロントとインフラでいうとインフラのほうが向いているような気がしています．これまでのところ，仕様を考えるよりもコードを書くほうが向いているようです．また，Docpedia はプロダクトマネジャー（PdM），デザイナー，私含むエンジニアからなる数人がチームとなって開発を担当しています．
今回の話は，そんな私が，普段開発している Docpedia のある機能の仕様書を書いた話です．
なぜ仕様書を書いたのか
餅は餅屋．せっかくプロダクトの方向性を決める本職の人がいるのだから，仕様決めの主導は基本的に PdM さんがやったほうがいいのでは？ そう思う人もいると思います．
かくいう私がそうです．最初に述べたように，私は仕様を考えたり，新しい機能のアイデアを出すのが特に苦手だと思っています．もう少し理由を細かく書くと以下のとおりです．
- UI にかなり無頓着．他の人が「えぇ…」となるような UI でも「そういうもんだろう」と気にせず使ってしまう*1
- 機能レベルでも「こんな機能があると良さそうだな…」というのを考えるのが苦手
- 仕様を考えていると「ああいう場合のエラーはどう処理しよう」と，プロダクトの未来ではなくて技術的委細のほうを気にし始めてしまう
- フロントよりはインフラのほうが得意な気がする．普段の仕事の半分は SRE 的なものだし…JavaScript は少し苦手だし…
というわけで，チーム内でも「その仕様は後々つらいと思いますよ」みたいなことは言いますが，「こうしたほうが使いやすくなると思います，ユーザーフレンドリーだと思います」という発言はあまりしません．普段からかなり外れ値なユーザーとして振る舞っている自覚があるからです．
そんな私が書いた仕様書は何かというと，「Docpedia のメルマガの配信内容を編集・登録する管理画面」の仕様書です．これは Docpedia としては新機能ではあります．しかし，上に述べたようなタイプの新機能ではないな，と思いました．というのも，
- 利用者が社内で閉じるので，実際に「この UI でどうですか？」とおたずねして調整するのが容易
- できないとマズいこと，できればやりたいことが割合明確で，そこから実装がある程度逆算できる*2
- 一方，社内にある既存の機能をそのまま流用するのは技術的には避けたい*3など，エンジニアでないと見えない考慮点が多々ある
- インフラの考慮点が多い．フロントは書いたとおり使う人に感触を聞けばよさそう
そんなわけで，これは多分私が仕様書まで書いてレビューしてもらうほうがいいだろうと思い，実際に書いて PdM さんや他エンジニアさんにレビューしてもらって実装に入りました．
このブログを書いている現在，絶賛実装中です．
書いた感想・よかったこと・向いてなさそうなこと
書いた感想
久々に手書きで文字を書いたので手が疲れました．また，今回は UI/UX は後々すり合わせる前提だったので，機能の流れがわかればよいだろうと考えて手書きで書きましたが，修正が頻発しそうな機能を手書きで書くのはやめたほうが良さそうです．ワイヤーを組むソフトの存在意義を理解しました．ただ，以下に挙げるように良かったポイントもたくさんあったと思うので，総じて書いてよかったです．
よかったこと
利用者・エンジニアとの調整を密に行いつつ仕様を決められた
これは今回の機能の特性ゆえでもありますが，実際にどのような仕様が一番よいのかを「利用者の都合」「実装の都合」の両面からすり合わせやすかったと感じます．実際，今回の登録画面での登録方法も，エンジニアと議論する中では「メルマガに送りたい質問のIDを入力する」「内容を書いたCSVをアップロードする」などの選択肢が挙がりました．それを踏まえてメルマガ編集部との意見合わせを行い CSV アップロードをすることにしました．
見積もりに自信が持てた
何ができるか，必要なら社内の既存システムを調べてエンジニア主導で仕様などを組むので，不確実性が低い状態で進められると感じました．私が普段インフラ作業をしていたり，メール配信システムを触ったことがあった*4というのもあって，「ここの通信経路開けないと困る」などの懸念も事前に洗えたと思います．
向いてなさそうなこと
自由度の高い話
このアプローチは「実装するとしたら可能性はこれとこれなので，ありえる仕様のパターンはこんな感じ」というふうに，できるとわかっていることベースで進めていくので，実装や仕様の可能性がたくさんある状態で探索的に話を組み上げるのは苦手です．もちろんそういうことを「私が」「このやり方でやるのは」不得手ですが，Docpedia はチーム開発なので，得意な他の人に補ってもらいながら進められたらありがたいと思っていますし，ここに書いていない他の施策などではばりばり仕様の大枠を用意してもらっています．
We are hiring!
私はエンジニアとして会社づとめをはじめて2年目なので，まだまだできないこともたくさんあります．そんな中で自分のできそうなことを見つけて仕事を進めた話を書きました．仕事は一人でやるものではなく，それぞれ違う個々人が自分のできることや強みを発揮して協力していくのがいいと思っています．自分にとっての強みがなにかあって，それがこの会社で少しでも活かせそうだと思ったらぜひお話に来てください．
また Docpedia チーム，およびチーム内で使われている技術スタックにご興味がある方はこちらも御覧ください．
*1:「新卒入社して数ヶ月ほど，無改造 Emacs 以外のエディタを使っていなかった」といえばエンジニアの方々には無頓着具合が伝わると思います．いまは主に IntelliJ です．
*2:できないとマズいことは，例えば今回でいうと，メール配信システムとの接合ができないといけない，とか，タイトルとメルマガの内容を出さないといけない，とか．できればやりたいことの例としては診療科ごとの出し分けとか，パーソナライズとかでしょう．
*3:既存機能は，例えばメルマガの内容をオンプレの RDB 上に書き込み，メール配信システムが直接その DB を参照して密結合化している部分があります．今回の記事では詳細は述べませんが， Docpedia ではメルマガの配信内容を返す API を新規設置し，配信システム側からはその API を叩く設計にすることで結合を疎にしたり，その API の返り値だけは（他のエンドポイントは RDS から値を引く中で）s3 にあげた csv ファイルを読ませたり（Docpedia は clean architecture に則って実装されているので，これが楽にできました）など，技術的にいろいろ改善・挑戦をしています．
*4:Docpedia 以外のメルマガについて配信日などの設定を変更してほしいという依頼が来たり，障害時に調査に入ったりしていました．雑用っぽくみえて面白くなさそう，他のことに時間を使ったほうが良さそうと思う人もいると思います（…また，障害調査は実際つらいです）．しかし，この手の「雑用」を通してシステムの動き方に対する勘所を養えていたからこそ，今回の設計を進められたと個人的には思っています．
