システム開発はなぜうまくいかないのか？（自社開発編）
システム開発はなぜうまくいかないのか？（自社開発編）
さて、システム開発はなぜうまくいかないのか？シリーズも3つ目になりました。外注に丸投げじゃ良いものが作れないのわかったわ！と自社開発にチャレンジする企業は増えています。セブンペイで炎上した7&iホールディングスさんも過去の教訓から正しいアプローチに切り替えている様です。
無印良品が騙された悪質なベンダーについて
無印良品さんは、コンサルのふりをしたベンダーに騙されていました。そこのベンダーの謳い文句は「うちは開発も出来るほど技術力のあるコンサルで、大手Sierに頼んだらぼったくられますよー」という触れ込みで無印のシステム開発案件を受注したらしい。
以前の記事にも書いていたけど、独自フレームワークを使って手離れを悪くさせていた悪質な技術力のないベンダーはここで、無印良品はそのベンダーのエンドクライアントでした。僕はオフショア開発会社側のPMとして参画しました。なので、僕自身、ベンダーが作った在庫管理システムのソースコードを見たことがあります。現場の雰囲気は最悪で、まずこちらの提案が何も通らない、ベンダー側のPMがExcelが大好きな仕事の出来ないPMで、JIRA等のチケット管理ツールの導入を何度も提案したけど提案が通らず、オフショア側はJIRAで管理して毎日Excelに転記をするという無駄な作業をしていました。ソースコードもエンジニアならリファクタリングしたくなるような品質の低いスパゲッティコードでバグが頻発し、毎日デバッグに追われていました。
クラス名やメソッド名も理由のわからない日本語が使われていたり、独自フレームワークを作ったエンジニアはもう3年前にそのベンダーを辞めていて誰も直せない状況だったり、お客がソースコード見てもわからないからと嘘をついていたり、客の無知に漬け込むビジネスモデルに嫌悪感を感じました。と同時に、この事実を無印良品さんに伝えたいと思いました。「もうこんな技術力のないベンダーは放っておいて、自社開発にチャレンジしましょう！そうしたら今よりも、もっと安く、もっと早く、もっと使いやすいUIの、良いシステムを作れますよ！」と伝えたかったので、今このnoteを通して自分の意見を発信出来る世の中に感謝です。もし、この記事が無印の中の人の目にとまれば嬉しいです。また、そのベンダーは無印良品の著作物であるソースコードを他社であるDAISOにも有料で提供しておりました。私は契約書を読んで居ないので違法かはわかりませんが、倫理的に考えてもおかしな事をしているベンダーでした。
一般的な請負契約の場合、納品のタイミングで無印良品に所有権や著作権が移ります。準委任契約の場合は、最初から無印良品の著作物です。それはもちろん、無印良品がお金を出して無印良品だけのために作られたオーダーメイドシステムなわけですから、それを他社に提供するのであれば無印良品の許可が必要になるわけです。ただ、そのベンダーはソースコードの共通部分は流用して、一部をカスタマイズして他社に売っていました。
リクルートの技術力
私は元々リクルートに居たから良くわかりますが、良くも悪くも営業会社です。なので、システム開発や技術のことはわからないんです。以前は開発は完全にベンダーに丸投げでした。最近は子会社のリクルートテクノロジーズなどで積極的にエンジニアを採用しているのかと思ったのですが、実際はベンダー離れが出来ずに折角の自社開発なのにウォーターフォールをしていました。実際、開発ベンダー経由でリクルートにアジャイルコーチとして参画したことがありましたが、小さなウォーターフォールを繰り返しているだけで、アジャイル開発の実践は全く出来ていませんでした。私は、自社開発をしていたらOKと言いたいのではなく、自社開発じゃないとアジャイル開発を実践することが難いから自社開発を提案しているだけです。
アジャイル開発とは
ここで、アジャイルという概念について少し説明したいと思います。アジャイル（agile）とは、英語で「素早い」「機敏な」「頭の回転が速い」という意味で、ビジネスシーンでは「状況の変化に対して素早く対応すること」を表す言葉として用いられています。
アジャイルとは大きな概念でして、予測不可能な未来や予測していなかった変化に対して、その時、その時、で常に最善の道がないかを模索し続ける。という考え方です。アジャイルはソフトウェア開発などの分野で使われていましたが、私は、組織のマネジメントや経営手法にも転用が出来る考え方だと思っています。
アジャイルソフトウェア開発の歴史は、2001年に一つの重要な出来事にさかのぼります。その年、17人のソフトウェア開発者が米国ユタ州のスノーバードで会合を持ち、「アジャイルソフトウェア開発宣言」を発表しました。この宣言は、ソフトウェア開発に関する従来の手法に対する新しいアプローチを提唱し、以下の4つの基本的な価値を中心に据えています：
プロセスやツールよりも個人と対話を
包括的なドキュメントよりも動くソフトウェアを
契約交渉よりも顧客との協調を
計画に従うことよりも変化への対応を
これらの価値は、ソフトウェア開発の過程で柔軟性と効率性を高めることを目的としています。アジャイル宣言の背後には、スクラム、エクストリーム・プログラミング（XP）、クリスタル、フィーチャー駆動開発（FDD）、ダイナミックシステムズ開発メソッド（DSDM）、適応型ソフトウェア開発（ASD）など、さまざまなアジャイル開発手法が存在していました。これらの手法は、それぞれ異なる特徴を持ちながらも、柔軟で迅速に変化に対応する開発プロセスを共有しています。
アジャイル開発の背景には、1990年代におけるソフトウェア開発プロジェクトの遅延や失敗が多発した経験があります。従来のウォーターフォールモデルなどの厳格な計画と段階的な開発プロセスは、急速に変化する市場の要求に対応するにはあまりにも硬直的でした。アジャイル開発は、このような問題に対する解決策として登場し、ソフトウェア開発のアプローチを根本的に変革しました。
アジャイル開発は、ソフトウェア開発プロジェクトを効率的かつ柔軟に進めるためのエンジニアのマネジメント手法です。この手法は、短い開発サイクル（通常「スプリント」と呼ばれる）を繰り返し行うことに特徴があります。各スプリントでは、チームが設計、開発、テスト、レビューを行い、実際のプロダクトの一部を作成します。アジャイル開発の主な目的は、顧客の要求の変更に迅速に対応し、製品の品質を高めることにあります。
アジャイル開発の主な原則
顧客満足の優先：顧客の要求に応じて頻繁に価値あるソフトウェアを提供します。
変更への対応性：市場や顧客の要求の変化に柔軟に対応し、それを製品に反映させます。
頻繁な納品：短い期間（数週間から数ヶ月）で動作するソフトウェアの納品を行います。
協働：ビジネス側と開発者が日常的に協力し合います。
モチベーションを支える環境：プロジェクトに関わる人々が最高の成果を出せるよう、必要な環境や支援を提供します。
対面でのコミュニケーションを重視：チームメンバー間の効果的な情報伝達と意思決定のために、対面でのコミュニケーションを重視します。
動作するソフトウェアが進捗の主要尺度：文書や会議よりも、実際に動作するソフトウェアの開発に重点を置きます。
持続可能な開発：開発者、顧客、ユーザーが無理なく継続的に働けるペースを保ちます。
技術的卓越性と良い設計の追求：アジリティを高めるために、技術的な品質と設計に注力します。
シンプルさ：不要な作業は極力排除し、シンプルさを追求します。
自己組織化するチーム：最高のアーキテクチャ、要件、設計を生み出すために、チームが自ら組織化することを奨励します。
定期的な振り返りと調整：効率的な方法で作業を進めるために、定期的にチームの振り返りを行い、適宜プロセスを調整します。
アジャイル開発の代表的なフレームワーク
スクラム：小さなクロスファンクショナルなチームが、定期的なスプリントを通じてプロダクトバックログから優先度の高い作業を選び、実行していくフレームワークです。
カンバン：「進行中の作業」の量を制限して、作業の流れを最適化し、効率を向上させることに焦点を当てたフレームワークです。カンバンは視覚的な管理ツールとしても利用され、タスクや進捗状況を一目で把握できるようにします。
エクストリーム・プログラミング（XP）：短い開発サイクル、継続的なフィードバック、優れた品質、プログラマの福祉に重点を置くアプローチです。ペアプログラミング、テスト駆動開発（TDD）、リファクタリング、継続的インテグレーションなど、具体的な技術的実践が特徴です。
リーンソフトウェア開発：ムダを排除し、価値のあるものだけを迅速に顧客に提供することを目指すフレームワークです。リーン製造から発展した原則をソフトウェア開発に適用し、プロセスの改善と効率化を図ります。
アジャイル開発の利点
柔軟性と適応性：市場や顧客の要求の変化に迅速に対応できる。
リスクの軽減：定期的なレビューとフィードバックにより、問題点を早期に発見し、修正できる。
顧客とのコミュニケーションの強化：顧客との密接なコラボレーションにより、顧客の満足度を高めることができる。
品質の向上：継続的なテスト、レビュー、リファクタリングにより、高品質なソフトウェアの開発が可能になる。
チームワークとモチベーションの向上：自己組織化されたチームによる協働と、成果に対する責任感が高まる。
アジャイル開発の課題
スケールの問題：大規模プロジェクトや分散チームでは、アジャイル開発を適用する際に困難が生じることがあります。
文化とマインドセットの変革：従来のウォーターフォールモデルなど、より計画重視のアプローチに慣れている組織やチームにとって、アジャイル開発への移行は大きな文化的変革を要求します。
継続的な顧客の関与：顧客の継続的な関与とフィードバックが必要であり、これが常に可能であるとは限りません。
ウォーターフォール開発の難しさを揶揄したイラスト
このジョークは、要件の伝達やコミュニケーションの難しさ、そして期待と現実のギャップをユーモアで表現したイラストです。顧客がシンプルな要求をしても、その要求が多くのステップを経て変わってしまうことを示しています。
ウォーターフォール開発の流れです pic.twitter.com/hF0ksqzZho
— うめめ (@beConjuror) November 1, 2021
まとめ
アジャイルという概念について、興味を持っていただいたり、ご理解いただけたらとても嬉しいです。弊社では、初回相談は無料で行っております。ベンダー選定時、ベンダー乗り換え、自社開発への挑戦、エンジニアの採用、などの際に是非ともお気軽にご相談ください。個人的に仲の良い優秀なフリーランスエンジニアも居ますし、パートナー企業からのSESも可能です。開発に関わる事であれば一気通貫でサポート出来ますので、是非とも宜しくお願い致します。
この記事が参加している募集
この記事が気に入ったらサポートをしてみませんか？