「決まった型にはまるのではなく、ゼロから創る」そんな環境を求めているなら、DINAMICAはまさにその舞台として最適です。
私たちのプロダクト
.png)
Toursサービスサイト
.png)
バチャナビサービスサイト
上記プロダクトは密接に連携しており、組み合わせることで、求職者は時間や距離の制約なく職場の雰囲気をリアルに感じることが可能です。企業文化を“体験”として伝えることで、採用の質を向上させ、より効果的な採用活動を実現しています。
このチームで働くと、こういうことを大切にすることになります。
- 要件定義や設計、実装、運用に至るまで開発に関わる領域に幅広く関わる（コードを書くだけでなく、システム設計や意思決定にも関与）
- 技術選定・アーキテクチャ設計に関与できる（単なる実装要員ではなく、"どう作るか" まで決める）
- 迅速な意思決定を求められる（変更容易性を確保しながら、スピーディに試す文化）
- 会社やプロダクトの未来に影響を与える責任を持つ（黎明期だからこそ、"今の開発が未来を決める"）
このチームに入ると、こんな課題に一緒に取り組むことになります。
- 開発体制が限界に近づいている
- 現在のエンジニア組織は、正社員1名＋業務委託2名の体制で創業から開発を進めてきました**。**
- この少数精鋭体制でここまで作り上げてきましたが、今の開発スピードでは事業成長に追いつかなくなってきています。
- プロダクトの拡張や新機能開発を加速させるには、今が新しいエンジニアを迎えるタイミングです。
- ドキュメントが不足しており、ナレッジの共有が難しい
- 仕様や設計の意図が言語化されておらず、新メンバーのキャッチアップに時間がかかる
- 改善策：技術ドキュメントの整備、ナレッジ共有会の実施
- 開発スピードを優先することによる技術負債の蓄積
- 現在の開発チームの方針が「まずは最速で動くものを作り、ユーザーからのFBを得る」ということもあり、スピードは担保されるが技術負債が蓄積されやすいという特徴がある
- エッジケースの考慮漏れが発生し、デプロイ後にバグに気付く場合がある
- 改善策：
- 最速で作って検証すべき開発と慎重に進めるべき開発とを判断する基準を設け、それに応じて開発スタイルを柔軟に変える
- 定期的にリファクタリングDayのような日を設け、技術負債の返済ができる体制を整える
- 開発と運用の役割分担が曖昧
- サーバー管理・監視・オンコール対応が少人数の負担になっている
- デプロイフローがまだ最適化されておらず、本番環境でのトラブル対応が属人化しがち
- 改善策：SRE的な考え方を導入し、運用負担を分散
- プロダクトの方向性が変わるスピードが速い
- ビジネスサイドの意思決定が速く、エンジニアリングとのバランスを取るのが難しい
- 仕様変更に柔軟に対応できるアーキテクチャ設計が求められる
- 改善策：技術負債を溜めすぎず、変更容易性を確保するためのアーキテクチャ設計を進める
DINAMICAのエンジニアとしての働き方/開発プロセス
- 「ユーザーにとって価値があるかどうか」を基準に仕様を考える