r.a.k.u. Rapid Approach by Knowledge use

Solution("r.a.k.u."とは?)

""r.a.k.u."’(Rapid Approach by Knowledge Use)とは?"

 "r.a.k.u."は、「継続的な業務の洗練化を実現する、新しいアプローチのコンセプト」です。

 情報システムが中核をなすようになったビジネス環境において、ビジネスとシステムの間のギャップ解消するためのソリューションが「r.a.k.u.(rapid approach by knowledge use)」です。
 ビジネスとシステムのギャップには、「時間のギャップ」「品質のギャップ」「コストのギャップ」「変化へのギャップ(柔軟性のギャップ)」「要求のギャップ」「人的リソースのギャップ」「開発と運用のギャップ(DevOps)」が存在すると考えています。これらのギャップが無駄な情報システムに対する投資を産み出しています。

「時間のギャップ」

 従来のSIerによる情報システムの開発方法は、システムありきの導入・構築です。既存システムをベースにしたシステム単位での再構築となり、システム化の範囲が拡大し、開発の規模(SIerが見積もる工数や人月、FP等)も拡大する傾向があります。開発規模が大きくなればなるほど、見積りの誤差も大きくなってきます。
 この傾向がプロジェクトの期間を長期化させ、プロジェクトが終了した時点では、完成したシステムの陳腐化が始まることも少なくありません。また、システムが本稼働した時は、要件定義時とビジネスや環境が変化し、システムがビジネスに全くあっていないことも少なくありません。

 ”r.a.k.u.”はこの「時間のギャップ」を最小化します。
 システムありきではなく、ビジネス・業務(プロセス)を中心に考えることにより、ビジネス上において必要なプロセスを「最少実行可能な業務のかたまり」(MVPI: Minimum Viable Process Instance)に分割し、その業務のかたまり毎にシステムを提供していきます。
 また、一切のムダを省いた超高速開発手法と、ビジネス要求についての変更を前提とした、無駄な成果物を作成せず価値あるサービスを提供する思想により、いつでも変更可能なシステム構造をとりビジネスとシステムの時間のギャップを最小化します。

「品質のギャップ」

 従来型の請負開発では、SIer側の都合から、システム規模を大きくし、大量の機能を一度に提供するようなウォーターフォール型の流れ作業が通常化しています。要件定義ー設計ー開発ーテストの中で、いかにそのコストを縮小化して利益を確保するかという考え方により、開発等は、二次請、三次請、オフショアといった低コスト化を図るビジネスモデルが主流です。そのため関係者間のコミュニケーションミスが発生し、品質のバラツキやテストのフェーズになっての大量のバグ、仕様もれ、仕様の誤りによる手戻りが発生することが少なくありません。開発者個々人の技術力のバラツキによるところも影響し、属人的なプログラミングやプログラマ個人の癖が出ることによって、均一なレベルでの品質を保つことが困難なこともあります。これが、品質のギャップとなって現れます。

 "r.a.k.u."では、前述のとおり、ビジネス・業務を中心に考えることにより、システム化の単位を小さくし、変化に対応しながらシステム化を進めていきます。
 またモデルから動くアプリケーションを作成しプログラムは極力書かないことを方針とするために、品質のばらつきを低減します。これによりスーパープログラマに頼る必要もなくなります。
 設計書や仕様書についても、「動いているものが正」であるという方針のもと、動いているシステムから設計書を生成することにより、仕様変更の際の、設計書への反映漏れ等がなくなると同時に、システム変更の度に設計書を記述する、レビューする等の作業工数を大幅に削減することができます。

 "r.a.k.u."では、1週間という短いサイクルで仕様を確認し、変化を前提としながらシステムを作り上げて行くため、手戻りや仕様の間違い等も随時確認できます。
 また、"r.a.k.u."は最初から移行を開始します。はじめに新旧のシステムで使用しているデータの種類、持ち方等をきちんと把握し、業務のかたまり単位で移行を開始することによって、設計や開発の品質が格段に向上します。

「変化への柔軟性のギャップ」

 従来の開発手法においては、要件定義で決まったもの以外は開発せず、開発開始後の変更は避けることが原則です。
 一度、要件定義で決まった要件を変更するためには、別途プロジェクトを立ち上げたり、要件の確認、再見積、変更の影響調査等が必要となります。設計書を書き直し、お客様のレビュー・承認を受けた後開発・テストを行いリリースする等、工数も費用もかかります。
 システム変更にこれだけの多くの時間とコストを要すると、ビジネスを取り巻く環境の変化に柔軟に対応することは困難であり、企業競争力の低下を招きかねません。

 "r.a.k.u." は、企業の仮想情報システム部門としてのビジネスパートナーシップをとるため、変化に対して常にフットワークの軽い対応が可能です。一切のムダを省いた超高速のアプローチ、開発と運用の壁をとりはらった、安定感のあるシステムの供給を実現します。
 私たちは、コンサルタントでもなく、SIerでもなく、お客様とともにビジネスを成長していく、ビジネスパートナーであるということを信念としています。企業とともにビジネスの成長に寄与していくビジネスパートナーモデルであるために、常に変化を前提としたシステム化手法を提供します。

「要求ギャップ」

 ユーザー企業が要求を決めてくれないというSIer側の不満は多く見受けられます。しかし、システムへの要求をはじめにすべて洗い出し、決定することは至難の業です。
 要求が必ず変化します。昨今のビジネス環境は、従来は変化が少なかった領域に対しても非常に速いスピードで変化しています。そのような情報化社会において、ビジネスの変化に対してシステムが柔軟に対応できなくては、情報システムがビジネスの成長の足枷となってしまいます。変化へのスピードに業務・システムともに対応できる企業こそが、他企業との競争に勝ち抜いていくことができます。
 現在のビジネス環境は不確定な要素が多く、決めた要件をそのまま作ったとしても、その要件が正しいかは誰も分かりません(その時点では正しかったとしても直ぐに変わります)。さらに、ウォーターフォール開発手法における、要件定義や設計のフェーズは、全体の2、3割を占めます。そこで決めない限り次の工程に進めないとともに、決めきれないために、要件定義にかける時間も増えていきます。そして、その間もビジネス環境は変化をしています。
 企業が情報システムに対して、間違いのない、変わらない要件があるとすれば、「いつでも環境の変化に対応可能なシステムにしてくれ!」ということなのです。

 "r.a.k.u." は、従来の「要件定義」をしません。ある程度の大枠の要求をもとに、要求提案という形で、システムを作りながらお客様とともに練り上げ、変化を前提としての設計・開発を実施するため、開発の途中やリリース後においても変更可能とします。この方針によってビジネスの成長に沿って成長するシステムの構築が可能となります。

「コストのギャップ」

 要求が常に変化をすることを踏まえると、今までの開発手法やプロジェクト構造では、変化に対応しきれません。決められた要求を、決められた期間で開発するシステムであれば、決まったコストで構築可能かもしれません。
 しかし、昨今のようにビジネス環境の変化のスピードが加速し、将来の予測が不確定・不確実である環境では、ムダなシステム投資が発生する可能性が高くなります。

 "r.a.k.u." は、ビジネス・業務の効率化の優先順位をMVPI(Minimum Viable Process Instance:最小実行可能な業務のかたまり)という単位でつけることによって、ビジネス上必要な時期に必要な業務プロセス改善を行っていくため、不確定な環境下においても、ビジネス状況に合った業務プロセスとシステム開発が実現可能となります。それによってムダな投資を限りなく低減し、継続的なローコストオペレーションを実現できます。

「人的リソースのギャップ」

 システムありきの開発では、システム開発のプロジェクトが大規模化し、プロジェクトに関わるステークホルダーが増加します。そのため、そのプロジェクト専任になったり、通常の業務に支障をきたしたり、システム開発のために多くの時間やコスト、作業負荷を裂くことになります。(ただし、その裂いた時間に比例して良いシステムができるとは限りません)プロジェクトに関わる人数(ステークホルダー)が増えれば、それをマネジメントすることは容易ではなくなります。さらにステークホルダーが増えれば、プロジェクトに対する抵抗勢力も増加します。

 "r.a.k.u."で は、小さなMVPI(最小実行可能な業務のかたまり)という単位で実装して行くため、業務プロセスに関わるお客様の人的リソース(担当者:例えば経理担当者等)の投入が、その期間だけの作業負荷ですみます。
 また、ビッグバン的にシステムや業務の変更をせず、小さな業務プロセスのかたまり(MVPI)で、小さな範囲のシステムの変化ですむため、お客様の中で生じる変化への適応も少しずつ進み、変化のマネジメント(チェンジマネジメント)がより軽い負荷や抵抗で実現しやすくなります。

「DevOpsのギャップ(開発と運用のギャップ)」

 DevOpsとは、「Development(開発)」と「Operation(運用)」を組み合わせた言葉で、開発と運用が共に協力し合って、短期間で完成度の高い企業システムをつくり上げていく手法を指します。リーン・スタートアップと同様に、開発と運用と評価を短いサイクルで繰り返し、新規のサービスを少ない投資で素早く立ち上げ、品質を高めることでビジネスの機動力を強化できます。
 しかし、開発チームと運用チームの間にはギャップが生じがちです。
 現在のSIerのサービスは、一定の期間に大量の人的リソースを投入し、開発、納品します。運用フェーズになると、開発したチームは引き上げ、運用・保守チームに切り替わります。ここで、開発と運用の分断が発生します。
 運用・保守を担当するチームは、数年後のシステム更改時に、設計・開発情報や開発時の業務状況を把握しておらず、お客様に対して最適なシステム提案ができないことも少なくありません。

 "r.a.k.u." は、SDLC(Software Development Life Cycle)を劇的に進化させます。開発チームと運用チームという分離をせず、小さなリリースを繰り返すことによって、開発と運用の壁を取りはらい、そのギャップを最小化し安定したシステムの供給を実現します。さらに、r.a.k.u.では、コンサルティング、システム開発の領域も分断しません。

トップへ戻る

"r.a.k.u."の方針

 "r.a.k.u." は、「継続的な業務の洗練化」を実現するために、ビジネスとシステムの間に存在するギャップを最小化し、システムを起点とするのではなく、ビジネスを中心に考え、ビジネスとシステムをシームレスにつなぐ価値あるサービスを「定期的に」「定額で」届けます。

"r.a.k.u."は以下のことを方針とし、ビジネスの成長に直結するサービスを継続的に提供します。

  • 「定期的に」「定量のサービスを」「定額で」届ける
  • システムありきではなく、ビジネスを中心としたアプローチ
  • 一切のムダを省いた手法
  • 変化を前提とした仮説検証
  • ユーザーイニシアチブなシステムの導入

トップへ戻る

r.a.k.u.の背景