VOICE

失敗は「財産」に変わる!開発チームを強くする、ジークス流”成長環境構築術”

システム開発に「つまずき」はつきものです。特に複雑な要件が絡み合う業務システム開発では、どんなに注意深く進めていても、思わぬ落とし穴にはまることがあります。

しかし、私たちジークスでは、そのつまずきを単なる「ミス」で終わらせません。失敗を共有し、仕組みで改善し、次の挑戦への糧にする。そんな「失敗を財産に変える文化」こそが、エンジニアが最も成長できる環境を作る鍵だと考えています。今回は、現場のエンジニアが大切にしている、ジークス流の成長環境の作り方をご紹介します。

開発速度を阻害する「見過ごされがちな課題」の処方箋

開発速度を阻害する「見過ごされがちな課題」の処方箋

プロジェクトが停滞する原因は、大きなトラブルよりも、実は日々の小さな「認識のズレ」にあることが多いものです。私たちは、こうした課題を放置せず、具体的な「処方箋」を出すことで開発リズムを整え、開発効率の向上を図っています。

例えば、多くの現場で頭を悩ませる「レビュー待ちの長期化」。実装が終わってもレビューが滞留し、マージリクエストが溜まっていく状況は、エンジニアのモチベーションを削ぐ大きな要因です。私たちはこれに対し、「マージリクエストの細分化」や「AIレビュー」の導入といった運用改善を継続的に行っています。

また、丁寧さを求めるあまり陥りがちな「ドキュメントの書きすぎ」も課題でした。仕様変更のスピードにドキュメント修正が追いつかず、「仕様書と実際の挙動が食い違う」という状態が発生。コードとの不整合が生まれる「情報の負債」を防ぐため、チームで共通フォーマットを定義し、必要な粒度を見極めることで、無理なく更新し続けられる仕組みを構築しています。こうした地道な改善の積み重ねが、開発チームとしての安定感とスピードを底上げしています。

挑戦と失敗が人を育てる、明日から始める「フィードバック文化」作り

「本番環境のファイルを誤って消してしまった」「検証設定のままリリースしてしまった」——。冷や汗が出るような経験ですが、開発現場では誰にでも起こりうるミスです。こうした問題に対しても、ジークスのフィードバック文化が真価を発揮します。

私たちが徹底しているのは、「誰が(Who)」ではなく「何が(What)」にフォーカスすることです。直接の原因がAさんの見落としだったとしても、そこでAさんを責めても再発は防げません。そうではなく、「なぜチェックプロセスをすり抜けたのか?」「二度と起きない仕組みは作れるか?」という視点で、チーム全員で「再発防止の知恵」を出し合います。

「ミスをした個人を責めない」というスタンスは、決して責任をあいまいにすることではありません。一番落ち込んでいる本人を追い詰めるのではなく、事実を直視し、原因を咀嚼して、次に活かすアクションを一緒に考える。この「人を責めず、課題に向き合う」というバランスが、個人の失敗をチームのレベルアップへと変換させ、結果としてエンジニアの育成に繋がります。

挑戦と失敗が人を育てる、明日から始める「フィードバック文化」作り

挑戦を諦めさせない「失敗許容度」の高いチームの作り方

近年よく耳にする「心理的安全性」という言葉。私たちはこれを単なる「仲の良さ」や「甘さ」だとは考えていません。本当の意味で心理的安全性が高いチームとは、プロとしてのリスペクトを持ちつつ、ミスを早期に報告でき、お互いに率直な意見を戦わせられる環境のことです。

心理的安全性は、「チャレンジに対して寛容」「ミスを個人の失敗ではなくチーム課題として捉える」といった意識を現場に根づかせます。ジークスでは、発生した問題をその都度レポート化し、社内の共有システムに蓄積して、他チームの事例も含め誰でも閲覧できるようにすることで、「どこで何が起き、どう対処したのか」を会社全体で学べるようにしています。また、人が関わる工程でミスが起きやすいという前提に立ち、CI/CDの自動化やAIによるレビュー支援など、テクノロジーを活用した改善にも積極的に取り組んでいます。

しかし、自動化がどれだけ進んでも、開発は結局「人」が担う仕事。どれほど注意してもミスを完全にゼロにはできませんが、それを悲観的に捉えず、成長の糧になるものと捉えています。問題が起これば見えづらかった課題が現れ、改善のチャンスが生まれます。原因を見極めて解消できれば、チームは確実に一段階上へと成長していけるのです。

ジークスのエンジニアの間では、「許可を求めるな、謝罪せよ」というフレーズを耳にすることがあります。これは、失敗を恐れて立ち止まるくらいなら、まず動いてみて、もし間違っていたらそこから学んで謝ればいい、という挑戦を尊ぶマインドを表しています。「やり遂げる覚悟」があれば、未経験の領域でもチャンスが与えられる。失敗してもチームがカバーしてくれる安心感があるからこそ、メンバーはフルスイングで挑戦できるのです。

もちろん、積極的に新しい技術に突っ込む人もいれば、既存の土台を堅実に守る人もいます。どちらのタイプもリスペクトし合える「失敗許容度」の高さは、エンジニアが成長する環境に欠かせないものです。私たちは、問題が発生することを「改善のチャンス」と捉え、エンジニアの成長環境作りを考え続ける組織でありたいと考えています。