システム移行は大変？ピンとこないことがプロジェクト最大のリスク
システム構築プロジェクトに費やす工数として、実に3割をも占めるタスクをご存知だろうか。当然システム設計や開発タスクではない。
それは「移行」だ。
「そうそう」と納得した方は過去に痛い目にあった方だろう。
「そうなの？」と疑問に思った方は要注意だ。
2019年にみずほ銀行が新システムが稼働する際には、8年かけて開発を行った。
その際の移行は、ATMを9回も止め、丸1年かけて行っている。本番稼働に1年かけたほどなので、その前の移行設計や準備もその数倍は時間をかけているだろう。（今は稼働後のシステムがいろいろ問題になっているが）
実際、「移行作業がうかくいかない・間に合わないから、本番稼動を遅らせます」「移行データが全然正しくなくて、システムの機能はあるのに業務に使えない」ということは往々にしてある。
だが後者の「移行に大変なのピンとこない」人が一般的には大半だ。
それはなぜか。
1つは家の引っ越しと同じと判断して軽く見ているからだ。
だいたいの家の引っ越しは業者に見積もらせてあとはおまかせが大半だ。家主がやるとしてもダンボールへの梱包、それも業者に任せることすらある。
たとえアメリカサイズ・キングサイズの家から、昔風の日本家屋に引っ越したとしても判断は少ない。「キングベッドは合わないから捨てようか」「でかいソファは畳に似合わないけど我慢しよう」程度のことだ。
もう1つは目に見えないことがある。
モノなら目に見えるため「なんか合わないな」「家具がデカイから大変そうだな」とわかるが、システムでは「マスタデータの移行対象が1万件」と言われてもピンとこない。
こういった過去の自分の経験・体験からの判断がベースになるため、「移行なんて何がそんなに大変なの？」となってしまう。
だが、みんな持っているスマホの移行をイメージしてほしい。これまで家族全員でiPhoneを使っていたが、Androidへ買い替えたケースだ。
まず、iPhoneで使っていたアプリがAndroidにもあるのか調べることから始まるだろう。そしてそのアプリがクラウドにデータを持ってくれていればいが、なければなんとかして移行しなければならない。
例えば写真。これまでiCloudで保管していたのをGooGlePhotoに移行しなければならない。ツールを使うのか？自分で全部ダウンロードしてフォルダ作り直して移行するのか？はたまた特定の写真は移すのを諦めるのか？
移すのを諦める場合もすんなりとはいかない。家族全員の写真なので「これいるの？」というのを全員に聞いて行く必要がある。
これを同じように、家計簿のデータやゲームのデータ、家族と共有しているカレンダー情報などすべてに対して行っていく必要がある。
考えただけでも辟易して、スマホを買い替えたことを後悔したくなる。
システム移行ではこの規模がより大きくなる。
例えば、基幹システムを刷新するに当たり、これまで取引先一覧（マスタ）として1つで管理していたものが、仕入先・販売先に別れた場合を想像してみてほしい。
「これは仕入先なの？販売先なの？両方なの？」とまずはそもそもの一覧の判別が必要になる。
その上で過去の取引情報に対しても「これは仕入先との取引でいいんだよね？」と数年分溜まった取引の一覧に対して行っていく。
「そんな面倒はことはしたくないから、2000年以前の情報は諦めよう」とした場合もすんなりとはいかない。家族なら数名に確認をとればよかったが、システムのような数千人、数万人におよぶものだといろいろなキーパーソンとの合意を図っていかなければならない。経営層から組織長、現場のご意見番や古株まで。誰かが「No」といえば交渉は長引いていく…。
システムではこういったマスタや情報が多種多様に存在する。それだけでなく「旧システムのコード体系がおかしくで重複がある」などあった場合は最悪だ。データクレンジングというこれまた途方も無い作業を行っていかなければならない。
これにどう対処すればいいのか？
特効薬はない。
地道で途方も無い作業をやるしかない。
だが、まず「移行はこれだけ大変」というのをプロジェクトに関わる人間が全員認識しておくことが重要だ。
危機感があれば移行作業をきっちり見積もったり、移行チームに優秀な人を配置する手立てがとれる。
それによって開発期間や工数を事前に確保することができる。
プロジェクトを成功させるためには乗りこえなければならない必須の壁だ。まずはその大変さを認識して、事前に手立てを打つ動きがとれるようにしよう。
あとは「やらなければならないこと」として覚悟を決めて移行タスクに臨むのみ…。
「失敗の本質」とサンセットの必要性
私が勤めているケンブリッジでは、プロジェクトが終わった後やフェーズの境目(要求定義、設計、など)に、活動を振り返るサンセットという場を設けている。プロジェクトのメンバーが全員集まり(当然パートナーも)、活動のよかったところと改善点を振り返る。
どんな振り返りが挙がるかというと
・思った以上に追加の打ち合わせが発生し残業が続いた。提案時に正しく工数を見積れなかったのか。
・納品間際はバタバタした。段取りが悪かった。
・フェーズは終われたが継続はできなかった。もっと価値を見せれなかったか。
など生々しい「できなかったこと」「うまくいかなかったこと」も含めて振り返る。反省点はその場で別途1時間くらいか時間を設けて、事実確認や次のフェーズ・プロジェクトで活かせる点まで整理する。
えてして日本人は振り返りが少ない傾向がある。むしろしないことの方が多い。
失敗の本質は、大日本帝国が太平洋戦争でいかにして敗北を喫したのか、について書いた本だ。失敗理由はいくつかあるがそこには「失敗から学習する意識の軽視」も書かれている。
今のコロナの国の対応やオリンピック開閉会式の一連の騒動でもその傾向を垣間見れる。なぜこうなったのか、再び同じ事態を招かないためにはどうすべきか、振り返った上での対策は検討されない。なので同じ事態が起きても同じことを繰り返す。
「失敗の本質」で書かれた失敗に陥る傾向を未だに引き継いでいる。
プロジェクトでも同じだ。
「やっとプロジェクトが終わった！」という完走感には浸るが、振り返りはしないことが多い。プロジェクトの特質上、「数年に一度だし」「次自分がやるわけではないし」という気持ちから振り返りに気が向かない。
だが、プロジェクトは非常時の活動なので組織能力を高める機会としては貴重だ。
例えば、ある事業部のビジネス戦略を立案するというプロジェクトが終わったあとプロジェクトの振り返り、我々で言うサンセット。そこの振り返りとして「戦略は立てたが、我々がいなくなると本当に実行されるのか不安がある。もう少し実行のための手立てを議論してもよかったかも」という反省が挙がった。
そこでその反省に対して小一時間、プロジェクトメンバーで事実確認と「やれたこと」を振り返った。
・内部調整の足がかりや対外的な説明の準備を支援しても良かったかも
・顧客内部や「顧客の顧客」に対してはすでにアクションをとっているらしい、その点は大丈夫そう
・市場の興味・動向アンケートを準備したら内部・外部と話を進める上でいい後ろ盾になったかも
・別組織を立ち上げる、などコミットメントの動きをとってもよかった
・とはいえ数カ月後に中計策定の場があるのでそこには盛り込まれるのではないか
などいろいろな意見が挙がった。
そこで「中計策定の時期にコンタクトをとって状況を確認しよう」というアクションも決まった。
それだけではない。
・結局実行しないと意味がないので実行の足がかりまでやるべき、そこも提案討議時に話にあげるのが顧客にとっていい
・実行の足がかりにも説明準備や組織立上などいくつかレベル感があり、「どこまでやるか」という軸になる
と私にとっては「次にプロジェクトを進める／提案するときに討議する観点」というものが数多く得られた。
サンセットとしてフェーズ・プロジェクトの終わりに、ちゃんと時間を確保するとこんなことが期待できる。
①プロジェクト推進中だとなかなか言えなかったこと・もやもやしていたことをオープンにして、PMやパートナーとじっくり話せる
②メンバーとして「そもそもなぜこれをここでやるか」という進め方や方法論で理解に至らなかったことをじっくり腰を据えて話せる
③フェーズで区切ることで次やその先など長期的な視点で今を見つめられる
④今回の失敗を題材に「すべきだったこと」を見出すことで継続的な活動、この次に活かすことができる
どこぞのトレーニングや勉強会にでるよりもずっと学びは多い。
ではサンセットをどう進めたらいいか？特段の方法論はない。
だいたいは2時間程度全員が集まれる場を設け、チーム単位・個人単位で各自よかった点や改善点を挙げていってもらう。これに1時間。改善点などの中で「特に討議したい課題」をピックアップし、残り1時間で「どうすべきだったか」を討議する。
振り返りの観点としては、
・当初の目標・目的は達成できたか
・さらに改善すべき点、品質や生産性を高められる点はなかったか
・次の工程に共有すべきノウハウや学びは
・今後の懸念点、課題になりそうなことは何があるか
プロジェクトの期間が長い場合は全体スケジュールを見ながら起きたことを振り返ったりもする。
また人数が多い場合はチーム単位で分かれたり、事前に書き込みを依頼した入りする。
ただやり方自体は「各自よかった点や改善点を挙げ」「課題を討議する」という流れに変わりはない。
何より大切なのは「振り返りの場をちゃんと持つ」ということ。それも関わったメンバー全員参加して。
「失敗から学習する意識の軽視」、これはもう日本人に根付いた特質だ。
その特質があることを念頭に、そのための手として「必ずサンセットをやる」というルールを課す。
もしこれができないのであれば、すでに「失敗から学習する意識の軽視」にどっぷりはまっている証拠だろう。
弱虫ペダルとコンサルタントの第一線
お盆休みなので少し緩いネタを投稿しようと思う。
それがアニメから得るコンサルタントの価値観だ。
弱虫ペダルは私の好きなアニメ10本に入る作品であり、とても熱く感動にあふれた作品だ。
概要を簡単に述べると、総北高校自転車部という高校生のロードレースアニメ。舞台はだいたいインターハイであり、そこに向けた努力や思い、チームワークをインターハイの舞台にぶつけ、熱い戦いを描いた作品だ。
私もいつかあんな熱い体験を仕事なりPJでしたいと思っている。
そんな弱虫ペダルの中で、個人的名場面の1つが4期第10話にあるシーン。
総北高校1年生選手がインターハイ中に不調になり、トップ集団に追いつけず
後続の集団から出れずに迷走しているシーンだ。
その中でわざわざトップ集団から離れて助けにきた総北高校の先輩が起死回生の策を提示するが、それは「アニソンを歌いながらペダルを漕げ」というものだった。
プライドの高い1年生選手には受け入れがたい、集団の他のチームからも笑い者にされる策だった。
だが本気で語る先輩をみて、その1年生はこう考える。
「レースで戦えないほうがもっとかっこ悪い」
「これで前に進むならなんでもやってやる」
1年生はその策を受け入れ、アニソン一発歌って後続集団を抜け出していく。
この場面自体熱いのだが（背景知ってない・文字面だけだとそう感じないかもしれないが…）、コンサルタントであり、ビジネスパーソンとして感じ入るものもあった。
それは「第一線に立ち続けるには同じ覚悟を持っておかなければならない」ということだ。
コンサルタントであれ、1人の人間であり、知らないことはわからないし、経験がないことはうまくいかないことだってある。
それを乗り越え、顧客に価値を提供するには、教えを乞い、案をぶつけ・叩かれ・洗練させないといけない。
自分のイケてない部分をさらけ出す、ボコボコに叩かれるのを承知でレビューに出す、できないことを表明する。
下手なプライドがあると、これらを率先してやることはかなり辛い。臆してしまってなかなか前に進めない。
うまいこと言い訳つけたり、自分の中で隠し続けている方が断然楽だからだ。
だけどそれをやって得をするのは「今の自分」だけだ。
「コンサルタントとして価値を認められないほうがもっとかっこ悪い」。
どんな手でもやりつくす・考えつくす、教えを乞い新しいInputを得続ける、実行のために頭を下げる、自分が嫌と感じる人でも話を聞きに行く。
PJが成功に近づくためならやれることはきりがない。
シニアコンサルタント時代の自分はまさに臆して聞きにいけない、レビューに持っていけない奴だった。
「この状態でもっていってもフルボッコだ。もう少し考えてからもっていこう」
「今は忙しそうだから、ちょっと時間をおいてもっていこうか…」
など何かにつけて時間をかせぎ、結果フルボッコくらって修正に時間が足りない、ということの繰り返し。
これが変わったのは明確なきっかけはないが、徐々に顧客に価値を認められてきて、「もっとスピーディに価値を認められたいな」と自分思考から顧客思考になったからだと思っている。
うちの会社にはClientFirstという、いい言葉・いいカルチャーがある。
弱虫ペダルでは「勝機の1%があるなら」「なんでもやる」と言っていたが、「PJの成功率・お客さんの成長が1%でも上がるなら」やれることが何かあるはず。
「ClientFirst」という言葉がやっと身に染みて理解できてきたからだろう。
自分はいくつになっても、どんなタイトルになっても、「まだ全然できてない」と思うし、上司から「過信するな」とお叱りを受けたり、「またボコられてしまった」と自己反省会にキリがない。
先日も経営層の会議に新規サービスを持ちかけにいったら当然のことフィードバックを多くいただき、「あーまだまだダメダメだった。考えが浅すぎた」と凹んだ一週間を過ごした。
とはいえこれを回避していてはコンサルタントとして第一線に立っていられない。
そのことの方が自分としては辛い。
言われずにできればそれに越したことはないが、まだそこに至っていないならやれることはやっておきたい。
「これで前に進むならなんでもやってやる」
弱虫ペダルに教えられたことは、貴重で、熱く、そして厳しい。
ーーーーーーーーーーーーーーーーーーーー
ちなみに自分が最も影響を受け、かつモットー・目標としているアニメは別にある。
「やらなくていいことならやらない。やるべきことは手短に」
これをモットーにプロジェクトゴール・目的にそったコンサルタントワークを目指している。
そしていつか安楽椅子探偵になりたい。きっとなれると信じている。
これについてはまた別の機会で書こうと思う。
書籍「システムを作らせる技術」に込めた実体験からの思い
先日7/22に、3年（もしくはそれ以上？）期間をかけた、「システムを作らせる技術」がやった書店に並んだ。
嬉しいことに発売からすでに重版が決まったそうで、読んでいただいている方がいるのはとても嬉しい。
今回この本を書いたのは過去の苦い体験がある。
お金と労力をかけてシステムをつくって、結局使われない無用の長物になった経験だ。
重版になったということは、同じような苦労や失敗をまだ多くの人が経験しているのだろう。
それをできるだけ防ぎたくこの本を書いた。
以下にこの本の「おわりに」の文を転載しよう。ここに、上記に対する自分の思いを詰めている。
「こんな経験したくないな」
「もしかしたらうちの会社でもこんな事態があるかもしれない」
そう思った方はまずはこの記事を、そして本気で解消したい方は「システムを作らせる技術」の本を当事者に紹介してほしい。
ーーーーーーーーーーーーーーーーーーーーー
個人的な執筆動機
ケンブリッジへの入社以前に参加したある大企業でのプロジェクトが、本書執筆のきっかけだった。
私は途中から参画したのだが、間接部門を効率化した上で、より付加価値の高い業務へのシフトを目指すプロジェクトだった。当時は政府が「日本の生産性向上」を重要施策として掲げ、それに伴い各社でITシステム・ツールの活用が取り上げられており、その時流に乗っていた。経営陣からの期待も大きく、中期経営計画の一端を担うプロジェクトだった。
わたし自身も、大々的に発表されて社外からも注目を集めるプロジェクトへの参加に期待を膨らませていた。わたしはプロジェクトの途中から参加したのだが、その時点で技術部門の設計や開発、人事部門の定型業務を効率化するためのシステムをすでに構築済みだった。利用を開始して、具体的な効果が上がり始める時期である。
だが参加してすぐに見えてきたのは、華々しい発表とはかけ離れたプロジェクトの現実だった。特に問題だと思ったのは、（本書で説明した）組織受入態勢をないがしろにしてシステムで効率化する対象業務を選定していたこと。それなのに導入のフォローを全然していなかったことだ。
開発したシステムは実際には、「技術担当者がこのツールを利用して進める案件と手作業が残る案件を判別する必要がある」「ツールを利用する案件の中でも、ツールだけで完結する部分と手作業で補う部分の把握が必要」など、活用にかなりの注意が必要だった（組織受入態勢が低い機能）。
だがユーザーに使ってもらうための説明が不十分だったので、現場の方は「使う機会がなかなか恵まれなくてねー」「利用する担当者がこういったツールに慣れていなくてねー」といろいろ理由をつけて、利用を避けていた。
途中からの参加とはいえ、わたしもこの状況をなんとか改善しようと「こういう案件なら活用できるでしょ」「1つでいいから使ってみて。ほら効果あったでしょ」と、普及活動を行っていった。だがなかなか現場の熱は高まらない。そもそもこのシステムは彼らが望んで作ったわけではないのだから、当然かもしれない。
こうして当初発表していたほどはツール導入による改善効果は上がりそうになかったが、「○○時間の業務効率化！」と発表してしまった以上は引き下がれない。「経営目標必達！」を理由に、導入効果の上積みに奔走することなった。
つまり「ムダをなくして業務を良くする」という観点でなく、「なんでもいいからこのツールを適用できる箇所を探す」というプロジェクトになってしまったのだ。例えば、開発が大変な割に効果が低いのは分かっているので見送っていた領域も「適用できるのだから、この際作るしかない」と開発をすすめることになった。
ツールが適用できる部分をもう一度探すためのヒアリング会も全国で行った。本当は「ムダ業務をなくす」という観点だと、伝書鳩みたいなコミュニケーションをなくすとか、設計変更のやり方を標準化するなど、もっと効果的な方法もあった。だがあくまでツール導入が目的になってしまっていたので、それらに着手することはなかった。
効率化は二の次という、そうした姿勢は現場の方々も感じていて、説明会や開発にもだんだん協力的でなくなった。もちろんプロジェクトメンバーも冷ややかな目で見られるようになっていった。経営陣肝いりのプロジェクトなのに・・。
こういう経験があるので、この本で当たり前のこととされている方法論が、どれだけプロジェクト、ひいてはその会社全体に有効かを認識できた。Whyから考える重要性、システム機能の優先順位付け、現場の巻き込みなどはすべて、こういう事態を防ぐためにあるのだ・・と身に沁みてわかった。
そして、わたしがあの経験から得たもう一つの教訓は「プロジェクトの基本を無視してシステムを作ってしまうと、完成後にいくら現場に懇願しても無力だ」である。
カネと労力を使っても、使われないシステム、使えないシステムは最悪だ。誰も幸せにならない。システムは企業活動をより良くし、よりよい会社をつくるためにあるはずだ。
ケンブリッジに入社してからもこの経験が自分の中にくすぶっており、ケンブリッジでこれまで学んだこと、やってきたことをまとめたいと思った。私が経験したような悲しいプロジェクトを一つでも減らすために。この本に記載したことを読者が実践することで、少しでも幸せになるプロジェクトが増えるよう心から祈っている。
「どうですか」コンサルタントに価値はない、あるいは「Where」と迷いの重要性
事前に資料をつくりこみ、それをレビューや承認をもらう場で、なぜか発言がでずにシーンとなる。
もしくはお茶を濁したような発言がされ、本来確認してもらいたかったことにフォーカスされずに終わってしまう。
そんな経験ないだろうか？
「前回挙がった課題に対する対策を考えてきた！確認もらって実行に移そう」
「実行計画をつくってきたので確認してもらおう」
と意気込んでもっていくものの、「うーん、そうだねぇ…」とハギレの悪い回答しかでてこない。
このときに、「どうですか」というワードでレビューや確認を依頼していないだろうか？
この「どうですか」の問い、コンサルタント・ファシリテーターも使う人が多いが、この発言には価値がない。せっかっく資料やたたき台をつくっても、「どうですか」コンサルタントとして臨むと資料も場も有効に活かせない。
なぜか。
それは「どうですか」と問われた相手は何を回答したらいいかわからないからだ。
「どうですかって言われても体裁を見ればいいの？中身を見ればいいの？」
「計画としてタスクの漏れを見ればいいの？実現性を見ればいいの？」
と問われた側は迷ってしまう。
「どうですか」という問いは発言・依頼する側としては楽だ。だが、それは相手にいろんなことを投げて、さぼっているとも言える。
「対策について、これで課題を解消できるか見てほしい」
「対策は挙がったが、リソース含め承認・協力依頼できる資料になっているか見てほしい」
この２つではレビュワーの観点が全然違う。
「課題を解消できるかなら、この課題に対しては別の策があると思う」
「協力依頼するなら目的と負荷をしっかり説明できるように補強したほうがいい」
とレビュワーの回答も変わる。
「実行計画としてリソースと実現性が妥当か見てほしい」
「実行計画として気にすべきマイルストーンや制約と整合とれいているか見てほしい」
この観点の違いでもレビュワーの回答は大きく変わる。
「あまりに同時並行が多いのでリソース的にきついだろう、ここを見直そう」
「経営報告がこのタイミングにあるから、このタスクは先行した方がいい」
レビューや確認を依頼する際には「どこを見てほしいのか」を明らかにした上で臨もう。資料を作り込んで終わりではない、何を見てほしいかまで考えて準備が完了だ。
そうすると意図した回答が得られたり、有効なフィードバックをもらうことができる。
ただ、いきなり「どこを見てほしいのか」の観点を出すのは難しいかもしれない。
その場合は、「作る際に迷ったところ」「自信がないところ」を出せばいい。
「対策を考えたものの、有効な策になっているのか不安がある」
「実行計画つくったものの、リソース見積もるのにこの粒度でいいか迷った」
「計画の時期感やタスク順序を設定したが、根拠が薄くて迷っている」
などなど、資料・たたき台を作った際に、「どうだろうか…」と思った部分はあるはずだ。自分なりに解消策は考えていたとしても、その観点を出すだけでずっとレビュワーは語りやすくなる。
かつその迷いを語ることで「ここについてはちゃんと考えてそうだな、他の観点を喋ればいいな」とも判断がつく。
この「どうですか」。
楽が故に多用したりしてないだろうか。だが、それなら録音再生でもできる。
「どうですか」は禁止ワードにして、どう「どうですか」を使わずに質問できるか、制約をかけて考えてみるともっといい意見をもらえるはずだ。
コンセプトとは何か、あるいはシステム構築プロジェクトでの必要性
業務改革やシステム構築のプロジェクトで、我々はゴールとは別に「コンセプト」というものを策定する。
そもそも「コンセプト」とは何か。
プロジェクト以外でもたまに聞く言葉だが、横文字で、わかったようなわからないような感をもったことはないだろうか。
辞書的には「概念」や「全体を貫く基本的な考え方」とある。
「チームのことだけ考えた」という本では「誰にどんなセリフを言わせるか」とある。
最もわかりやすくコンセプトを表現しているのはデザイン思考だ。
デザイン思考ではコンセプト＝「やることとやらないことをわかるようにする」。
同時によくあるNGケースも示しており、それは「社会やユーザーが入っていない」ものだ。
自分のコンセプトの定義は「何をまずやるのか」「何は後回しか」がひと目で分かり、何のためにやっているのか立ち帰れる1枚もの、だ。
以前はやっていた働き方改革を例にとろう。
どんなものがコンセプトとして思いつくだろうか。
例えば「自社の強みを活かして業界No1の働き方を実現する」。
これはNo1などビビッドな言葉があり、一見コンセプトっぽいかな、とも見える。
だが、これだと「誰がどんないいことがあるのか」「何を優先するのか」が明確ではない。
「個人の強みを評価し、強みを活かして価値をだしやりがいを感じる働き方を実現する」だとどうだろうか。
これだと
「強みを評価する仕組みがまず仕掛けで必要」
「弱みを克服する策は後回し」
「価値を出すこと＝やりがいとして、それを最大化する」
など何をするか、この改革でどんないいことがあるのか、が読み取れる。
少なくとも先述のコンセプトよりずっといい。
このコンセプトがある場合とない場合、どんな違いがあるか。
1つはプロジェクトで取り組む施策やシステムに盛り込むシステム機能要求を「どっちを優先するか」、意思決定する際の判断基準になる。
どんな会社・プロジェクトでもリソースは有限だ。人もお金も限りがある。
だが、取り組むべき施策や実現してほしいシステム機能要求は無数に挙がってくる。
そのときに「強みを活かすのに直結する施策はどれだろう？」「弱みを克服する策っぽいから後回し」とコンセプトをもとに判断できる。
プロジェクトで判断に迷う場面でも「強みを活かすにフォーカスしているか？」「価値だせる策になっているか？」と立ち帰れる。
もう1つは現場の理解だ。
改革は変化を伴い、ときには一部に痛みを伴う。
人は変化を嫌うものだ。
そのときに自分なり所属する会社に何のメリットがあるのかわからないことに賛同し、積極的に関わろうとしないだろう。
むしろ自分のメリットが減ったり、やることが増えるなら反対に回る。
そのときに、トップダウンで無理やり押し通す方法もあるが、それだと表面上は賛同・実行してもゆくゆくは元の状態にもどってしまう。
このときに「この改革でどんないいことがあるのか」があると現場へのメッセージも変わってくる。
「今までやりたくない弱みばっかり指摘されてたけど、それが変わるのはいいな」
「顧客に価値あることが評価されなかったのが、評価され支援されるのはいい」
と理解を得られると求心力をもって推進できるようになる。
システム構築でもコンセプトは重要だ。
意思決定に必要なだけでなく、関係者を巻き込むのにも必要になる。
あるプロジェクトでは、はじめ「パッケージを使い倒す」がコンセプトだった。
だが、それだと「とりあえずやれることはやればいいのか？」「何を先にやるのか？」など疑問がわいてくる。
同じ用に「パッケージに業務を合わせる」というコンセプトもイマイチだ。
業務とパッケージのGapがあるときに、どちらを優先すればいいかはわかる。
だが「それで何が嬉しいのか」が踏み込めていないため、現場からは「そうはいっても認められない」と反発を受けてしまう。
我々がプロジェクトの参画した際には以下のように見直した。
「パッケージ機能に合わせ運用を変更し、低コスト・柔軟な高品質なシステムを目指す」
それまでは法制度対応などあってもアドオンが多くてすぐに対応できなかったものをパッケージに合わせることで即時対応を実現する。
かつ、総コストはアドオンアドオンで高くなっていたものを抑制し、会社利益に貢献する。
プロジェクトの意思決定や関係者の理解を促すためにはコンセプトはこのレベルまで必要だ。
ーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーー
このたび本を書きました。7/22販売です。
プロジェクトの実例盛り込み、「どう求めるシステムをつくっていくのか」を書いています。
「システムを作る本」はありますが、発注者・依頼側として「どうつくってもらうか」を書いた本は少ないので、ぜひ手にとって読んでみてください。
https://www.amazon.co.jp/dp/4532323991/ref=cm_sw_r_tw_dp_PKT17MM6ASX15Y2SP8EM
「タグ付け」「同意」「言い換え」で議論はグッとスムーズになる
「本日は10年後のビジネスを考えてみましょう」
「将来として自社のビジネスチャンスがどこにあるか考えましょう」
このようにはじめに「今日何を議論したいのか」を明確に伝えたにも関わらず、実際の議論ではこうなることはないだろうか。
「今のお客さんはお金が動くことにした興味ない傾向があるからねー」
「今は環境嗜好の製品ってなかなか売りにつながらないんだよねー」
こちらが伝えた主旨と異なる発言が中心でなかなか議論が前に進まない。
本来であれば
「将来は人口減になりお金の流れも減少するのでそれをどうテコ入れするかに着目が当たりそう」
「今の異常気象などが続けはゆくゆくは環境嗜好にもニーズが高まるのでないか」
というような議論ができればベストだ。
議論が進み、ポジティブに意見を積み重ねることができる。
ただ、前者のような発言になるのにも理由がある。
1つは「言われたこともすぐに忘れてしまう」ため。
打ち合わせの冒頭で今日の目的を説明したとしても、そのときは覚えていても、実際の議論になると覚えてない。
議論までの間に他の情報を与えていたり、そのときには別のことに気を取られ聞いてなかった、ということもあるだろう。
そうなるとつい自分が思ったこと、興味・関心に沿った発言になる。
もう1つは「思考は現状に引きづられがち」な傾向があるからだ。
人はなかなかいまないことをイメージしたり考えたりすることが苦手だ。
つい自分が見聞きしたもの、経験したものをベースに思考する。
冒頭挙げたような将来について議論する際にはこの傾向が顕著にでる。
ではこのような議論をどうリードするといいか。
「タグ付け」「同意」「言い換え」の3つを活用することでうまくいく。
1つ目の「タグ付け」。これは「枕詞をつける」と言い換えてもいい。
議論になって、参加者に質問を振る際に、必ず今日の主旨であるキーワードを入れるのだ。
「XXさん、どうですか？」
「何か意見がある人いますか？」
「どんな考えが浮かびます？」
これではうまくいかない。
「XXさん、10年後のビジネスってどうイメージされてます？」
「自社のビジネスチャンスについて何か意見がある人います？」
「10年後のビジネスでどんな機会が考えられます？」
このように必ず、こちらが意図するキーワードをつける。
「そんな簡単なことでうまくいくのか？」と疑問に思う方もいるだろう。
だが、はじめにこのタグ付けをするだけで、質問された人は何を回答すればいいのかがわかる。
「質問されたことに回答しよう」という思考になるので、冒頭の目的を聞いてなかったり、つい現状の思考になってしまっても、主旨に沿った回答をしてくれる。
まずはクドくても質問・発言の際にはこのタグ付を忘れてはならない。
もう1つは「同意」だ。
議論する際に、我が強い人は別だが、人によっては自分の回答が意図に沿っているか不安に感じている人もいる。
「こういう回答でいいのかな」
「内容とか、粒度とか、このくらいでいいのかな」
こう感じている人に対し、挙げてもらった意見について「同意」を示す。
「なるほど、私は気付かなかったけど10年後はそうなってそうですね、いいですね！」
「たしかにおっしゃるとおりのビジネスチャンスって生まれそうですよね。」
ベタベタで構わない。むしろ最近のリモート環境だとベタベタで同意を示すほうが伝わりやすい。
みんな不安をもっているので、主旨に合っている・合ってないを「同意」として捕捉してあげる。
そうすることで、その後の発言も同じ感覚で回答を得やすくなるのだ。
最後が「言い換え」だ。
先に挙げた2つをやっていても、やっぱり主旨と外れた発言をされることは往々にしてある。
その場合は、発言を拾いつつ、こちらの主旨に合ったような意見に「矯正」して「言い換え」るのだ。
「今のお客さんはお金が動くことにした興味ない傾向があるからねー」
→
「なるほど。だとしたら10年後は人口減になってますけど、お金の動きも変わってるんですかねー」
「今は環境嗜好の製品ってなかなか売りにつながらないんだよねー」
→
「たしかに。だんだん関心が高まってますが、10年後だとどうなっているでしょうね。関心高まりますかね。」
「別のお客さんだと、異業種との情報連携も進んでいてねー」
→
「ということは、我々のお客さんも10年後にはそういった変化が生じてきますかね？」
「どんどん客先の売上も減っていってて10年後にはリスクしかないよ」
→
「でも、ということは売上減少を打開する策なり支援のようなサポートは求められるということですかね？」
といった具合だ。
相手の発言は汲み取りつつ（決して否定はしない！）、こちらの主旨に関する話題に誘導する。
議論をスムーズに進める人はこの展開がうまい。
議論が主旨に沿わない方向に行っても、相手の発言をうまくこちらの主旨に言い換える。
議論の目的／主旨があっても、人は自分の思っていること・興味関心で発言してしまうものだ。
だが、「タグ付け」「同意」「言い換え」というたった一言言葉を添えるだけで、議論を随分スムーズに進めることもできる。
ものすごいパワーや技術がいることではない。一言挟むだけだ。
だったら、ぜひともやってみよう。
ムダな議論をなくし、スムーズに打ち合わせを進めることは、自分だけでなく周りの人のためにもなるはずだ。
