アジャイルと内製化の話

こんにちは、松本です。

今回はアジャイルと内製化のお話をします。

『アジャイル開発』という言葉が生まれて20年近いので、開発者じゃない方でも聞いたことくらいはあるかもしれません。

（ちなみにウォーターフォールモデルは50年前に生まれたモデルです）

色々な説明がありますが、大雑把に言えば

『小さな機能をユーザーと開発者が協力して少しずつ作っていくスタイル』

です。

ウォーターフォールのように最初からすべてを設計してしまうのではなく、小さなシステムから出発して徐々に全体を作っていく方法です。

なので『小さく設計し、小さく実装し、作った分を検証する』というサイクルを反復して何度も行います。

例えば1週間とか2週間で区切って小さく作りながら前進していきます。

少しずつ確実な石橋を作っていくイメージです。

ウォーターフォールが長大な道路を設計して全部用地買収してから作りはじめるモデルなら、アジャイルは足元の土地から買収して1mずつ設計と施工をしていくようなイメージです。

一見効率が悪いようですが、途中で道路の方向性が変わっても即座に対応できます。

ソフトウェア開発というのは、作っていくうちにいい方法が見つかったり、作っている間に状況が変わったりすることがよくあります。

なので、アジャイルの『小さく確実に前進する』スタイルと相性がいいんですね。

完全なウォーターフォールは人類には無理だった

ソフトウェアを最初から全部設計して開発しきって見事なものが出来上がれば確かにすばらしいのですが、それは人類には無理でした。

数々の墓標（それに伴う訴訟）がそれを証明しています。

実際、アプリだってよくアップデートしますよね。OSだって日常的にアップデートが行われています。

初めから完成品は作れないからです。

アジャイル開発は『人類との相性が極めて良い』開発モデルということです。

アジャイルの弱点

そんなアジャイルですが、ちゃんと弱点はあります（ちゃんと？）。

・終わりがない
OSやアプリのアップデートに終わりが無いように、アジャイル開発に終わりはありません。ある程度の完成はあっても必ず『ここ直したいな』というのが出てきます。必ずです。状況が変われば必要な機能も変わります。

・総予算が分からない
終わりがないということは、システムが完成するまでの期間や金額も最初によく分からないということです。果たして完成するのかすら分かりません（対策はありますよ）。

・相性の問題が大きい
顧客と開発者の相性が悪いとうまくいきません。日常的に頻繁にコミュニケーションを取って進めていくモデルなので、仲が悪くなるとうまく進みません。

どちらかだけ一生懸命でもダメで、両者の協力が不可欠です。『依頼したらあとは待ってれば完成する』と顧客が思っていたり『言われたことだけやってればいい』と開発者が思っていたりすれば出来上がりません。

弱点への処方箋

・終わりを決めておく
最初に、最低限必要な、本当にミニマムな部分だけをウォーターフォール的に設計して開発し、それに肉付けすることを目指します。そうすれば一応の『区切り』は出来ます。開発を『フェーズ』で分けるということもよくします。

・上限を決めておく
例えば1年で3,000万円までという上限を決めます。あるいは2ヶ月で300万円でもいいですが、上限を決めます。その中でやれることをやる事になります。大抵は作っていくうちに欲が出て（またはアイディアが出て）開発規模は膨らみますが、それはフェーズ2で行うことにします。

・相手が変わっても問題ない作り方をする
相性が悪いのはどうしようもないので、フェーズ1などの区切りで契約を終了して他の開発者に依頼し直す事も考慮します。そのためには各プログラムの独立性が重要です。各クラスが疎結合になっており、互いに悪影響を及ぼさない作りになっていないと他人が書いたコードを引き継ぐのは困難になります。

きちんとモジュール化されており、各クラスのドキュメントが揃っていれば開発者を変えても短い移行期間で済みます。複雑に絡み合ったシステムでドキュメントが無いと解析だけで工数を取られます。

『オブジェクトのカプセル化』と言いますが、細部が全体に影響を与えない仕組みで作っておかないと大変な事になります（クラスはこういう問題を解決する処方箋です）。

その辺もキチンと気を使える開発者を選び、顧客もコード構造の良し悪しくらいは理解しておきましょう。

無知な顧客は開発会社から見たら『いいカモ』です。

最高の処方箋

アジャイル開発で最高の状況は、

『ユーザー＝開発者』

です。

自分が欲しいシステムを自分で作るのが最高です。

そりゃそうですよね。自分と自分の相性は完璧。コミュニケーションコストはゼロです。期間や予算の制限なく自分が欲しいものを自分で作れます。

多少モジュール化に失敗しても自分が書いたコードならメンテナンス可能です。

ただ、これが業務システムだと属人性が高くなりすぎるので、会社としては問題になります。

一人で作ったシステムが会社の運命を握ってしまうのはあまり良くない。

なので、通常はチームで作ると良いでしょう。

何人かで『システム開発部』みたいなものを組織して開発すると属人性が減ります。

人数が増えればコミュニケーションコストは増えますがリスクヘッジになります。

内製化していきましょう

一昔前は企業が内部に開発部隊を持ってシステムを内製するのが普通でした。

それがコストダウンの煽りで外注するようになると、様々な『動かないシステム問題』が生まれました。

外注は上手くいかないんです。開発と顧客が運命共同体でなくてはならないからです。

そして今、プログラミングはかつてないほど簡単になってきています。

誰もがシステム開発を出来る時代です。

少人数で大きな成果を出すことも可能ですから、昔ほど内製化のコストは高くありません。

（少人数スタートアップでアプリやなんやらを作っている時代ですよ？）

外注に出すより良いものを自分たちで作ったほうが安く良いものが出来ます。

もう外注に出すのはやめて自分たちで作っていきましょう。それが今後のトレンドになります。

私たちは、自分たちで開発を行いたい方を応援しています。

3月もiPhoneアプリ開発の無料体験講座を行いますので、是非いらしてください。

http://stepapp.jp/2017/11/28/taiken/

なんか宣伝みたいなオチになっちゃってすみません(´･ω･｀)