DXプロジェクトを始める「最初の一歩」をどう作るか
榊巻亮氏（以下、榊巻）：みなさん、こんにちは。今日は「企画の作り方、通し方」というセミナーを行っていきます。始める前に、声のトーンが大丈夫かとか、できればチャットに書き込みしていただけるととてもありがたいです。「いいね」を飛ばしてくださるの、非常に助かります。ありがとうございます。
感想もチャットで流していただけすると、我々としてはしゃべりやすいというか（笑）。ウェビナーは1人でしゃべっている感じになって孤独なので、非常にありがたいです。みなさんありがとうございます、大変助かります。
今日は僕とケンブリッジの営業マネージャーの堀之内の2人で話していこうと思っています。
堀之内幸氏（以下、堀之内）：営業のマネージャーをやっています、堀之内です。よろしくお願いいたします。
榊巻：よろしくお願いします。じゃあ、ここからお話しさせていただきたいと思います。ではみなさん、よろしくお願いします。
堀之内：お願いします。
榊巻：今日は「企画の作り方、通し方」ということで、DXのプロジェクトを始める時の、まさに「最初の一歩」をどうやって作っていくかというお話です。
なんでこの話をしているかというと、そもそもプロジェクトってすごく難しいですよね。みなさんすごく苦労されていて、「なんとかやらなきゃ」と考えてらっしゃると思います。
難度が高いプロジェクト遂行は最初が肝心
榊巻：その前の立ち上げのパートで、企画を作って、企画を通して、社内で承認を得られないと、そもそもプロジェクトを始められないじゃないですか。今日はそこの話がしたいんですよ。
プロジェクトを立ち上げるのはすごく難しいし、プロジェクトの立ち上げ方に失敗すると、そのあとがすごく難しい状況に追い込まれてしまうので、最初が大事ですよね。
我々ケンブリッジがプロジェクトをお手伝いする時に、とにかくこの立ち上げのパートのご相談に乗ることがすごく多くて。特に営業はそういうシーンに出会うんですよ。お客さんに相談されて、一緒に立ち上げ方を考えて、プロジェクトを興して、一緒にお手伝いする。
今日は、我々に貯まってきた知見を、少しでもみなさんにお伝えできると幸せなプロジェクトが増えるんじゃないかなと思っています。なので、終わった時に1つか2つ「ここに気をつけて企画を立ち上げよう」というものが、みなさんの中に残るといいなと思ってます。
アジェンダはこんな感じです。企画を作る5つのポイントと、通す4つのポイント、大きく2つのパートに分けてお話ししていきたいなと思います。
決裁者から怒られる……よくある失敗事例
榊巻：最初に、企画の失敗事例をちょっとおさらいしてみたいなと思います。我々がよく出会う失敗事例というか、企画で「うまくいかなかったな」という例を挙げてみます。企画を作る担当の方が、社内で「業務を標準化するプロジェクトをやりたいと思っています」と言うわけですね。そして、偉い人が応じてくれるわけです。
「確かに標準化をやったほうがいい気がするし、良いと言えば良いんだけれども、何のためにやるの？ 標準化できたら会社としてどのくらいメリットがあると思ってるの？」と、まっとうなことを聞かれています。
担当の方は「でも標準化できたほうがいいですし、もともとみなさんはずっと『標準化したい』と言っていたので、悲願の取り組みじゃないかと思っていまして……」「悲願というだけでGoは出せないよね。どのくらい価値がある取り組みなのかはっきりさせないといけないし、標準化って手段が目的化してるんじゃない？ もうちょっとちゃんと考えてよ」と言われて、怒られてしまうとか。
こういうケースもあります。我々の相対するお客さんは、「外部支援としてコンサルを使いたいです」という話をけっこうしてくださるんですが、「この規模のプロジェクトなら当然、外務の支援入れないと社内だけでは無理だよね」ということを考えながら言ってくれてるんですよね。
でも、偉い人はこんなふうに言うわけです。「それって価値に見合うの？ そもそも何にお金を払うのか、我が社にないものを補ってもらうためにお金を払って入ってもらうんだよね。それって何なの？」。
「価値と言われると、確かに価値に見合うのか微妙なので、相見積もりを取って一番安いところに出すような感じになりますかね。うちにないものというと、他社の事例。そうすると、同業他社の経験がある会社にお願いする感じになりますかね」というふうになってしまう。
（すると決裁者は）「一番安くて業界の知見がありそうなところね。まぁそうなるか……」という話になります。
立ち上げでコケないためにも企画書づくりが重要
榊巻：実はこの担当の方は、プロジェクトマネジメントの経験が不足していて、プロジェクトを引っ張るにはちょっと能力が足りないと思っていたので、二人三脚で一緒に走ってフォローしてくれるコンサルを入れたかった。しかし知見を提供してくれるコンサルしか入れられないな、となってしまうケースです。
そして（企画が）うまく立ち上がらない。こういうケースはあるあるだと思うんですが、こうならずにきちんと立ち上げられるようにしたいと思っています。
企画と言ってもいろいろあるし、各社によって通し方はたぶんバラバラだと思います。今日は、我々が「こうするとうまくいくよね」と考えているものを、いくつかポイントでお話しできるといいなと思ってます。
「こういう要素だったら取り入れられそう」「ここはちょっとうちには合わないかも」「こうしたら取り入れられるかな」と、うまく（自社の状況に）置換していただけるとありがたいです。会社によってセオリーとか、やらなきゃいけないことはまちまちだと思いますので、置換力を発揮していただきたいなと思います。
今日の構成は大きく2つに分かれてます。まず1つは、企画を作る時にはやりたいことを整理しなきゃいけないですよね。これが企画書に該当すると思います。まず企画書を整理して、そのあと決裁者に承認をもらうという、この2段階でお話しします。
企画書作成のポイントは「序列」を守ること
榊巻：まず最初に、企画書をちゃんと作るところを押さえないと先立つものがなく、承認ももらえないので、左側の話からします。
企画書をちゃんと作るうえで気をつけなくてはいけないことを5つ挙げていますので、上から1つずつ見ていきたいなと思います。1つ目のポイントは「構成と序列をちゃんと押さえる」ですね。
みなさんは企画書と言われたら、どんな構成で書きますか？ もしかすると各社で雛形みたいなものがあるかもしれないですが、ケンブリッジではこんなふうに要素を整理しています。
「取り組みの背景」「目指す姿」とか、1から11までが全て企画書の項目として満たされれば、いったん企画書は完成だろうという見方をしています。どこが足りないのか、見ながら埋めていくことができるといいと思うんですよね。
まずは構成を押さえてほしいんですが、重要なのは序列なんです。1、2、3……という番号が若いほうが満たされていかないと、下のほうが決まらない構成になってるんですよね。
1から11までだと細かいので、ざっくり4つに分けてみるとこうなります。上のほうは、取り組みの背景、現在の概況、目指す姿は何かという「意義目的」です。なんでこのプロジェクトをやるのか、それにはどういう意義があるのか、なんでやらなきゃいけないのかというのが意義目的のパートです。
それから1つ下りると、5から9の項目は「実行計画」と言えるかなと思います。Aの「意義目的」のために、こんなアプローチで、こんな検討のスコープで、実際はこんな施策が展開されるんだろうな……というのが実行計画です。そして「体制」と「予算」という感じで下に続いていきます。
「意義目的」がない企画書は浅く見えがち
榊巻：大きく4分類を押さえてもらいたいという話と、序列があるということですが、予算で揉めるのはだいたい「意義目的」の問題なんですよ。
みなさんは予算が問題だと思ってるわけじゃなくて、「予算をかけるぐらいの意義目的じゃないよね」「それほど重要な問題じゃないよね」と思っているので、なかなか予算が通らないんですよね。
（企画が通る時は）「こういう意義目的で、こういう実行計画でやるなら、こういう体制が必要だよね。それはすごく重要な話なので、このぐらいの予算つけようよ」となるわけです。にも関わらず、A（意義目的）・B（実行計画）を押さえずにC（体制）やD（予算）の話をしちゃうのは非常にもったいないなと思うので、まずは上からきちんと押さえていってもらいたいです。
ここからは1つずつ、「Aで押さえなきゃいけないポイントって何？」というのを解説していきたいなと思います。全部は押さえられないので、A、B、C、Dでポイントを1個ずつ押さえてお話しします。
意義目的をどうやって作ればいいかという話ですね。「意義目的は『問』が命」と書いてみました。（ポイントを）上から押さえていくので、まずは意義目的を押さえるわけですが、意義目的が浅いシーンをよく見るなと思います。
よく見るNGシーンを挙げてみました。「業務標準化がゴールです！」。このプロジェクトの意義目的としては、「標準化をちゃんとやって、プロジェクトのゴールを達成したいと思ってます」と言われているわけです。でも、これは「浅いな」というふうに我々からは見えちゃうんですね。
なぜかというと、これって単なる達成目標なんだなと思います。スローガン的で、どういう状況になったらこのゴールが達成できたことになるのかが、なんかぼやっとしてますよね。我々はこういうゴールじゃなくて、自問自答でもう一段深めています。
企画のメリットだけでなく「失われるもの」も考える
榊巻：僕らはお客さんからいろんな相談をいただきます。「こんなプロジェクトをやろうと思ってるんですけど、どうですか？」「こんなゴール設定でやろうと思ってるんですけど、どうでしょうか？」と。その中で「標準化がゴールです」ということをよく聞くわけですね。
こういうことを聞いた時に僕らがどうするかというと、「この取り組みをやらないと何が困るの？」「『標準化がゴールです』と言ってますが、標準化しないといったい何が困るんでしたっけ？」という問いを投げかけるようにしてます。お客さんにも投げるし、我々がゴールを作る時は自問自答もします。
「これって、なんで今やらなきゃいけないんだろうか」「会社のミッションとどうつながるんだろうか」「具体的に標準化することで誰がうれしくなるんだろうか」「具体的に何が変わるんだろうか」ということにスパッと答えられるようになっておかないと、浅いゴールになってしまうなと思っています。
私はこの問いがすごく好きなんですが、「逆に失われるものは何か」も重要だなと思ってます。標準化すると良いことばかりじゃなくて、失われるものもあるはずなんです。サービスの柔軟性が失われることもあるかもしれないですよね。（失われるものは）何か？ それって許容できるの？ という問いです。
自問自答を繰り返すと、ゴール設定の解像度が上がる
榊巻：こうやって自問していくと、「標準化がゴールです」と言っていた一文が、もうちょっと具体的になるんだと思うんです。
「業務の品質のばらつきが顧客満足度に致命的な影響を与えているんですよね。だから今、この取り組みが必要なんだ。なので業務を標準化することで社員が迷わず業務できる状態を整えて、品質のばらつきを抑えたいんだ」となると、このあたり（吹き出し部分）の問いにわりと答えられているんですよね。
具体的に誰がうれしくなるのか、具体的に何が変わるのかまでくると、かなり具体的になると思いますので、このぐらいまで意義目的を深めてほしいなと思っています。こういう問いを投げて具体化していくと、同じ「業務標準化がゴールです」という設定だったとしても、ぜんぜん違うものが出てくる場合があります。
例えば「業務のばらつきが育成の足かせになっていて、深刻な人材不足になっている」という背景もあり得ますよね。なので業務標準化することで教育負荷を削減して、多能工化を図りたい。結果として人員不足を解消したいというゴール設定。同じ業務標準化でも、その背景にあるものと狙ってるものが違うのが伝わりますかね。
「業務標準化がゴールです」だけじゃなくて、自問自答によってもう一段階深めて、解像度を上げていってほしいなと思います。なんとなく伝わるといいのですが。
でも、これは相当難しいなと思っています。さっきみたいに自問自答で問いを投げてもらうのは1つ（のやり方）なんですが、そもそもけっこう難しいことだなと思っています。
我々も現状調査を始める前に、コンセプトフレーミングというフェーズをわざわざ設けてるぐらい難しいものなので、小さめのコンセプトフレーミングというかたちで始めていただくのも有効です。
関係者を集めて、我々みたいな人間に少し声をかけていただいて、一緒にゴール・コンセプトを作るところから始めるのも手かなと思います。
曖昧な企画提案は「ついで感」が生まれてしまう
榊巻：構成と序列を押さえるのが大事、まずは問いを投げることで意義目的を具体化して、解像度を上げてみてください、という話をここまでしてきました。
ここでセールスの堀之内の話もちょっと聞いてみたいなと思いますが、お客さんからいろんな相談をもらうじゃないですか。意義目的が問題だったケースがあれば、ぜひ聞いてみたいなと思いますが、どうでしょう。
堀之内：（意義目的が）曖昧なケースはけっこうあるかなと思ってます。今、本編で例が出ていましたが、例えば「基幹（システムを）刷新したい、支援してくれ」とお客さんから問い合わせがきます。「なんでですか？」と聞くと、「3年後にEOS（End of Service）を迎えるから」という理由を挙げるケースがあるんですね。
こちらも「じゃあシステムそのものを変えるだけだったら、別にストレートコンバージョン（従来使用していたソフトウェアに原則として手を加えず、そのまま新しいシステムで動作させる方式）でいいんじゃないの？」と答えたりすると、「けっこう投資が大きいので、これを機会に業務改革をしたい」なんて言い出したりするケースはあって。
ただ私が聞いていても、どうも「ついで感」が強いなと思っていて。きっかけはEOSでもぜんぜんかまわないとは思うんですが、業務改革をついでにやられたら、現場はたまったもんじゃないよなっていう気はします（笑）。なのでこのあたりは、もう少し深く考えたほうがいいのかなと思ったりはしますね。
なぜ・誰のためにやるのかを具体的に定める
榊巻：堀之内さんが投げてる問いは、まさに「なんで困るんですか？」「EOSなので」だけでいいんでしたっけ、というあたりですよね。なんでこの取り組みをやるのか、誰が・どううれしくなるのか、具体的にどこまで変えようとしてるのか（が曖昧です）。
業務を変えるのも大変なので、失われるものがあるはずですよね。そこの覚悟もイメージもない状態で始めてしまうと、ちょっとリスクがあるよねと。問いをちゃんと投げて、自問自答して考えると、（意義目的が）深まっていく感覚はありますよね。
堀之内：ありますね。私も営業の段階でこういう話を聞くので、私自身が問いを投げかけることによって、お客さんのほうで「じゃあもうちょっと考えてみます」というケースもけっこうあります。それで再考してもらえるきっかけになるんだったら、いいかなとは思ってます。
もちろん我々も商売なので、さっきのコンセプトフレーミングみたいなサービスもありますし、そこまでご相談いただけるならもちろんありがたい話ではありますが、本当に軽くディスカッションパートナーとして、まずは壁打ち役ぐらいにはなれるかなと思っています。
榊巻：まずはそこからですよね。ディスカッションすることで深まることはあるなと思っています。ありがとうございます。
実行計画は「タスク」レベルまで砕く
榊巻：意義目的が押さえられたら、次は「実行計画」ですね。「確かに意義目的はそうだね」「こういうふうにやっていきたいね」という解像度が上がってきたら、実行計画を作りたいんです。実行計画については「アプローチ」の部分をお話しします。大事なことは「タスク」に砕くことですね。
よく見るNGシーンがこんな感じです。「実行計画はどんな感じですか？」とお客さんにおうかがいすると、「調査に2ヶ月かけます。そのあと構想策定して、要求定義して……」という、年単位の大きな矢羽がよく出てきます。
これではちょっと具体化が足りないというか、なかなか企画としてすぐにスタートできないなと思ってます。どうしてかというと、「調査」「構想策定」とか、フェーズが分かれているわけです。
これだと、調査のフェーズで何をするのか、終わった時に具体的にどんな状態を作るのかがイメージできないんですよね。そうすると、企画書を読んだ時に一緒にプロジェクトをやるメンバーたちは迷っちゃうと思うんです。
よく見る“NGなロードマップの書き方”
榊巻：僕らがどうしているかというと、もちろんロードマップは作るんですが、「アプローチ図」のレベルまで落として作っています。例えば調査を2ヶ月やる中で、どんなタスクの塊があるか。どこをどういうふうに調査するかを設計して、現場のヒアリングをして、マニュアル棚卸して……とあるわけじゃないですか。
「こんな感じの箱がいくつか並んでいて、2ヶ月過ごすんだな」「終わったタイミングでこんなふうになるんだな」というイメージができるぐらい（まで粒度を下げる）。
実際にプロジェクトが始まる時は、我々はスケジュールまで落として、月単位でどういう会議を何回・誰とやるかまで決めています。
最初のフェーズだけでいいので、企画の段階で、アプローチ図まではこのぐらいの粒度まで砕いてもらいたいと思っています。そうすると、だいぶ解像度が上がりますよね。
「そんなことをやるのね」「確かにそれは大変そうだな」「業務マニュアルの棚卸まで必要？」という議論が、これでようやくできるようになるわけです。一言で調査と言っても、人によってイメージするものが違いすぎて、イメージがばらついちゃうかなと思っています。実行計画の部分は、シンプルにそれぐらいの話です。
PMが忙殺され、プロジェクトが炎上気味に……
榊巻：次は「体制」の話に入っていきたいと思います。意義目的が決まって、やることのイメージが固まってくると、今度は体制を決めるわけですね。体制で大事なのは、役割で考えることです。
最終的には、よく見るこういうアウトプットができますよね。体制図です。プロジェクトのコアチームにこんな人がいて、現場からはこんな方々に入っていただいて、体制図ができました、というふうになります。
もちろん体制図は必要なんですが、これだけで終わってる場合はけっこう危険だなと思ってます。よく見るNGなシーンを挙げてみるといっぱいあるんですが、特にこれをよく見ます。
PM（プロジェクトマネージャー）をアサインしたものの、意思決定や現場メンバーへの指示に忙殺されて、社内のコミュニケーション、上申や承認、来月の活動の設計などが後手後手になって、あちこちから問い合わせきて、プロジェクトが炎上気味になる。
プロジェクトマネージャーがボトルネックになって、プロジェクトがうまくいかないケースをすごくよく見ます。なんでこうなるかというと、体制図で考えを止めてるからなんです。
「とりあえず」でPMをアサインするのは危険
榊巻：役割で考えると、プロジェクトマネージャーには大きく2つの機能があるなと思っています。意思決定をしなきゃいけないという機能と、プロジェクトの設計と運営をする機能です。この2つを、プロジェクトマネージャーは両方担ってるんですよね。
もうちょっと細かく、プロジェクトでの各役割を砕いてみたいと思います。今話したとおりプロジェクトマネージャーは、方向づけをしたり施策の検討をする意思決定系の話と、プロジェクトの運営・設計・管理をしなきゃいけないという2つの機能を持ってるんですよね。
この2つの機能をあまり考慮せずに、「とりあえずプロジェクトマネージャーを1人入れればいいんでしょ」という感じでアサインしてしまうと、パンクしてしまうということです。
細かいのでざっくり言うと、業務部門は業務を調査したり分析する。もしくは新しい業務が出来上がった時に、定着化をがんばるのが業務部分の機能ですよね。IT部門はシステム側の調査や分析、あとはシステムの改修が必要になったらシステム改修・開発をする機能があると思います。
ITベンダーはIT部門と連携してシステム開発をするとか。それから外から入るスペシャリストのような人もいますよね。コンサルタントなど、この道に通じているスペシャリストたちが提案をしてくれたりするわけです。経営はというと、承認をする。こんな役割分担でプロジェクトが進んでいきます。
PMがプロジェクトのボトルネックになってしまう理由
榊巻：意思決定とプロジェクトの運営・設計を担っているプロジェクトマネージャーが、最大のボトルネックになるんですよ。例えば、業務やシステムを調査した結果が集まってきて、それをさばくのがプロジェクトマネージャーの役割になっちゃうんですよね。
「だったら次はこうしよう」とか、スペシャリストから「通常、他社さんはこういうふうに運営されていたり、こういう施策をやられていますが、御社ではどうなんですか？」みたいなこと言われる。それを元に意思決定するという機能が、ここ（プロジェクトマネージャーに）に集中しますよね。
それから、コミュニケーションのハブにもならなきゃいけないです。例えばプロジェクトで意思決定したことを、「こういう意思決定をしたので、こういうふうに動いてほしい」とベンダーさんに伝える。そして、意思決定したことを経営に上げて承認をもらうとか。
来月のプロジェクトの運営の仕方を設計して、「来月はこういうふうに動くから準備しといてね」「次はここにヒアリング行ってほしいんだけど」という伝達をしなきゃいけない。コミュニケーションのハブになっているというのも、もう1つの側面としてあるなと思います。
“人を充てておしまい”にならないために
榊巻：こう考えると、プロジェクトマネージャーは相当大変ですよね。だからプロジェクトに人をアサインする時には、こういう機能・役割を十分担えるかを考えてほしいんです。
プロジェクトマネージャーが誰かじゃなくて、「プロジェクトマネージャーとしての機能をこの人が1人で担えるかな。大丈夫かな」と考えてほしいんです。そこまでを考慮して体制図を作らないと、ほぼ意味がないってことですね。
どうしてもプロジェクトマネージャーがボトルネックになっちゃうので、「これを1人で担うのは相当厳しいな」と思うのであれば、例えば部門のサブリーダーみたいな人を立てて、現場での意思決定をこの人たちに任せる。
各領域でのある程度の意思決定をこの人たちに任せて、プロジェクトマネージャーはプロジェクトの設計・運営側に軸足を置くという手もあると思います。こんな感じで、負荷分散をするのも1つの手ですよね。
それから、どうしても現場側の意思決定にもプロジェクトマネージャーが力を割かなきゃいけない、重要なキーマンだとなった場合は、プロジェクトの運営・設計をするような右腕の人間を加えるのも1つの手だと思います。
外部の人材を右腕として活用するという手も
榊巻：ここで、我々みたいな外部の人間を入れるのも手だと思います。現場での意思決定は、外の人間ではもちろんやりきれないので、社内のリソースを（現場での意思決定に）集中していただいて、右腕を加えてプロジェクトの運営・設計をフォローするのも手だと思います。
「はい、プロジェクトマネージャーはこの人」というふうに人を充てるのではなくて、役割ベースで考えた時に担えそうか、無理そうであれば補強、もしくは負荷分散の策を考えていただきたいなと思います。
そこまで考えて、ようやくこれ（体制図）ができます。「とりあえずサブPMを入れておけばいい」ってことじゃなくて、サブPMにはプロジェクト設計・運用を担ってもらいたいとか、現場での意思決定を担ってもらいたいとか、役割まで落として考えてもらいたいです。
実行計画が具体的になった上で体制を作るんですが、役割ベースで体制を考えてもらいたいという話までしてきました。
「情シス部長がPM」はかなり危険
榊巻：さて、ここでまた堀之内に登場していただきたいなと思いますが、役割・体制のあたりでお客さんの相談を受けた時に、何か感じることはありますか？
堀之内：やはりPMは大事だなと思うんですよね。特に、PMが情シス部長のケース。これは本当に声を大にして異を唱えたいところなんですが（笑）。インフラや情報系のプロジェクトなら、それはそれでいいとは思うんですが、業務系のプロジェクトでPMが情シス部長というケースは本当によろしくないなと思ってます。
榊巻：わかります。それって、こっち（現場での意思決定）を担えないからですよね。設計・運営はできるんだけど、という。
堀之内：そうです。さすがに人事や経理みたいな管理系のところは、PMを人事部長がやって、オーナーが人事担当役員というケースはけっこう出てきてるんですが、販売系なんかは特にひどいですね。情シス部長がPMのケースが多かったりします。
話を聞くと「営業の声が強いから」「営業が忙しいから」と言うんですが、だからこそ余計に、営業系のところでPMを立てるべきだなと思っています。
結局、営業系は現場としてはヒアリング対象者で、完全にお客さんモードになってるので、どう考えたってプロジェクトがうまくいかないなっていうケースはよくあります。我々も体制図を見て、「ここの体制はちょっとよろしくないんじゃないですかね」と、よく指摘させていただいたりしてますね。
体制づくりの前に、まずは「意義目的」をきちんと設定
榊巻：逆もありますよね。現場部門しか見てなくて、「ここをやります」というPMが立ってくれてるんだけど、プロジェクトの設計はどうするんですか？ とか。
堀之内：それもありますね。
榊巻：ありますよね。だから、役割で考えることと意思決定できるかはすごく重要。こうやって言うとどうってことないんだけど、これ（体制図）で考えると「PMって誰？」となっちゃう。これはすごくもったいない。
体制図を作る時に、いったんみんなで「こういう役割をみんなが持たなきゃいけないよね」というのを眺めて、じゃあどこを誰が担うか・担えそうかを議論してから、体制図を作ってほしいですね。
体制を作るのも非常に難しいと思います。今日はずっと通して言っていますが、「このためにやる」「こういうことが必要だよね」「確かにそうだ」という意義目的があって、「それを実現するためにはこういう計画で、具体的にはこういう動き方をして、こんなタスクをさばいてくんだったらこういう人が必要だよね」と（粒度を）落としていく。
どうしても体制から考えると、「とりあえず人を充てればいいでしょ」ってなっちゃうので、やはり上から押さえていくのは肝なんだろうなと思います。
