もう大きいシステムを作ることはやめていいんじゃないか
私たちが日々行っているシステム開発では、年々開発にかけることのできる時間や予算が少なくなっていることと思います。昔であれば半年や 1 年といった時間をかけ、要件を聞き出し仕様を決め、そこから開発・試験を行いリリースする、俗に言うウォーターフォールの流れでシステムを作り上げることができていました。
現在ではそこまでの時間をかけることが、顧客側・開発側双方の都合もあり難しくなっています。スパイラルモデルやアジャイル開発など、細かくリリースを行い都度方向性を調整する方式が、珍しくなくなってきたことからもわかります。
IT に関わるもののほとんどの要素において、ライフサイクルが短くなった今では、これまでと同様の方法で進めても、成功する割合は非常に少なくなっています。しかしそれでも開発方法を変更したり、予算は増やさなくとも時間だけは増やすなどといった、何かしらの対策を行えている企業は、まだまだ少数派のように感じます。
「現場はそこまで時間はなく、どうあるべきかはわからない」
現場側や現場に近い立ち位置にいる人であれば、要件を明確にし、時間や予算を十分に確保してから開発に取り掛かることが、どれだけ現実に即していないかは体感されているでしょう。大まかには叶えたい要件らしきものをイメージできますが、細かい箇所に至っては言葉通り「やってみなければ」分からないことが多いです。
開発側としては、要件を明確にすることができれば、その後の工程での戻りを減らすことができます。大規模案件のように、そうしなくては開発を進めることすらままならないケースもありますし、過去の経験を持てば持つほど要件定義が非常に重要なもの、というある種の固定観念になってしまっている人もいるでしょう。
現場側と開発側、双方の思惑が衝突してしまうと殆どの場合において、残念な結果になってしまいます。それは参画した人達にとっても、またシステム対応を決断した会社にとっても何一つ喜ばしいことはありません。
そのような残念な結果を、できる限り減らすにはどうすればよいのでしょうか。
一つ考えられるのは、開発領域を可能な限り小さく収めることだと思います。開発作業が失敗する境目、というのはどこかに存在するのは間違いないのですが、その位置は様々な条件によって変動します。優れたメンバーが集い現場側と一致団結できるような場合と、一般的なレベルのメンバーとあまり協力的でない現場側な場合とでは、開発をうまく進めることのできるラインは大きくズレがあります。
ズレを明確にできる基準は現在私が知る限り存在しません。スキルの評価と同様に、数値化できるものではまだまだ到達していないためです。それであればいっそのこと、どのようなケースでも実施することができるところまでを、開発可能な領域としてしまい、複雑なシステムを作ることは放棄してしまうというのはどうでしょうか。
領域が小さくなればなるほど、開発が失敗する割合は減少できます。人一人が扱うことのできる範囲は、その人その人の経験や能力に左右されるとはいえ、どこかに限度があります。そしてその限度は、目に見えるものではないのでどうしても感覚に頼らざるを得ません。
領域を小さく狭めるという事は、一度に提供する機能を少数に限定することです。少数機能に限定できれば、開発もスムーズに行う事がまだ現実的に思えてきます。現場側としても、考えるべき範囲が狭くできるのですから、叶えたいことをより明確にできるのではないでしょうか。
そうすることでお互いに良い方向へ向かうことができるのですが、ここで懸念されるのが、以前に全体最適と個別最適の話題でも扱ったもので、ミニマムなシステムが乱立す露ことによる混沌とした状態です。
しかし、ここまでに書いたように領域を広げてしまう事こそが、システム開発を失敗させる最も大きな要因の一つです。失敗することと比較すると、個別最適による乱立した状態はまだマシだと思えます。
だからといって全く何も考えないのであれば、問題を先回しにしていることとそれほど違いはありません。何かしらの方法を用意したうえで、小さい領域に限った問題解決を行っていく必要があるかと思います。
今の時点で私が考えるのは、作成する機能は必ず別システムから利用可能とする、部品もしくはコンポーネントとして利用可能な機能を提供する形を採用することです。コードレベルでの話ではなく、あくまでも機能レベルとして再利用可能であることを絶対条件とするのです。
私が個人的に気に入っているものとして、Microsoft Azure の機能で提供されている LogicApps というものがあります。また、.NET でも WF という組み合わせて利用する事を前提とした仕組みが、すでに用意されています。これら、既存の機能を組み合わせ利用する仕組みを大前提としておけば、多くの機能が提供されていたとしても乱立を防ぐことは十分に可能なのではないでしょうか。
複雑に発達を遂げるのはシステムだけではありません。現場側で携わる業務それ自体も、過去と比較すると複雑に発達しています。このような状況であることを考えると、システム開発やそこに出てくる多くの要素、全てのものに対する考え方を一度クリアにしてみるのも必要なのではないか、私はそのように考えます。