最も重視しているのは，個人のポテンシャルの最大化です． その為に以下のような文化を大切にしています． 1. 属人化の排除と自動化 2. ミッションと評価の明確化 3. 薄いレイヤと大きな裁量 1. 属人化の排除と自動化 1.a. Ruby on Railsの採用 Ruby on Railsがあらゆる開発現場で最適のフレームワークではありません． アニポスには10以上の言語・フレームワーク上でプロダクションコードを実装した開発経験の豊富なメンバーが複数人居ますが，技術選定の肝は「適材適所」という立場です． フロントエンドエンジニアとバックエンドエンジニアが分業体制で，後者がAPIに新しい機能を追加したが，前者にリソースの飽きがないため管理画面が取り残されたまま，といった開発現場は誰しも見たことがあるのではないでしょうか？ アニポスでの技術選定の際に意識したのは，そのような体制で生じるコミュニケーション・コストや硬直性を防いで，個人のパフォーマンスを最大化することです． そこでアニポスはRuby on Railsを採用することにしました． Railsは学習コストの高いフレームワークですが，習熟することで，DBレイヤから薄いフロントエンドまで(業務システムに置いてJavaScriptを必要とする要求はそれほど大きくはありません)，驚くほど少ないコード量で実装することが出来ます． 1.b. 全員が全領域の開発に従事 アニポスの開発対象は - Ruby on Rails - 保険基幹システム - アプリバックエンド - いわゆる管理画面 - 社内BPOチームの使用ツール - Flutter - スマホアプリ と多岐にわたります． どこが重点領域になるのかは，事業方針やタイミングによって変わってきます． その中でパフォーマンスを最大化する事を考えた時，状況に応じて柔軟にリソースをシフトできることが重要だと考えています． アニポスではタスクの割り振りの際に，メンバーのアサインが特定のプロジェクトや技術領域に固まらないように努めており． 例えば，アプリに小さな機能を追加する場合には，要件定義→アプリ及びバックエンドの開発→リリースまで一人の開発者が一気通貫で担当することが多いです． 生成AIのコーディング能力が飛躍的に向上し，Forward Deployed Engineerのような概念が登場する中，こうしたチーミングの価値は更に上昇していくものと考えています． 1.c. 徹底したコード化・自動化 少人数のチームでパフォーマンスを発揮するために，個々人が - ドメイン知識にスムーズにキャッチアップ出来ること - 本質的な業務に集中できること を，コードによって実現することを目指しています． 具体的には， - 仕様のURLや複雑なコード中のコメントによるドキュメンテーション - TDDの徹底 - コーディング規約や脆弱性チェックも含めたCIルール化 - アプリ・Webのリリース自動化・テンプレート化 - すべての開発・デプロイ環境のDocker・k8sによる定義 - Githubの設定からインフラ構築までのTerraformによる定義 を行っています． ---- これら3つの体制方針によって，アニポスはエンドユーザ向けアプリから保険会社向けのミッション・クリティカル・システムまでを少人数で提供する，という事を実現しています． 2. ミッションと評価の明確化 Githubのissue単位からプロジェクトのリードまで，何がミッションなのかを明確化する事をモットーにしています． エンジニア領域・PM領域それぞれの担当ミッションに応じて評価が半自動的に決まり，曖昧な人事面談等のイベントは存在しません． 3. 薄いレイヤと大きな裁量 3.a. 自由な勤務形態 リモート・出社の勤務形態は自由です． 定例会議は - 月一回の全社定例会 - 週一回の開発定例 - 週一回のCTOとの1 on 1ミーティング のみになります． 3.b. ワン・チーム 現在アニポスには4人のフルタイム開発者と4,5人のパートタイム・インターンのメンバーが在籍していますが，部署や役職による隔ては有りません． 開発メンバーは全員がCTO直下に配属されます． 3.c. 大きな裁量 許可より謝罪，CTOがOKと言えばOKです．