IT化プロセス 1．企画化

IT活用ではプロセスが大切です。

私の場合、以下のプロセスで実施します。

1．企画化　→　2．IT化要件定義　→　3．調達　→　4．テスト　→　5．本番移行　→　6．目的の通り価値を出すようにもっていく

企画化について振り返ってみます。企画化では何をやるかというと、以下の事を要求者と共有します。

・目的とその背景

・範囲

・検討する選択肢の方向性

・運用条件

・予測コストとスケジュール案

まずは目的とその背景です。ここでの要点は、文章で目的を分かりやすく書くという事です。例えば仕事やプロジェクトの目的を上司に確認してもらう時、ここの目的があいまいだと上司は恐らく企画を承認しません。なぜ目的があいまいになるのか。それは自分の目的理解が曖昧なままになっているからです。

要求者はIT担当者に目的を伝える事をあまりしない傾向があります。どちらかというと目的より手法を伝えてくる場合が多いです。なぜか。それはシステム担当者をIT実現のプロとして見ているからです。だがら、IT手法の実現の可否を聞いてくるのです。例えば、この画面でこんな項目を追加したい。こんなレポートが作りたい。こんな検索条件を追加したい等です。システム担当者は大体すぐに判断できるので、出来ますとか出来ないと答えます。出来ないとしても、こうなら出来ますというような会話になる事も多いです。つまり、要求者とシステム担当者の会話は手法そのものを論じる内容になる事が多いです。

この状態だとシステム担当者は目的を明確化出来ません。その目的を要求者から明確に聞いていないのですから。自分の場合、目的を文章で表現しようとして、その表現が何か曖昧な表現に頼った文章になる場合があります。それは「まだ自分が目的と背景を明確に理解しない」という何よりの証拠です。この場合、依頼者に改めて業務目的を聞きます。そうすると、自分の言葉で明確に業務目的を文章にする事ができます。他人にも説明出来ます。

この目的の明確化をサボって、上司に企画書を報告すると、まず目的の部分で突っ込まれるでしょう。また、この目的の明確化をサボって、次工程に進むと、必ず後の工程で問題が起きます。例えば、作った後、要求者に「使えない」とか言われて、要求者から追加要望が沢山出てきます。この場合、要求者は実は追加要望を出していると思っていません。自分の業務目的が実現できる手法を伝えたはずなのに、それが実現できないシステムが納品されたと思っているからです。納品物に対して、ダメ出しをしてあげている位の感覚です。

一方、システム担当者からすると、言われた通りの事を実現しているのに追加要望が多くて困ると思うでしょう。

ここの認識の差は目的の共有不足からくると思っています。何かを創り上げていくとき、初めから完璧に全ての要件を明らかにする事は難しいです。多少の抜けや漏れが出来ます。ではこの多少の抜けや漏れにいつどうやって気づくのか。もしシステムの作り手側が業務目的を骨の髄まで、自分事として、骨身に染みる位理解しているとすると、作っている最中に、「ここはこういう機能が無いと困るよな」「これって必要だよな」「これって目的からすると不要では」と作っている最中に気づく事が出来ます。ここで作り手が、要求者に確認を行う事が出来ます。作り手側が分かりやすく論理的に、疑問に思った事を要求者に伝えると、要求者と一緒に良い回答を作り出す事が出来ます。このようにして、作っている過程で抜け・漏れを拾っていく事が出来ます。

これはシステム開発の例でお話しましたが、ちょっとした作業でも同じです。業務目的を理解しないまま、手法だけ聞いて、その実現まで見えていればいるほど、深いレベルでの目的の共有化を飛ばしてしまいがちだと思います。簡単な作業だと思って、対応したのに、なんだか何回もちょっとしたやり直しが来るような事はありませんか？その場合、受け手である自分の方が相手の目的を深いレベルで自分の言葉で明確に端的に語れる位に理解していないのが原因になっている事が多いと思います。

次に範囲を決めます。これは簡単な図を書いて、今回やる範囲を明確に示すと良いでしょう。言葉では伝わりにくい部分です。

更に検討する選択肢の方向性を決めておきます。自社開発するのか、パッケージを購入するのか、クラウドシステムを利用するのか、ある程度の当り付けを示しておきます。ここで重要なのが、決めつけすぎないという事です。システム担当者は実現手法がある程度見えている事が多いので、無意識的に手法の選択肢を狭めてしまう場合があります。性格や性質の異なる選択肢を三つ位挙げておくと良いと思います。決めつけすぎて、企画書を上司に報告すると、上司の視点から見ると、やや企画の価値が小さくこじんまりとして、パンチの弱い内容に映る可能性があります。作り手側といては、企画時は、要求者から言われた手法だけに拘る事なく、組織としてもっと価値が出せるような発想で、選択肢を広く考えても良いと思います。

今度は運用条件です。ここは目的の共有と同じくらい重要な点です。物事を成り立たせるには、必ず前提条件が必要です。例えば、この目的を達成する為にこういうやり方でやります。その運用条件として必ず、この項目がもれなく正しく入力されている事が必要です、というような事です。逆にいうと、その運用条件が満たされていない場合、この企画書で記載している目的は実現出来ませんという事になります。

目的を実現するには、その実現手法が必要になります。そしてその手法でやりたい事が成り立つ為には、前提条件が必要です。この運用条件もよく見逃されます。要求者との会話で中心的な話題は前述した通り、手法になりがちです。運用条件を明確化しておくことをサボると、目的の共有をサボった時と同様に後工程で問題が発生する事が多いです。

最後は予測コストとスケジュール案です。予測コストは選択肢によって変わりますが、見極めておく必要があります。根拠も記載しておいた方が良いです。これは後工程で重要になります。後工程で費用が膨らんでしまった時、なぜ自分の予測費用と差異ができたのか、確認する事が出来るからです。根拠を残しておけば、コストが膨らんできつつあるとき、「コストが増加する理由と自分の予測コストの根拠の何処に差があるのか」を考える事が出来るからです。根拠を残しておかなと、追加費用が必要になった時、自分でなぜ追加費用が追加なのか、当初の予測と何処が違っているのか、説明が出来なくなります。逆に説明が出来れば、追加費用の容認の判断も行いやすいです。

スケジュール案はあくまで案で良いと思います。その仕事だけやっているわけではなく、通常複数の仕事やプロジェクトがあると思います。複数の仕事を行う中で、優先度は日々、変わっていくからです。具体的には企画化やIT化の要件定義まではおおまか実現性の高いスケジュール案とします。なぜならその部分は自分達でやるからです。管理可能性が高いからです。一方、管理可能性が低い工程もあります。例えば、調達や開発作業を外部に依頼する場合、企画化の時点では、この部分は外部の方のスケジュールによって決まる部分もあります。従って、自分達よる管理可能性が低い部分については、「これ以降の工程のスケジュールは、他のプロジェクトとの優先度も考慮しながら、発注後に決まります。」というような説明を書いておくと良いと思います。

参考図書はありません。自分で自分なりのプロジェクト管理の手法を確立しました。参考に挙げたいとするなら、ITコーディネータの仕事のやり方は参考になります。自分も元ITコーディネータでした。