ITコンサルティングでのAI活用術

ITコンサルティングに、そもそもAIは必要なのか

ITコンサルティングのAI活用が割に合うかどうかは、案件ごとの業務を二つの側から見ると判断できます。その作業を年に何件こなしているか。そして、そこで一つ取り違えたとき、費用や工期として誰が被るかです。

片方だけ大きい業務に手を入れても、労力に見合う変化は起きません。 両方が大きい業務 から順に見ていくのが現実的です。

ITコンサルティングでこの二つが両方大きいのは、書類の形が決まっている業務です。提案書と契約書の下書きは案件のたびに起こし直しますし、支援範囲や検収の条件を書き損じれば、追加費用を自社が被ります。

RFPの要求項目の洗い出しも、各社の提案を評価基準に沿って読み比べる作業も、抜けが選定のやり直しに直結します。

一方、最終的にどのベンダーに決めるかの意思決定は、AIに寄せてはいけない業務です。点差が小さいとき決め手になるのは、クライアントの情報システム部が何人で運用を回せるか、担当役員が過去にどの失敗を経験しているかという、 点数に載らない事情 だからです。

この線引きは会社ごとに、さらに案件の種類ごとに動きます。戦略の立案が中心の会社と、導入後の運用まで抱える会社とでは、繰り返しの多い工程が違うからです。自社のどの工程にどんな作業が集まっているのかを、一度分解してみる必要があります。次章でその分け方を示します。

提案・契約から効果測定まで、負荷が大きいのはどの工程か

ITコンサルティングの案件は、引き合いから稼働後の報告まで一方向に進みます。工程に切り分けて眺めると、書類の形が決まっているところと、相手の事情で中身が変わるところの差が見えてきます。

導入支援・PMOに、人の時間と神経がいちばん集まります。理由は作業量ではなく、コンサルタントが 決裁権を持たないまま三者の真ん中に立つ ことにあります。

仕様の変更をベンダーが追加費用と見るか、クライアントが要求範囲の内と見るかで、話が止まります。この手の論点は、コンサルタントが決められる話ではありません。それでも課題一覧の期日は迫るので、誰に決めてもらうかを見極め、判断に要る資料をそろえて持ち込む往復が生まれます。

時間を取られているのは、 この往復の準備 です。会議のたびに、前回どこまで決まったか、誰が持ち帰ったかを議事録から拾い直し、課題一覧に書き写す作業が挟まります。

ここが整うと、RFPで書いた要求項目と、いま揉めている論点が結びつき、どの要求が未決のまま残っているのかを会議の場で確かめられます。

極小と置いた課題の優先度付けは、どの課題から手をつけるかを経営層と握る場です。同じ課題一覧を前にしても、着手順は、予算の付き方や部門長どうしの力関係に左右されます。ここは人が場で判断する仕事として残ります。

ITコンサルティングで最初に取り組むべきAI活用、3つ

先に手をつけるのは、案件のたびに同じ形で戻ってきて、書き損じが後から金額や期日に響く書類です。次の3つは工程こそ別々ですが、どれもその条件に当てはまります。

提案書と契約書を、白紙から書き起こさない

起点は、案件管理の一覧で状態を「提案準備」に変えた時点です。提案・契約の工程にあたります。AIは、過去に受注した同じ領域の提案書と締結済みの契約書、初回の打ち合わせ記録を読み、支援範囲・成果物・検収条件・再委託の扱いを条項の形で書き出します。

書き出されたものは、契約審査の依頼一覧に1行として増え、下書き本体は文書作成ソフトの文書として案件の保管場所に残ります。これまでは似た案件を探して条項を切り貼りしていた作業が、挙がった条項からこの案件に合わないものを外す作業に変わります。

準委任と請負のどちらで受けるか 、検収の条件をどこに置くかは、案件を預かるマネージャーが決めます。再委託先を使う前提の条項が残っていないかは、契約審査の担当者が最後に確かめます。

要求項目の書き漏れを、RFPを出す前に見つける

RFP作成の工程は、要件整理の打ち合わせ記録を案件フォルダに保存した時点で動きます。AIが読むのは、その記録と、現行システムの機能一覧、自社が持つ要求項目の標準の一覧です。この一覧と照らして、記録に出てこない項目、たとえば移行データの範囲や保守の時間帯を拾い上げます。

出力は、表計算ソフトの要求項目一覧に増える行です。項目ごとに、 必須か任意かの区分 の候補と、その根拠になった打ち合わせの発言が並びます。前の案件のRFPを開いて章立てを写すところから始めていたのが、拾われた項目に過不足を入れる作業に変わります。

必須と任意の線引きは、クライアントの予算と稼働時期を知る担当コンサルタントが引き直します。拾われた項目をRFPに載せるかどうかの最終判断は、発注する側の情報システム部長が持ちます。

各社の提案を、同じ物差しで並べ直す

ベンダー選定の工程です。提出期限が過ぎ、各社の提案書が所定のフォルダにそろうと動きます。AIは、提案書一式に加えて、RFPの要求項目一覧と、選定委員会で先に決めた配点表を参照します。要求項目ごとに、各社が何と書いているか、書いていないかを抜き出します。

結果は、要求項目を縦、各社を横に取った比較表に戻ります。 空欄はそのまま空欄として残り 、どの社がどの要求に答えていないかが一目で分かります。各社の提案書を順に読み、差を手元の表に書き足していた段取りが、埋まった表を原文に当たって確かめる形になります。

空欄が、提案の欠落なのか、こちらの要求の書き方が曖昧だったせいなのかは、RFPを書いた担当コンサルタントが切り分けます。点を付けたあと、どの社に決めるかは選定委員会が決めます。

業務に組み込むまでの4ステップ

4ステップは、各社の提案を比較表に並べ直す例で追います。新しい仕組みを開発する話ではなく、提案書の置き場所と配点表と比較表をつなぐ作業です。

1. 使う情報がどこにあるかを決める

使う情報は3つで、いま別々の場所にあります。

• 各社の提案書：案件フォルダに届いた順で入っている
• 配点表：前回の選定を担当した人の手元にある
• 要求項目の一覧：要件定義の成果物として別にある

新しく作るものはありません 。3つを同じ場所に集め、要求項目を表の行の形に直すだけです。

2. 何をきっかけに動かすかを決める

きっかけは、提案書の提出期限が過ぎた時点に置きます。担当者が思い出して操作する形にすると、期限直後の問い合わせ対応に追われている間に後回しになり、結局は委員会の前夜に手で作ることになります。

3. 判断の基準を設定しておく

いちばん時間がかかるのがここです 。ベテランが提案書を読むときに無意識にやっている見分けを、文章にします。たとえば次のような基準です。

• 要求項目に触れていない提案は、減点ではなく「確認事項」として立てる
• 「対応可能」とだけの回答は、実現方法の記載がなければ満点を付けない
• 見積は初期費用で並べず、5年分の保守費を足した額で比較する

この手の決まりは、選定のたびに口頭で確かめ直しているはずです。一度書き出せば、次の案件でも評価の根拠の説明にも使えます。

4. 結果の戻り先と、確認する人を決める

戻り先は、選定委員会がそのまま開く比較表です。点と根拠の抜粋が入った状態で保存され、更新は担当者に業務チャットで届きます。

委員会の3営業日前に担当コンサルタントが空欄と低い点を原文と突き合わせ、直した跡を残して委員会に出します。

先に知っておきたい、つまずきやすい3か所

• 各社の提案書が図や表の中に要件を書き込んだ形で届くと、比較表の欄が埋まりません。 文字として読める形で提出してもらう よう、RFPの提出要領に書き添えておきます。それでも図で届いた分は、担当者が手で埋める前提とします。
• 契約書の下書きは、クライアント側の雛形を使う案件で外れます。自社の条項の並びを前提に書き出すため、先方の雛形に無い条項を足してしまいます。雛形を先方から受け取る案件かどうかを、 案件登録の時点で分けておきます 。
• 要求項目の標準の並びを更新したとき、必須と任意の区分の基準を直し忘れると、新しい項目がすべて任意として出ます。並びを直した人が基準も見直す、という担当をひとつにまとめます。

ITコンサルティングのAI活用は、どこから考えればいいか

最初に引いた線は、書類の形が決まっていて書き損じが金額に響く業務と、点数に載らない事情で決まる業務との間にありました。先に挙げた3つは、 どれも前者にあります 。案件が変わっても書類の形が変わらず、間違いが後から追加費用や選定のやり直しとして戻ってくるからです。

3つを同時に始める必要はありません。次に契約を結ぶ案件が近いなら提案書と契約書の下書きから、選定が控えているなら比較表からで十分です。どちらも、過去の提案書と配点表という、 すでに手元にあるものだけで始められます 。