なぜ海外ではソフトウェア開発のプロジェクトが炎上しにくいのか 〜ドイツより～
はじめに
ドイツ・ベルリンに本社がある新興の大手IT企業に、ソフトウェアエンジニアとして、2022年夏から現地で働いてます。
具体的な職務内容はBig Data x Cloud Architectに関わる業務全般で、ビッグデータの抽出・加工・書き込みのアプリケーション、またはそれらのデプロイメントとリリースを自動化するウェブサービスの開発などです。
この記事では、なぜ（典型的な）海外のプロジェクトが日本に比べて炎上しにくいか、自分が体感した4つの理由を書きます。
受注開発（SIer）ではなく内製開発
正直なところ、海外の企業で炎上を防げている60%以上の理由はこれだと思います（笑）海外ではSIerもありますが、内製開発の方が多いです。
社内のプロジェクトなので要件やコスト管理を厳密にする必要がないですし、途中で機能要件・コスト・納期を変更しやすいです。
そもそも、自分はプロジェクトの炎上とは成果物がステークホルダー（例：顧客）の期待値に応えられていない状態だと思っています。
なので、受注開発のエンジニアだと、完璧に社内の機能要件、スケジュールを達成しても、そもそもSIer側のディレクターと顧客の期待内容が違っている場合に不満をもらい、やり直しになる場合はよくあります。
そのため、炎上を起こさないためには
開発機能の期待値を顧客と合わせる
締切までに要件通りの機能を開発する
の両方が必要です。
しかし、受注開発では１の開発機能の期待値を合わせることが難しいです。
そもそも要件を文言やグラフで全て網羅することは難易度が高い。
顧客の窓口の人が必要な仕様を理解しておらず、上層部の意見で後から仕様がひっくり返り、結果的に不満が出る
フロントエンドなど見た目の部分はやってみて、出来上がりをみないと、分からない繊細な部分がある（あまり髪型について分からないけど、何となくいい感じにして欲しい顧客と美容師の構造と同じ）
期待値を合わせることは不可能ではないですが、技術的な部分の開発・解析・修正について、丁寧な説明・連絡・説得をすることは大変です。
エンジニア経験があって顧客の背景や意図も理解できるディレクターが必要であり、そういう人は日本も海外も少ないです。
これら全てを曖昧にしやすく、その分のコミュニケーション時間を減らせて、後から要件・コスト・納期を柔軟に変更できる内製開発の方がやはり炎上は少ないです。
ウォーターフォール開発ではなく、アジャイル・スクラム開発にしやすい
これは炎上防止に10%くらい関係していると思います。そもそも、最初にあった内製開発を前提としているので、可能だと思ってます（笑）
海外でよく採用されているアジャイル・スクラム開発では、以下の開発ステップを短いサイクルで行います。
設計
→ 開発
→ テスト
→ リリース
→ 評価
----> 次サイクルの設計
前期の評価をもとに次期の設計と開発に活かしていき、多少の手戻りがあったとしても長期的には高品質なアウトプットにできる、というのがアジャイルの考え方です。
一方、日本のSIerで主流のウォーターフォールでは大きく一回のみ、設計 → 開発 → テスト → リリース → 評価を行います。
工程がシンプルなので、それぞれの締切日も決まっています。
両者を比較すると、アジャイル・スクラム開発の方が開発の方向性を柔軟に変えていけるので、ウォーターフォールよりも長期的に高品質・高速にできる傾向があります。
また、開発が遅延している時に、次のサイクルでスケジュールを調整しやすいです。
それゆえ、よく海外のエンジニア・マネージャーから『日本の会社(SIer)もアジャイル型にすれば良いのに』という意見を聞きます。
しかし、これは受託開発とその契約の問題があって、不可能に近いです。
受託開発の場合は、大規模な成果物に対して、品質、ボリューム、期限などある程度の確実性が必要です。
そのため、請負開発（請負人の仕事の完成に対し、注文者がそれに対して報酬を支払うという契約）の場合が多いです。
また、さまざまな関連サービスとの調整もあるので、最初からリリース日が決まっています。
この辺りについて、ピンとこない場合、以下の別サイトの記事が参考になると思います。
旧来型SIerでアジャイル（スクラム）が上手く行かない５つの理由
ガバナンスが強い
これは炎上防止の20％くらいに関係していると思います。
たとえば、プロジェクトの進行管理を行うプロジェクトマネージャーに加えて、プロダクトの品質を管理するプロダクトマネージャーもいます。エンドユーザー、現場のエンジニア、上層部の意向などを聞き取り、プロダクトの方向性を調整したり、プロダクトの良さをアピールします。
また、エンジニアの職務で言えば、熟練度に応じた階段(Career Ladder)があり、それぞれの権限と責任範囲が海外の企業の方がしっかり定義されています。
Junior Software Engineer
→ Software Engineer
→ Senior Software Engineer
→ Principal Engineer
さて、これらのガバナンスが強いとどうして炎上しにくいのでしょうか。
言語、フレームワーク、ツールの選定が安定する・・・世界的に将来性のある、ベンダーロックにはまりにくいツールをトップダウンでしっかり選び、会社ではそのツールの使用を推奨します。
全く同じ用途だけど、チームごとに使っているツールが違うということを防ぎ、一貫して使用することで運用コスト、学習コスト、ツールの変換コスト、コミュニケーションのコストなどを削減できます。プライオリティがしっかり決まる・・・指揮系統と責任の所在がある程度、決まっているので、何のタスクを先にこなす必要があるのか、個人の判断ではなく、チームレベルで決まっています。
純粋なマネージメント力が高い・・・スクラム開発などのマネージメントトレーニングを受けてきた人が多いので、マネージメント力が安定しています。ただ、日本でも特に大きな案件ではマネージメント力の高い人がマネージャーになっています。
高度な人材の採用＆適切な案件へのアサイン
最後ですがこちらは炎上の10％くらいに関係していると思いますが、上述のガバナンスが効いているゆえに、できていることだと言えます。
チームに適切な人の数を新しく採用：日本では、案件規模に比べて過少になりがちで、現場が炎上・疲弊する→案件・売上が減る→さらに人を減らす、という負のスパイラルを見ます。（機会ロス）
専門性のある人を採用：少なくとも若さよりも、関連した経験が重視されるのが大きな違いだと思います。人物面や同僚とのフィット感はこちらでも最終段階で考慮しますが、日本ほどではないです。
適切な案件に配置：上記の通り、専門性をある人を採用しているので、適切な案件に配置しています。バックエンドの経験が全くないにも関わらず、大きなバックエンドの開発責任を負うことなどは基本的にないです。
一方で、日本では新卒エンジニアに大きな改修を任せてみたなど『あるある』な話で、インターネットでもそういった開発記事を見かけます。
まとめ
なぜ（典型的な）海外のプロジェクトが日本に比べて炎上しにくいか、自分が体感した4つの理由を書きました。
60％：受注開発（SIer）ではなく内製開発
10％：アジャイル・スクラム開発にしやすい
20％：ガバナンスが強い
10％：高度な人材の採用＆適切な案件へのアサイン
ただし、受託開発を内製開発に切り替える、徐々にシフトするなどはかなり難易度が高いと思います。なので、海外の企業から学べることとしては後半２つの
ガバナンスの強化
高度な人材の採用＆適切な案件へのアサイン
になるかと思います。
以上です。
Happy Coding!
この記事が気に入ったらサポートをしてみませんか？