株式会社SENRIの杉山です。

2015年からプロダクト開発をしており、いわゆるチケット管理もGitHub上で行なっているので、開発が進めば進むほどGitHub上の # が増えていくんですが、ついに先日 #10000 を迎えました 🎉 めでたい！

いい機会なので #1 から振り返ってみます〜

#1 モデルの再構成 (2015 July)

GitHub上では2015年7月の1つ目のissueがこちらでした。これはもともとあってプロトタイプで試してもらってたんですが、いよいよ本格化（プロダクト化）するか！というタイミングのissueでした。個社向けに作ったやつだったので、Companyという概念すらなくて、ログインすると全員同じ画面に入るのでまずはCompanyを差し込んでそこに色々つけるってことだな〜ってなったのを覚えています。1ヶ月後にはすでにこの右の図の通りにはならず結構色々ぐちゃったのを覚えています。（あと、これはのちにわかる怖い話なんですが、Returnモデルがあるんですよね〜〜〜！！）

#100 Dashboard画面の追加修正 (2015 Sep)

2015年9月時点で、すでに100にタッチしていました。結構いいペースですね。多分これは、ログイン後にリダイレクトされる画面をDashboardと呼んでいて、そこでのデータをどれぐらいの期間で出すか、とかそういうやつですね。記憶が正しければ、この頃はherokuの上で動いていた気がします。

#201 [機能追加] Dashboard画面にSub Inventory画面の追加 (2015 Nov)

めっちゃ荒削り〜〜〜！！でも好き〜〜〜！！懐かしい〜〜〜！！
2015年11月時点で在庫管理に手を出してました・・・。サクッといけるっしょ！みたいな感じで思ってたけど、奥が深い在庫管理。どこまでいじれていいのか、一人の営業さんは何個この在庫の塊のようなもの（Sub Inventory）を持っていいのか。棚卸はするのか。何によって引かれるのか。履歴情報は。などなど無限に出てくるし、ここの数値変動をここと連動させたいよ、とかトラックとかに乗せてるこの在庫を持ってって配達したら配達した先の在庫が増えて欲しいよ、Delivery Management Systemと化すにはどうすれば、配達するもののバッチ番号はどう反映させれば？など7年経った今でもやれることは山積みです。

#501 CSV関係の実装を controllers/concerns から、models に移動 (2016 Mar)

これは、個社対応で作ってたCSV Export機能が、Controllerの中で

def export
    data = Hoge.where(company_id: params[:company_id]).all
    CSV.generate('', headers: header, write_headers: true ) do |csv|
      data.each do |content|
        csv << [
          company.id,
          company.name,
          company.hoge.id,
          company.hoge.name,
        ]
      end
    end  
    send_data(data, filename: "hoge.csv", type: 'text/csv')    
end

みたいにゴリゴリ controller 側に組み込まれてたやつを Concernsに移したけど、違うな、となってmodels配下にCSVの生成周りを担うファイルを作ったよってPRでした。
始まってから9ヶ月ぐらいで500番か〜という感じ。確かこの頃に、入ってくれた達人によって弊社にテスト文化がもたらされたような・・・（現在では、カバレッジ85%ぐらいです。本当にありがとうございます🙇‍♂️）

#1000 Payment statusのコールバックについてのテスト （2016 Oct）

テスト駆動とはいかないものの、ちゃんと工数割いてテストやろうね、というのが根付いていたのか、テスト書くだけのissueが立っててえらい（PR出す前にやれや、というのはごもっともなんですが・・・）
そして、このissueまでの振り返りをみる限りではこの時点で、SENRIは

- 各Productのいくらでいくつ売るみたいな取引ができて
- その配送管理（少なくとも状態の管理）をしていて
- （上記のSub-inventory）個人レベルで持つ在庫の管理ができる

というとこまで来てたっぽいですね〜。もはや今のSENRIの原型は完全にできてるっぽい（機能の磨き込みはともかく）

#2000 VisitQuestionが登録上限に達すると編集と削除もできなくなる (2017 Nov)

前回から1年1ヶ月ぐらいで +1000番されてますね。そして、これはbugラベルが付けられてるんですが、境界値あたりのバグっぽいタイトル〜〜〜！！普通にありそう。

このVisitQuestionというのは、SENRIを持った営業さんがお客さんのところにいってオーダー（注文）を取るなりDeliveryするなりをするんですが、それと同時にそこで営業レポート書いてね、という機能があります（Visit Reportと呼ばれている）。で、その時の質問項目はその会社のManagerが自由に設定ができるけど、999問とか作られると困っちゃうので上限つけとこうね、というのが今回のissueのバグの発端ですね。

このVisit Reportは元々2問ぐらいの固定質問だったんですが、2017年冬あたりを皮切りに、質問項目の個数を自由にできたり、質問項目のグループを作れるようにして、（新規営業なのかルート営業なのかで営業レポート内容が違うので）顧客によってどのグループを答えるかを決められるようにしたり、Question 3でAと答えた人はQuestion 5に、BとQuestion 8に進んでね、みたいな回答によってルートを変えたり・・・とかなり多機能になっていきます。

#3000 DealのCSVダウンロードでサーバーが死に得るので修正 (2018 Aug)

これは取引データを1年ちょっととかの長期間でCSV出力しようとした時に、割と大量データになるんですが、そこまで考慮して無く、シンプルに each 文で回していたら死んだので、 find_each にしましょう、というやつですね。なんだかここら辺の時期は、3年ぐらい運用されてきたこともあって、年単位でのデータのダウンロードとかって、CSV出力周りに無茶があったりして、なんでもincludesして楽するのをやめてインメモリ上での展開されるものを意識的に減らしたり、そもそもめちゃくちゃリファクタリングしたりしてた覚えがあります。

#5000 Improve/#4997 improve vr export speed sugi511 (2020 Jun)

ぐわ〜〜！！2年前にやってたCSV exportの高速化系だった・・・。ここら辺で、うちのデータ構造の癖に合わせたCSV exportの高速化のお決まりパターンみたいなのがしっかり決まった感じがしますね。

これはVR = Visit Report（訪問レポート）のCSV出力なんですが、誰がどのお客さんにいつ訪問して、それがどうだったか、の誰とかどのお客さんとかそれぞれのメタデータっぽいもの（name以外のデータ）もそこそこ出しておかないと、出てきたCSVをベースに分析できない、みたいなのもあって、読み込むデータがベースのVisit Reportからリレーションでいうと3つぐらい先のものまで参照しに行く、みたいな感じだったので愚直にテーブルをjoinしてると死ぬ、というお手本みたいなやつだった気がします。

で、issue # が 3000 -> 5000 でだいたい2年弱という感じなので、だいたい1000強/yearぐらいで進んでいるっぽいのがわかりますね〜。

#7000 [Fix]question-signをinfo-signに変更 （2021 July）

これは・・・時代を感じますね笑
昨年、2021年夏頃に今までポリシーなくそれとなく他に合わせて画面を作っていたところ（ごめんなさい🙇‍♂️）から、きちんとデザインシステムを作って全体をそれに沿って実装していきましょう、というプロジェクトが走ってました。で、その時の一コマって感じですね〜。そして、これは昨年入ってくれた未経験エンジニアがフロントエンド側でバリバリ活躍してくれてたやつです。

そして、約1年で #2000 ぐらい進むようになっている・・・！？おれたちは加速しているのか・・・！？

#9000 [Remove]newsページの注意書きを削除 (2022 Mar)

さらに #2000 進むのに、1年の月日は必要なかったようですね。マジか。加速しすぎでは。

これは、ManagerさんがAndroid app持ってる営業さんみんなに何かのお知らせを配信できるシステムを開発した関連のやつですね。例えば、「商品のプライス変わったからチェックしてね〜」とか「直行するときは9時までにSENRIでチェックインよろしく！」などみんなに表示するやつですね（杉山フィルターが入って優しい表現になってると思います）。

このNewsの機能も、リリース時には全員に同じものを配信する、で良かったけど、そのうち「複数個配信したい」「8月のお知らせは9月になったら勝手に消えて欲しい」「営業グループAには配信したいけどBには配信しなくても良い」など、まぁその要望はあるよね〜というのが早めにフィードバックとして返ってきて、使ってもらうのも早くなるとフィードバックも早くなるよね、という良い機能でした。

#10000 Weekly Activitiesの物理テーブル化 (2022 Aug)

記念すべき #10000 はまたもや高速化案件でした〜🎉

これまた結構な大量データを扱う系だったんですが、WeeklyとかMonthlyだと超リアルタイムじゃなくても良いよね、ということで計算ロジックはそのままにページアクセスごとに計算するんじゃなくて、事前計算しておいてそこから持ってくるか、という形にした issue でした。先週の話なので記憶が新しすぎる。

振り返ってみて

#9900 ぐらいからドキドキしながらissueを作ったりPRしたりしながら、「もう今週いっちゃうんじゃない？」とか言いながら、 #10000 を迎えたのが先週だったんですが、2015年7月に #1 だったことを考えるとおおよそ7年で #10000 を迎えました。正直、これが早いのか遅いのか全くわからないんですが、2020年までの5年はフルタイムサーバーサイドエンジニアは2人がMaxみたいな感じで、2022年現在もフルタイムサーバーサイドエンジニアは3人なので、やっぱチームとしては割と小さいのかな、という感じがしています（パートタイムとか副業の方とかもいるのでもうちょい工数としてはあるんですが）。

ちょうど良い機会だったのでURL欄にissue番号を打ち込んでは懐かしむ、みたいなことをやってた結果がこの記事なんですが、昔は大きな機能の概念自体、例えば雑な在庫管理〜！！みたいな感じのを作ることが多かったのかな、と今になって思っているのですが、最近はもうちょっと微に入り細を穿つというか痒いところに手が届くというか大きくもあるが細かくもある機能の開発みたいなのが多くなってきた印象があります。結果として、仕様を詰めていく時にも「表面的には機能としてはワークするけど、この実装で欲しい価値まで到達するのか？」「これだとちょっと人の手が介在するけど使ってもらえる？」「人間の脳みその限界超えてない？コンピューターにさせた方が良い？でもどうやって？」みたいなのが多くなってきているような気がしてすごく楽しいです。

ソフトウェアエンジニアとしては、ソフトウェアを作って、それが何かのきっかけでCPUをぶん回して、それがファイルを生み出したり、何かの数値を叩き出したり、Push通知を送ったり、何か人の行動を変容させて生まれる価値、をどれぐらい作れるか、その生まれた価値でどれぐらいの人が幸せになったのか、みたいなことを考えるんですが、コードを書く、キーをタイプするここからは価値が生まれている現場はなかなか見えないけど、なんだかんだで7年もやっていてたくさんの人に使ってもらえている、もっとこうして欲しいよと声が上がる、という現状を考えるとまだまだ満点からは遠いかもしれないけど、落第ではないのかな、という気持ちになっています。

最後に - We're hiring的なやつ

直近の #1000 を考えると、5ヶ月で #1000 なんですが、issue/PRがペアだと思うと、実態としては500個ぐらいのissueを5ヶ月で捌いているので、だいたい 100 issues /月 ぐらいっぽいんですが、issue の消化速度は上がっているし、結構やって楽しいし、自分の手とか目が届かないところに価値を届けられる、というソフトウェアエンジニアっぽい仕事だし、多分アフリカとか東南アジアとかで知らないこともたくさんあるし、Railsエンジニア（経験者）ならガンガン活躍できるissueも日々生み出されているし、その一方で（技術的というよりもビジネスサイドの方が）難しいが一緒に考えて紐解くのが楽しいissueもあるし、Railsもアップデートしたい（もうすぐ6へアップデート完了します・・・！！）し、データの見せ方の工夫ももっとやっていかないといけないし、やりたいことたくさんありすぎるので、ぜひ僕らと一緒に6億人（現在展開国人口合計がたぶんこれぐらい）の生活を支えるSaaSの開発を一緒にやりませんか？結構困ってます！お願いします！！お願いします！！（2回目）

「画面とか見せてくれないと、どんなProduct作ってるかわかんねーよ！」「結局、事業内容分からないんですけど・・・」ですよね！わかります。ポチッと「話を聞きに行きたい」とかボタン押してもらうか Twitter でDMもらうか、固定ツイのMeetyに連絡もらうかなにかいただけますと、その疑問解消しにいきますので、何卒お願いいたします🙇‍♂️🙇‍♂️