IT企画立案サービス〜事業に必要なITを、ITプランナーが設計してデザインします〜

Tweet

Pocket

IT企画立案サービス

IT企画とは、「経営もしくは業務課題を解決するために必要な、業務や事業をより良くするためのITシステムの企画立案」を指しています。

「ITで新しい事業を展開したい」「ITで業務を改善したい」というお客様に対して、現状の経営資源にある「情報」をどうやって収集・蓄積し、「どういう仕組みをITで構築すれば」課題を解決できるかのロードマップを立案するもので、我々はそういったロールを行う人材を「ITプランナー」と命名し、サービスを展開しています。

IT企画のロードマップ

これが当社の考える、IT企画を行う道筋です。

IT企画の対象になるのはソフトウェアです。難しいのは、現物がそこにないこと。注文住宅と同じで、平面図・立体図・間取り・パース等を駆使してイメージでお互いを理解するしか無く、文章や図解ベースのドキュメントで表現するのは限界があります。この溝を埋めるためには、一定のガイドライン(方法論)を使うべきと考え、独自のガイドラインを策定しました。

フェーズ1. コンセプトワーク

最初に行うべきは、なぜこのITを求めているのか、手に入れる必要があるのかを的確に示す「コンセプト」の策定です。

コンセプトを簡単に言えば、「今はまだわからない未知の良さを表現している、20文字程度の言葉」です。ちゃんと言葉で明文化する必要があります。絵ではだめです。

上記のマトリックスを見て下さい。左から右上に進んでいくのがコンセプトワークです。すでにわかっていて、手に入れたいものが見えているなら、コンセプトがどうこうじゃないですよね。手段を決めるだけの話になります。場合によっては、買ってくれば良いだけになることもあるでしょう。IT企画が目指す所は「既に知っているものではなく、未知の良いこと」であるはずです。未知ですから、当然言語化されていない。それを言語化するために、コンセプトを決める必要があります。

• わかっている(認識できている)か、わからない(認識できていない)か。
• 手放したいのか、手に入れたいのか。

この2軸で整理すれば、コンセプトが策定できるはずです。未知の良さを表現する道順としては、大きく２つあります。実際にはこの２つを行ったり来たりすることが多いでしょう。

1. 課題を出し合い、依存関係を整理して構造を作る
2. あるべき戦略から始める

また、「皆がハッピーになる」とか「○○化を実現する」と言った具体的なシーンがイメージできないコンセプトはNGです。どうとでも解釈されてしまい、企画の骨子がブレてしまうからです。YouTubeは当初「動画のFlickr(写真共有サービス)」というコンセプトで始まったそうです。DropBoxは「フォルダに入れるだけでどの端末でも共有できる」ですね。プロダクト系の場合は、コアとなる利用シーンをコンセプトにするとわかりやすいかもしれません。

業務系の場合はもう少し複雑です。いろんな立場の人達が絡みあうため、どうしても○○化を実現するみたいな言葉を使いたくなってしまいます。解決したい問題が多岐にわたるからです。「明確な(時には漠然とした)不安／不満」と「これが実現できたらという願望」の２つをコアに、コンセプトにできそうな言葉を作り出しましょう。「どこでも、どの端末でも仕事ができるようにする」とか「受発注業務の手作業をゼロにする」とか、可能であればこういう言葉が望ましいです。

フェーズ2. 施策抽出

施策抽出というのは、目指すべきゴールと現在地の距離を図って、ゴールから逆算してどういう手順で進めていけば欲しいITが手に入るのか良いのかを決めていきます。端的にはAsIs・ToBeのギャップをどう埋めるでして、大まかな流れは決まっています。

1. 今回改善したい業務の流れを整理する
2. 各々の業務でどんな作業を行っているかを整理する
3. どんな機能を持つITがあれば望む変革ができるのかを吟味する
4. 機能一覧を整理して全体像をまとめる

この流れを整理するフォーマットとして一番わかり易いのが、ユーザーストーリーマッピングです。

IT企画の目的はどんな機能を持ってどういう変化が促すことが可能なITがあればよいかをデザインすることで、あーでもないこーでもないと書類をこねくり回すよりも、ポストイットに全員で向かうほうが議論も進むし検討内容も濃くなります。ライブ感重要です。

フェーズ3. 仮説検証

ここからは「どうやって手に入れるのか」のフェーズに入ります。欲しいITを手に入れる方法は下記の4つです。

1. パッケージ製品、ASP、SaaSを活用する
2. アプリを作る製品やサービスを活用して、DIYする
3. オーダーメイドで新規にシステムを作ってもらう
4. 既存システムの改修・カスタマイズを行う

業務の独自性・システム適用範囲・現状のITインフラ・人材リソースなどの勘案して決めることになりますが、大きく分けると既成品かオリジナルかのどちらかが大きな分岐点です。インフラやツール系(メール・スケジュール・ファイル共有・社内サイト構築・セキュリティ等)のIT系の企画に関しては、オリジナルで何かを作ることは少ないでしょう。

問題は業務システムです。パッケージやSaaSは広く普遍的な問題解決(どの会社でも同じような手法で管理している業務)を対象にしているため、ある一定のラインを超えると必ずアンマッチな要素が出てきます。パッケージやSaaSの活用が決まっている場合は、無料お試しやデモ等で理解を深めていくのが良いでしょう。

アプリを作る製品やサービスの代表例は、Microsoft Access、FileMaker、Kintoneなどです。操作画面をまず作って、その操作に該当するデータを保存できるもので、小規模(10画面程度)で収まるものであれば、この選択肢も有用です。内部で知見のある技術を使うのは良いですが、属人化する恐れが高いので注意が必要です。DIYの場合は、必ずある程度の市場シェアがあるツールを使って下さい。

オーダーメイドで何かを作る場合は注文住宅と同じ考えです。作ってから立て直せは無理ですので、パース(建物の外観や室内の空間のイメージが分かりやすいように、立体的に描いた図)を使って完成形を共有します。パース図に該当するものが、試作品(プロトタイプ)です。住んでみないとわからないでは駄目ですが、使ってみないとわからないのがITシステムの難しい所。そのため、本当に前段のフェーズで抽出した機能が有用なのか、使い方に問題はないかを検証する必要があります。

というのも、オーダーメイドの場合は、設計工程が多岐にわたるからです。それについては、次のフェーズで説明します。

フェーズ4. 要件定義

設計工程もいよいよ大詰めです。オーダーメイドの場合は必ずこの要件定義という工程が必要です。

コンセプトワークや施策抽出の前段のフェーズは、あくまでも「こういう事を叶えたい」という要望であり、施策抽出で要望を成し遂げるための機能の整理を行い、要求事項(やらないとだめなこと)に落とし込みました。

この要件定義という工程は、その要求事項を満たすためのシステムをどうやって構築するかを決める手順です。それらは以下の3つの要素に分解できます。

1. UI(画面)
2. データ
3. 機能(UIとデータをつなぐもの)

ユーザーがどの画面を操作して、どういったアクションを起こすと、どんなデータが送信され、どういうデータが生成(もしくは出力)されたら良いのか、というのを１つ１つ指を折って決めていくフェーズです。ユーザーのUI操作とデータの操作を紐づけていくことで、どういうプログラムを書けばよいかを決めていきます。単純化すれば、プログラムを書き始めることが出来るまでの前準備が要件定義であり、厳密には機能要件と言われています。別途非機能要件という、システムの可動性・パフォーマンス・運用体制等を決めるフェーズもありますが、ここでは割愛します。

この要件定義の過程は、未体験の方ですと嫌になるほど細かく物事を詰めていく作業になります。業務で行うオペレーションを的確にプログラムに落としこむために、業務のやり方を標準化する必要があります。プログラムは空気を読まないので、条件をつけて動作を規定しなければならないからです。例外は原則許されないと思って下さい。A社の場合は別途この判断が〜などと顧客別のローカルルールを反映し始めるとプログラムがどんどん肥大化してしまいます。

そういった塩梅の調整なども含め、やっとシステムの設計(これも厳密には外部設計と言われる工程になりますが)が完了し、注文住宅を立てるための工程表が出来上がるというわけです。

以上が、IT企画の立て方の骨子となります。皆様の現場でのやり方で不足していたな・この整理は参考になるなというポイントがあれば幸いです。