この記事は、freeeデータに関わる人たち Advent Calendar 2019の14日目の記事になります。
こんにちは、freeeのAnalyticsチームにいる笹尾です。
freeeに転職してもうすぐ1ヶ月が経ちます。
この記事では、前職とfreeeとの開発スタイルの違いについて感じたことを書きます。
主に、納品先の違いと開発を担当する人数の差によって生まれるものです
＜免責＞
ここでの話は私個人の主観に基づくものです。会社の意見ではありません。
また、私が開発しているのは外部向けではなく社内で利用する分析用のシステムです。
会社や開発環境の違い
前職（会社名出して良いの変わらないので、「前職」と書きます）
・分析コンサルをやっている会社で、私は開発を担当
・プログラムの納品先はお客様先
・会社が出来て5年くらい
・開発の担当者は、数年は自分1人。他は営業とか分析官とか
freee
・クラウド会計サービスをやっている会社で、私は(今は)開発を担当
・プログラムの納品先は自社
・会社が出来て8年くらい
・開発の担当者は、Analyticsチーム内に3人、会社全体で見ると数百人(？)
＊開発スタイルの差い影響するところを太字にしています。
納品先の違いについて
納品先が客先か自社かによって、
・開発スピード
・納品後の対応
に差があるように思います。
まず開発スピードについてですが、納品物が客先の場合は、完成を納品期日に間に合わせることがマストになります。どんな理由があっても、「納品物が間に合わなかった」という事実だけで、失敗になります。
そのため、早く納品に耐えうるプログラムを完成させることを優先して作業を行います。YAGNIマンセー。
（万が一、どうやっても間に合わないことが分かった場合は、「期日までに絶対必要な機能は何か」と「期日後に追加納品していくプラン」をお客様と相談します。。。これは他の手が尽きた時の最終手段です）
一方、納品物が自社の場合は、最初に決まった期日に間に合わなかった時の問題が小さいことが多いです。あくまで客先納品と比べればの話で、中には大問題な場合もありますが、比較的そのような案件の割合は少ないでしょう。関係者にいついつまで延びるということを伝えるだけで済む場合もあります。スケジュールが遅れている時の、胃の痛みもマシです。
オマケで、納品物の金額は開発にかかる人日に基づくため、早く開発できる方が客先への見積もりが安くなって案件を受注しやすくなります。
次に、納品後の対応についてです。
例えば納品物に問題が見つかった場合は、納品物を使うのが客先か自社かで対応にかかるコストが違います。いずれも関係者への謝罪から始まり、調査と修正を行うのですが、この作業の心理的コストの差は大きいです。
また、自社内なら「あー、すみません、修正したのでもう一度処理を流してもらえますか」で済むようなことが、客先だと様々なやりとりや確認が発生します。問題が発生した時の対応は、自社の方がまだ楽です。
一方で、客先納品の方が楽なこともあります。
それは納品物から手が離れることです。
納品後に機能の追加や修正の要望があれば、(基本的に)新しい仕事になるので、それほど依頼は発生しません。大雑把に言えば、納品物の内容を忘れてしまっても、後で後悔する可能性は小さいです。依頼が来たときに、少し多めに苦労すれば良いのです。
これが自社内で使われるシステムだと、機能追加や修正の要望、バージョンアップの依頼が簡単に発生することでしょう。納品物の内容を忘れることはできませんし、予めそういった依頼が来ることを想定した作りにしておく必要があります。
まとめると
・客先納品：開発速度が大事。YAGNI原則マンセー
・自社納品：保守性や拡張性が大事。
ということです。
開発担当者の人数の違い
前職では3年くらいは開発者は私1人でした。当然納品物は1人で作ります。
freeeでは開発者は会社全体でたぶん数百人、今のプロジェクトでは3人で作っています。
それによって何が違うかというと、
・作るものの規模
・チーム開発にかかるコスト
が違います。
前者については当たり前なので、説明はしません。
チーム開発にかかるコストで大きいのは、コミュニケーションコストとソース管理のコストでしょうか。意思決定者に聞かないと進められない・コミュニケーションロスによる不要な作業の発生・他の人が作った機能を学習する時間などなど。
一人開発だと、作業者＝意思決定者ですし、コミュニケーションロスはそもそも発生しません。書き方が良くないこと(可読性や拡張性が低い等)が分かっていても、それほど問題ありません。前述の通り、開発速度優先だったので、ここに時間を使うべきではありません。直すなら、いったん完成させてからです。
またgitも使いません。開発中のコードはローカルPCでコピペでした。
(＆一応ファイルサーバーにも最新ソースをバックアップ)
ちなみに、開発中のコードをコピペで履歴管理するのって古いやり方ですが結構良いんですよね。どうせ遡ることって滅多にないので、その稀な事態が発生したときに不便を感じればよく、トータル時間で考えると履歴管理は最小コストのやり方で良いと思ってます。繰り返しになりますが、納品に耐えうるものが完成するまでは速度優先です。
この辺り、チーム開発ではそうも言ってられず、避けられないコストになっています。
コミュニケーションコストもソース管理のコストもなるべく減らす方法を取り入れていかなければなりません。（ただ、その方法を取り入れるのに学習コストがかかるという、悶々とした気持ちがあります）
freeeに転職して
freeeは自社納品でチーム開発なので、それに適した開発スタイルに慣れていかないといけません。
ソースはgit管理でPR＆レビュー、クラウド管理はterraform、CI/CD、IAMの設定は最小権限などなど。
色々と学ぶことが多い毎日ですが、早くパフォーマンスが発揮できるように頑張ります。
最後に
この記事からなにか学ぶっていうようなものは無いと思いますが、
強いて言えば、スタートアップの段階の企業は、いきなり高度な開発スタイルを整えるのではなく、会社規模がある程度の段階になるまでは速度重視で突っ切った方が良いかもしれません・・・どうせ最初の頃は開発以外の作業も多々担当することになるので