Jitera のコアエンジニアリングチーム全員が共有する、エンジニアリングの原則。そして参加を検討し てくれる人に向けては、私たちがどういうチームで、どういう人を求めているかの公開された宣言でも ある。 これに共感できるなら、ぜひ話したい。共感できないなら、おそらくお互いにフィットしない——それを 早い段階で互いに知れることは、双方にとって価値がある。 このドキュメントは「禁止事項リスト」ではなく、私たちがどういうチームでありたいかの宣言であり、各 自のコミットメントである。メンバーはチームに参加するとき、これらの原則にコミットする。
AIコーディングに 100% bet する ● AIによるコーディングに全振りする。ヒトのレビューは引き続き必要だが、その人手レビュー すら減らす仕組みづくりに貢献する。 ● AIだけでプロダクトが自律的に成長していく仕組みを志向する。 ● 「AIにやらせるより自分でやった方が速い」で止まらず、AIが繰り返し実行できる形に落とす。
業務すべてを AI native に行う(エンジニアリングを越境する) ● チームは AI native である。エンタープライズセールスを除くすべての業務を、AI native に実 装していく。 ● 人の採用よりも、AI(エージェント)の採用・活用を優先して考える。まず「AIに任せられない か」を問い、人を増やす前に仕組みで解く。 ● エンジニアであっても、エンジニアリングという一つのロールにとどまらない。営業・マーケ・ CS・コーポレートなど、幅広くマルチロールで働く。 ● 「これは自分の職種ではない」で止めない。プロダクトとビジネスの成果に対してオーナー シップを持つ。
3. 「一人で良いプロダクトを生み出せる人」でチームを構成する ● オーナーシップ・プロダクトデザインスキル・テクニカルスキルを併せ持ち、一人で設計・発 明・デリバリーまで完結できる人でチームをつくる。 ● 自分の担当範囲を「言われたことの実装」に狭めず、課題の発見からデリバリーまでオー ナーシップを持つ。 ● 採用(ヒト)は全員一致を原則とする。採用に関わったメンバーの誰か一人でも疑問を呈した ら、その採用は行わない。
4. チームの合意・規範に従う ● 個人の判断で勝手に好みのライブラリ・ツール・設計を持ち込まない。 ● たとえそれが技術的に正しくても、チームの同意を得ずに新たな設計・依存・規約を独断で導 入しない。 ● 変えたいものがあるなら、まず提案し、合意を得てから入れる。合意済みの規範には従う。
5. マネジメントとコミュニケーションを最小限にする ● マネジメントの必要性を最小限にする。各自が自律的に意思決定し、確認・許可を求める往 復を減らす。 ● コミュニケーション・伝達コストを最小限にする。AIエージェントによって実装が速くなったぶ ん、いまや最大のボトルネックは人どうしのコミュニケーションである。 ● 同期(会議・口頭)に頼らず、ドキュメント・コード・PR で非同期に伝わる形を第一にする。読 めば分かる状態をつくる。 ● ただし「チームの合意・規範に従う」原則と矛盾させない。新しい依存・設計・規約のような全 体に影響する判断は合意を取る。日々の実行は許可を待たず自律的に進める。
6. チームの和を大切にする ● ハラスメントをしない。チームの和を乱す言動をしない。 ● 立場・経験・バックグラウンドにかかわらず、敬意をもって対話する。 ● 意見の対立は、人ではなく課題に向ける。
7. 自らが顧客になる(ドッグフーディング) ● 自分自身が顧客となり、「自分が良いものをつくっている」と実感できる機能をつくる。 ● 顧客と直接会話し、自らインサイトを得る。憶測ではなく、観測した顧客の声を起点にする。
8. 設計・テストドリブンで開発する ● 設計とテストを先に置いてから実装する。 ● コードやAIによるテストに加えて、自らの手でブラックボックステストを行う。
● AI機能を実装するときは、Eval や決定論的テストを先に設計・実装してから機能をつくる。 ● 分析が行き詰まったときは、憶測で進めず、観測できるログを増やしてから判断する。
9. リリース品質はエンジニア自身の責任であり、QA に肩代わりさせない ● QA は原則としてチームに1人だけ置き、よほどの理由がない限りこれを維持する。QA を増 やして品質を担保する、という考え方を取らない。 ● QA は顧客の立場に立って受け入れテスト(acceptance test)を行うヒトであり、各開発アイテ ムの事前テストを代行するヒトではない。 ● 各開発アイテムが本番リリースできる品質にあることは、エンジニア自らがテストして担保す る。QA の事前チェックを前提に実装を投げない。
10. 自らリリース計画を練り、本番で動作確認する ● リリースは毎日のように行ってよい。リリース頻度を落とすことで品質を守る、という方向は取 らない。 ● ただしリリースのたびに、エンジニア自らがリリース計画を練り、テストを行い、本番環境での 動作確認まで行う。 ● リリース計画には、切り戻し(ロールバック)の判断基準と、ロールバックの設計・準備を含め る。「どうなったら切り戻すか」を事前に定義し、実際に切り戻せる状態を用意してからリリー スする。 ● リリースを「誰かが面倒を見てくれる工程」にしない。計画・実行・本番確認・切り戻しまで一 貫して自分の責任とする。
11. 本番リリース前に顧客向けドキュメントを書く ● 本番リリース前には、自ら顧客向けのドキュメントを記載する。 ● 機能のリリースとドキュメントは一体。コードだけ出してドキュメントを後回しにしない。
12. モノリス・単一DBのアーキテクチャを保つ ● 完全モノリシックな自己完結アプリケーション(単一バイナリ)として作り、コードは1つのリポ ジトリに集約する。AIコーディングの効果を最大化し、かつセルフホストの運用を可能にする ため、マイクロサービスは採用しない。 ● データベースは PostgreSQL、またはその互換のものを1つだけ採用する。用途ごとに別種 の DB を増やさない。 ● この方針を変えたくなった場合も、「チームの合意・規範に従う」原則のとおり、独断で別構成 を持ち込まず、まずチームの合意を得る。
13. 顧客データと、託された信頼を守る ● 私たちは顧客のコードとデータを扱う。それを守ることを、後付けではなく一級のエンジニアリ ング責任として扱う。 ● 機能が本当に必要とするものだけを収集・保持する。明確な理由とチームの合意なしに、機 微な顧客データを保持しない。 ● セキュリティはリリース品質と同じく、エンジニア自身の責任である。誰かに肩代わりさせた り、後のレビューが拾ってくれると当てにしたりしない。 ● 脆弱性やデータの取り扱い上のリスクを見つけたら、自分の担当外であっても、その修正を 最優先で扱う。
14. 自らソフトウェアをオペレーションする ● 「作って終わり」にしない。動かし続けることまで自分の責任とする。 ● エラー・ワーニングログがあったら、自分の担当外であっても自ら率先して解消する。 ● サーバー・インフラのメトリクスを自ら確認し、異常があったら率先して対応する。 ● SLA は 99.9% を満たす。可用性は自分が担うものとして扱い、リリースの速さと引き換えに 犠牲にしない。
この原則は固定ではない。改善提案は歓迎する——原則について疑問があるとき、変えたいことが あるときは、気軽にチームに提起してほしい。ただし変更そのものも「チームの合意・規範に従う」原 則のとおり、チームの合意を経て更新する。