はじめに

こんにちは、プロダクトマネージャーの田原です。

新規サービスの開発をする際、開発スピードは重要な要素になるため、どうしても目の前の機能を実現することが至上命題になり、その過程で生産性を低下させる要素がいろいろなところに紛れ込んでしまう、というのはよくある話ですよね。

弊社7gardenもスタートアップとして新規サービスの開発を進めるに当たって、やはり上記のような課題を感じる場面が多々ありました。今回はそんな課題に対して弊社がいかにエンジニアが幸せに開発を進められる環境づくりを試みているか、を紹介していこうと思います。

タスク管理にGithub Issue・Github Projectを活用する

プロジェクト管理では、Trello、BackLog、Jira etc...　などなど有名で優良なサービスが沢山ありますね。

ですが複数の機能を並行して開発していたり、またそれらの開発タスクに前後関係があるような場合、下記のようなことが面倒に感じられます。

• 開発タスクに対応するブランチの把握
• 開発タスクに対応するPRの把握
• 開発タスクのステータスが変わった際にカンバン上のチケットの移動
• リリースバージョンにマージされているブランチの把握

etc...

これらは当たり前に行うことですし、手作業による対応でもカバーできます。例えば「カンバン上のチケットにブランチ名を記載しておく」などといった対応です。実際にTrelloを利用してそうしていた時期もありました。ですが

• ブランチを切る度、PRを作成する度にチケットにも記載する
• 開発の進捗に応じてカードを移動する
• 細かなバグ対応も含めてリリースブランチにマージされているブランチをメモしておく

etc...

といった面倒な手作業が発生することになります。面倒な手作業は即怠惰な気持ちにつながり、生産性の低下を招きます。管理も煩雑になります。

Github IssueとGithub Projectを活用すれば、ブランチ、PR等をGithub Projectのカンバン上のチケットと自動で紐付けて管理することができます。ステータスによるチケットの移動も50%くらい自動化できます。Git管理とタスク管理が連動すれば開発タスクの全体の見通しもよくなります。

特に数名〜十数名規模のチーム開発をする際にはおすすめです。

意外と使われてないイメージのGithub Projectですが、開発のストレスをかなり減らしてくれたなあと実感しています。

SlackをGithub Issueと連携する

当然エンジニアだけでモノ作りするわけでなく、営業・CS・ビジデブと多くのステークホルダーと一緒にサービスを作っていきます。その中では様々な要望が溢れています。それをストックされない状態でチャット上で１つ１つ拾っていくのはかなり大変です。

弊社ではSlackの特定のチャンネルでslack workflowで設定されたフォームから投稿されたものを自動でGithub Issueに登録されるWork Flowを組んでいます。上述のGithub Projectの機能と合わせて、要望がIssueに登録されたら自動でGithub Projectのカードとして登録されます。

テストコードを書く

多くの開発現場の方からすると、「当たり前でしょ」と感じられるかもしれません。

一方で、「スタートアップはスピード重視だから」「テストコードのコーディングはスケジュールに収まらない」という理由で小規模チームによる新規サービス開発では敬遠されることが多いのも事実です。実際僕がそう思っていたことも一時期ありました。

行き着いた結論は「テストコードは開発の負担を減らしてくれる。中長期的にはスピードも上げてくれる。」です。

テストコードがない状態では、サービスの機能が多くなればなるほどリリースのたびにディグレッションを細かくチェックしたり、機能開発のたびに、既存のロジックをバグらせてないか神経を使いながら実装をしてくことになります。

特にサービスが成長していくほど手動によるテストは本当に大変です。

テストコードがそれらを100%無くしてくれるわけではありませんが、負担を軽くしてくれることは間違い無いです。

有名な格言↓

「時間がないからテストコードが書けないのではない。テストコードを書かないから時間がなくなるのだ」

間違いない。自分たちの幸せのためにテストコードを書いていきましょう。

Circle CI/CDの導入

テスト実行・結果の可視化の自動化も重要でした。手動ではテストの抜けもれやそれをチェックするフローが必要になります。

テスト実行→結果の可視化→デプロイの自動化

は開発フローを楽にしてくれます。

TypeScriptを使う（特にフロントエンドで）

tunaにはCRMと予約エンジンの大きく２つのサービス群があり、

• CRMは既存のサービスを機能拡張
• 予約エンジンは完全にフルスクラッチでの開発

なのですが、フルスクラッチで開発した部分に関してはTypeScriptを導入しました。

既存の生JS部分もTypeScriptへのリプレイスを進めています。

するとどうでしょう、単純なミスによるバグは激減しました。

コードも圧倒的に読みやすいです。

「テストコードを書くべき」と言っておいてですが、「フロントエンドまでテストコードを書くのはきつい」というのは確かにあると思います。そんな中でもTypescriptを導入すれば下記のようなメリットをすぐに感じられると思います

• 変数に入りうる値など、生のJSではソースを読む・実際に動かすことでしか把握できなかった内容がソースから一発で把握できる
• ケアレスミスによるバグをコーディング中にTypescriptが教えてくれる
• コンパイル、ビルド中にエラーを教えてくれる

etc...

これによりリリースするまで気づけないバグを減らすことができます。

とりあえずフロントエンドはTypescript一択！と感じています。

緩めにでいいからコーディングルールをドキュメント化する

サービス開発始動当初はこういったドキュメントが整備されていないことも多いでしょう。

弊社がそうでした。

お互いのスキルレベルもよくわかっており、共通認識も作りやすい初期のフェーズではあまり必要ないかもしれません。ですがそこから、

サービスの成長に伴ってエンジニアが増える →

スキルレベルにも一定ばらつきが出始める →

エンジニア同士の共通認識の構築も徐々に難しくなっていく →

コードベースの品質を担保することが難しくなっていく

こういったフェーズを体験した中で、コーディングルールは中長期的な生産性の確保に大いに役立つと実感しています。（ガチガチにするのは考えものですが）

弊社では主にレイヤーごとの役割や記載すべき内容、禁止事項、その他共通のルールをドキュメントにして共有しています。

（デザインパターンやアーキテクチャのディープな話はまた別の記事で紹介しようと思います！）

最後に

開発のカオスを抜け出すために行ってきたこと・行っていることを紹介しました。小さなものまで含めるとまだまだあるのですが、特にやって良かったと感じていることをまとめました。

もし7gardenのプロダクトや開発に少しでも興味を持っていただけたら気軽にご連絡ください。

ではまた次回！