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

Solution("r.a.k.u."の特徴と効果)

"r.a.k.u."の特徴と効果

「定期的に」「定量のサービスを」「定額で」届ける

 変化の激しい環境下において、ビジネスの成長に沿った、システムが得られます。
ムダなコストや余計なモノを作らなくて良くなり、その結果、適正なITコストで適切なシステムが構築されます。
情報システムにおける業務の平準化を図ります。

「定期的に」「定量のサービスを」「定額で」届ける

トップへ戻る

システムありきではなく、ビジネスを中心としたアプローチ
ビジネスからシステムまでのシームレスなサービス

 システムを作ることを目的とせず、ビジネスの価値を最大化するためのアプローチを提供します。
「ビジネス領域とシステム領域」、「コンサルタントとSE」という形で業務を分断するのは効率的ではありません。
本サービスでは、ビジネス領域、アプリケーション領域を総合的・包括的にワンストップのサービスとして提供することで、シームレスで効果的なサービスを提供します。

システムありきではなく、ビジネスを中心としたアプローチ

「Think Big」「Act Small」「Quick Benefit」

決まったものを作るのではなく、お客様とともにビジネスから考える『仮説検証の提案型』のアプローチをとります。

『仮説検証の提案型』のアプローチ

BPOA(Business Process Oriented Approach)

システムありきではなく、ビジネスを中心としたアプローチ

システムありきではなく、ビジネスを中心としたアプローチ

トップへ戻る

一切のムダを省いた手法

「決めない」「作らない」「書かない」「終わりにしない」「依存しない」を方針として、一切のムダを省いた超高速の開発をビジネスの成長にあわせて仮説検証を行いながらビジネスとシステムを適切なコストで洗練化します。

1.決めない
  • 要件定義期間に要件は決まらない。
  • システムを開発しながら要件を開発する。

どんなに素晴らしい要求が開発できたとしても、それが実現化されて、効果を出さなければ意味がありません。また、その要件が実現するまでに時間がかかっては、要件が陳腐化してしまいます。 そして、要求・要件は常に変化、進化を続けます。このような状況下で、完璧な要件を定義する(できる)必要はあるのでしょうか。むしろ、それは非常に難しいことです。

要求は時間とともに変化し続ける

要求は時間とともに変化し続ける。

要件は、「きまらない」「変化する」ので、全てを決める必要ない

要件は、「きまらない」「変化する」ので、全てを決める必要ない

2.作らない
  • 設計書を作る前に、システムを作る。
  • 設計書は後から出力する。

要件は常に変化する。要件がかわれば、設計書も修正が必要になります。
要件と設計書とシステムの整合性をとるのは至難の技、その労力は図り知れません。

r.a.k.u.のアプローチは、動いているものが「正」と考え、実際に稼働しているシステムから、
設計書は自動生成します。

動いてるものが「正」



作ったものから設計書は自動生成

3.書かない
  • コードを書かず、部品組み立て型で開発。
  • プログラミングが必要な複雑な固有処理は別管理、変更時のシステム全体への影響を抑える。

要件は常に変化する。要件がかわれば、設計書も修正が必要になります。
要件と設計書とシステムの整合性をとるのは至難の技、その労力は図り知れません。

ソースコードは極力書かない

ソースコードは極力書かない

4.終わりにしない
  • 目的はプロジェクト終了ではなく、ビジネスの成長。
  • ビジネスの動きに沿って仮説検証を繰り返す真のアジャイル&リーン。

プロジェクトの終了を終わりとしない

ビジネスの成長に直結したシステムを提供し続ける

5.依存しない
  • ベンダ、技術、システムに依存しない。
  • ビジネスに必要なのはスーパープログラマではない。
  • ビジネスの成長に貢献する継続的に可能な仕組みの確立が必要。
技術に依存しない
特定の技術に依存しません。
技術は常に変化していきます。特定の技術に依存しすぎないようにすることが重要です。
ベンダーに依存しない
ベンダーへの丸投げ体質からの脱却します。
ユーザー側で主体的に仕様を抑え、コントロールできるようにすることが必要です。
パッケージに依存しない
パッケージありきのシステム開発せず、パッケージを導入する場合は、必要最低限なものにとどめ、カスタマイズには最新の注意を払うことがが重要です。
テンプレート、リファレンスを信じない
テンプレートやリファレンスに頼り過ぎるのは、企業の競争力を落とすことになりかねません。 ビジネスプロセス、システムを高速に見直し、洗練することで、他の企業に存在しない、プロセスやビジネスモデルを構築し、競争力が発揮できるようにすることが理想です。

トップへ戻る

変化を前提とした仮説検証

変化を前提としたアプローチをとるため、開発の途中でも、開発が終わったあとでも、極力変更を受け入れます。

変化を前提とした仮説検証

すぐに、効果と結果を出し、環境の変化に対し臨機応変に対応しながらビジネスの成長に直結すシステムを提供します。

トップへ戻る

ユーザーイニシアチブなシステムの導入

エンドユーザー、情報システム部の橋渡しをし、ユーザーがイニシアチブをもったシステムの導入を支援します。

ベンダーからパートナーへ
システム開発からサービス提供へ

ベンダーからパートナーへ<br>システム開発からサービス提供へ

ユーザーイニシアチブなシステムの導入

トップへ戻る

r.a.k.u.のサービス一覧