コンサルタントとは、何を指すのか？
----
#contents
----
* 広義のコンサルタント [#vfec4851]
「顧客の業務要件を定義することができ、また提案することができる人」という定義でよいかと思う。
なお、ちょっと毛色の違う存在として、経営コンサルタントがあり、こちらは「業務自体の在り方を論ずることができる人」として問題ないかと思う。
ちなみに、経営コンサルタントを頼るときは大抵会社が傾き赤字体質になっていて、経営コンサルタント＝「赤字を黒字にする人」「経営を立て直す人」というイメージを持つ人も多い。
が、実体は若干異なり、その背景は順風満帆の時はそんなものに頼らないわけで、藁をも掴んでくるのは末期、というだけだろう。((余談だが、ダメな人はいつだって手の施しようがなくなってから他人を頼る))
本来的には、経営状態が良かろうが悪かろうが、よりよい状態へ導くことができる人のことを指すものと考える。
前置きが長くなったが、税理士や起業コンサルタントなどを鑑みるに、コンサルタントとして外せないポイントとは何か？を以下に考えた。
** 顧客の現状を正しく把握し、そのために必要な情報を引き出すことができる [#hd191296]
顧客は、現状が抱えるネガティブな部分やそれがもたらす負利益を己以上に理解している人間がこの世にいないというのに、自らの現状を正しく表現することができない。
病院で医者に問診されることを思い浮かべてほしい。恐らく、医者が求めているだけの情報の提示することは、誰しも充分にできていないはずだ。
これは、伝えなければならないことを整理し、伝え方を考え、それを漏れなく伝えるという思考訓練を充分に積んでいないことに起因し、これは意識しなければなかなか伸びない部分でもある。
この状態で物事を進めても、手戻りや卓袱台返しが頻発するだけであるし、予め規定した期間や予算の超過リスクにもなり、何より顧客の満足度は高くなりようもない。
先述の通り何より現状を正しく把握しているのは顧客であり、ここから如何に情報を引き出すか。
腕の見せ所である。
関連して、「そんなこと聞いていなかった、初耳だ」とか「自分にはそういった認識はなかった」というシーンは幾らでもあるし、顧客が全て正しいとは言わない。
ただ、この引き出すという能力次第で、その機会が少なくなったり、インパクトの大きいことで発生しにくくなるのは間違いない。
** 深い見識を持ち、それを元にした在るべき姿を提案できる [#x483a5f3]
「深い見識を持つ」。
ここに異を唱える人間はいないだろう。素人に相談して金と時間を無駄にするくらいならば、置物にでも話しかけている方が金を使わないだけマシに決まっている。無駄にするのを時間だけなのだから。
また、見識だけでは無意味であり、良くある例で言えば''オタクと評論家は役に立たない''ことが挙げられる。
オタクは自らの知識をひけらかすだけであり、解決したり前に進めることではなく、自己弁護や自己愛、更に言えば自慰行為に過ぎないし、評論家は斜め上の目線からダメ出しするばかりで、建設的な何かをもたらすことはない。
経験や知識から生み出された何かを知恵と呼ぶならば、これを元に在るべき姿を提案できることこそがコンサルタントなのだと考える。
** 言いっ放しでなく自ら実現に向けて行動でき、要求を達成することができる [#c4c0cd76]
''客や状況が求めているもの、客や状況に求められるものは、いつだって解決''なのだ。
勿論、それに至るまでの筋道を示すことが重要であることに異論は無い。
が、これは上記の評論家につながることだが、あーでもない、こーでもない、そうじゃない、こうなんだとロジックやメソッドに基づいた発言・指摘だけでは不充分であり、自らが「ほら、こうすればできるでしょ」と示すことができなければ、口だけ君になってしまう。
それに、実際の話、村の長老の様にアドバイスだけしていても、顧客をはじめとした関係者との信頼関係を築くことはできないことが多く、やや精神論気味になるが「一緒に汗をかく」ことも肝要ではないかと思う。
* 狭義のコンサルタント [#q716b19e]
ここでいう狭義とは、ずばりSAPコンサルタントを指す。
一般的には''業務プロセス''を定義できる役割のことであり、個人的にはプロジェクトの最初から最後まで実施できる人のこと。
どちらにしても、コンフィグを設定できる人ではないことは確か。
知らないことや理解不能なことは山程あるが、学ぶ方法がないわけではない。
ここでは、上記の2点を軸に言及したいと思う。
** 業務プロセスを定義できる、ということ [#h3a769af]
当然ながら、全てのシステムは業務に使用する。
これを構築するにあたり、機能を熟知していることや技術に長けていることは然程重要ではなく、''お客さんの仕事をデザインできること''が肝要であると考える。
じゃあ何を持って業務プロセスを定義できると呼ぶか？というと、コンフィグいじれるなんてのは論外も論外の設定屋に過ぎず、一言でいえば要件定義〜プロトまで一人で出来ればokなんじゃないかと思うが、この構成要素は3つある。
じゃあ何を持って業務プロセスを定義できると呼ぶか？というと、コンフィグいじれるなんてのは論外も論外の設定屋に過ぎず、一言でいえば要件定義～プロトまで一人で出来ればokなんじゃないかと思うが、この構成要素は3つある。
*** 論理的思考ができ、他者への説明と理解を得ることができること [#q035c689]
もっとも重要なのは、ここである。
筋道を立ててデザインし、深堀りし、検証することができなければ何も生み出せないし、これを顧客や上長、関係者に説明した上で認識を共有し、合意を得ることができなければ何も前に進まない。
そういった意味では、これに比べれば他の要素は二次的・三次的なものと言える。
当たり前すぎて伝わらないかもしれないが、逆を考えて欲しい。
説明の辻褄があっていない、理論に脈絡が無い、コツやツボをおさえていない、大事なところの裏をとっていない、スタンドプレーで暴走する、ユーザによく却下されたり怒らせたりしてしまう・・・
まわりにこんな人はいないだろうか？
よくコミュニケーションスキルという漠然とした言葉で表現されるが、実体はコレである。
そして、ここがなっていないと、評価は''技術者どころか、人間として、社会人としてできていなければならないことが全くできていない残念な人''となる。
「もう少し考える」ことさえすれば、自分もまわりも残念な気持ちにならずにすんだり落ち込む機会が少なくて済んだりするのだから、頭は首の上についているうちに使いたいもの。
*** 業務知識を身につけていること [#saf4886f]
業務知識とはなんぞや？
大括りには業種、製品、取引先、国を背景にした''お客さんのお仕事に対し、どの程度の理解があるか''ということであり、それらは経験を活かすことができる。
但し、その上に胡坐をかくことはしてはならず、重要なのは学び続ける姿勢と考える。
なぜなら、機能的な話ならばコアの部分を押さえれば大体okとか単にキャリアに正比例して伸びる知識もあるが、この点については終わりがないからだ。
もちろん、その顧客の独自プロセスなどは最初から知っているはずもないので、恥を忍んでお客さんに教えてくださいと頭を下げることも肝要。
※ここでの「恥」とは、不勉強を反省せずに聞いてしまうのがマズいという意味を指す
*** SAPの知識があること [#zb9bf189]
業務プロセスを定義するにあたり、当然ながらSAPでの実現方法がデザインできなければならない。
そのためには、標準でできることと・できないことの切り分けをできていなければならず、更に標準でできないからといって途方に暮れていては前に進まないため、「純正の標準でできないならば、如何に実現するか？」まで考えられなければならない。
そのために必要なのは、下記の2点である。
-標準コンセプトを理解していること
「SAPは、どういった思想で設計されているか？」これに尽きる。
例えマニアックな機能であっても、ここにさえ思いが及ぶならば、知らないことでも想像はつくし、足元が揺らいでいる現状を如何にウラを取っていくかイメージできる。
具体的には、SAP標準が用意している機能やデフォルトコンフィグから窺い知ったり、先達よりナレッジの吸収を図ったり、或いは単にググるなど、なんでもできる手を打つしかない。
私見だが、シンプルに或いはスマートに実現することが難しい要件、影響範囲が大きく考慮事項が多岐にわたるようなテーマは、システムの設計思想に合っていないことが多い。
-標準に手を入れる手段を自分のものにしていること
標準でできない = じゃあ新しいコンポーネント作るか！
・・・なんて話にはならず、SAPには顧客要件を充足すべく提供されている手段少なくない。
例えば[[Exit>SAPの拡張手段#b1976726]]や[[BADI>SAPの拡張手段/BAdI]]を知っているだけで、「ざっくりn人日のアドオンでいけます」という話はできる。
これは、コンフィグばかりやっているだけではSAPコンサルタントとして不完全であり、標準の[[拡張>SAPの拡張手段]]さえ考慮して練らなければ、糸口すら見えず途方に暮れたり、できませんの一点張りで前に進まなかったりする。
「それはコンサルの役割ではない」という人もいるだろうが、ソリューションを提案する人間として''コンフィグのことしかわかりません''では話にならない。いわゆる[[SE>プロジェクト/システムエンジニア]]がやるようなことも、少なくとも部分的にはこなせる必要があると考える。
ていうか、高いんだからそれくらいやれよと。
というと実装をしらないコンサルタントをただ馬鹿にしているように聞こえるかもしれないが、コンサルタントは良質なソリューションを提供できなければならない。
それにあたり、コンフィグしか知らないが故に幅が狭まってしまったり底が浅くなってしまっては、課せられた役割は果たせないのだ。
** プロジェクトの最初から最後まで実施できる、ということ [#b9a77507]
キャリアがない/足りないという事実は別の話として、プロジェクトの一部分の工程しかできないということではコンサルタントとは呼べないと考え、オマケにオマケを重ねても精々[[アドオン]]の実装以外はできる必要がある。
それでは、プロジェクトの工程とは何か？について、敢えて工程順序の逆から入りたい。
理由は、遡れば遡る程に広く深い範囲のナレッジが必要とされるためである。
*** 稼動サポートフェーズ [#w7f16039]
''起こったトラブルに即時対応できなければならない。''
この一言に尽きる。
ではこの段階で起こるトラブルとは何かというと、大きくはコンフィグ漏れや間違い・[[アドオン]]のバグ・[[移送>ベーシス/移送]]のトラブルの三つである。
なお、ここでのトラブルは色々な[[プロジェクト]]特有の前提や要求をキャッチアップできていなければならないため、[[成果物]]対応でなければ要員追加は効果的でない。
-コンフィグ漏れ、誤り [#i90630f6]
これは分かって当然。
統合テストや運用テストを潜り抜けてでる漏れや誤りなんてのは、大抵それ以降の突貫工事に起因するものなので、即原因を分析し即[[本番機>SAPの構成/本番機]]へ[[移送>ベーシス/移送]]する。1〜2hもあれば充分だろう。
統合テストや運用テストを潜り抜けてでる漏れや誤りなんてのは、大抵それ以降の突貫工事に起因するものなので、即原因を分析し即[[本番機>SAPの構成/本番機]]へ[[移送>ベーシス/移送]]する。1～2hもあれば充分だろう。
- [[アドオン]]のバグ [#v16bf57d]
ソースの読み書きを出来ないコンサルタントが、只の役立たずに成り下がる瞬間がこれである。
[[開発者>プロジェクト/開発者]]に「まだですか」「もうちょいかかりますか」と煽ることしかできない、有害物質となってしまう。
そんなものは、読み書きさえできれば下調べは出来るはずであるし、開発チームに投げるにしても解決までの時間を大きく短縮できるはずだ。
-[[移送>ベーシス/移送]]のトラブル [#s6f44b09]
[[移送>ベーシス/移送]]のコンセプトや機能を理解できていないコンサルタントは少なくなく、繰り返し起こさないために原因の究明と善後策はもちろん重要であるものの、必要なのは''今、その場で解決できること''なので、[[ベーシス]]の担当が帰っちゃったんでわかりませんーではなく、リカバリくらいは自己完結して欲しいもの。
正しい順序で[[移送>ベーシス/移送]]しなおせば、基本的には直るので。
*** 本番移行/教育フェーズ [#ba1e4f15]
''本番移行のトラブルシュートができること''と、''トレーニングの準備〜実施までできること''。
''本番移行のトラブルシュートができること''と、''トレーニングの準備～実施までできること''。
前者は、[[マスタ項目定義書>成果物/マスタ項目定義書]]と[[概要設計書>成果物/概要設計書]]と実機での現象を見比べながら、原因を究明し、対応できることが条件となる。
ここでも、ソースの読み書きができないコンサルタントは大きなハンデとなる。
後者は、トレーニング計画を立案し、トレーニング日程を調整し、トレーニングマテリアルを作成し、講師を務めることができること。
飛んでくる野次や質問に答え、QとAをメモしつつ、不安そうな顔をしている人を拾いながら、制限時間内に説明を終え、理解度を上げなければならない。
ただ、会場が滅法だだっ広いとか受講参加人数がめっちゃ多いとか''テンパるなっていう方が無理''という状況も。
なお、ここでの要員追加は、猫の手よりはマシと言ったところ。
*** 実現化フェーズ/開発フェーズ [#mc6593bb]
''[[アドオン]]を[[設計>アドオン/設計]]できなければならない。''
これには、[[移行>プロジェクト/移行]]で使用するプログラムでもない限り、[[マスタ>SAPのマスタ]]・[[組織>SAPの組織構造]]・プロセス・コンフィグを理解しつつ[[設計>アドオン/設計]]しなければならない。
ここまでは最低限必要な要素だが、[[アドオン]]のボリュームの感度が読めなかったり、変更に弱い[[設計>アドオン/設計]]になってしまったり、[[実装>アドオン/実装]]し辛い作りになってしまったりと、やはりここでもソースの読み書きができないことが足を引っ張る。
但し、ここまで来るとほぼタスクは作業レベルまで落ちているため、相対的には要員追加の効果が高いフェーズと言える。
*** 設計フェーズ [#e7db332c]
''実現レベルの業務プロセスを定義できなければならない。''
これは、組織・マスタ・プロセス・権限といった重要要素を複合的に勘案できなければならないことを示す。
即ち、標準の機能だけでなくコンセプトも自分のものにし、稼働後どうなるか？どのように使われるか？をイメージできていなければならない。
前フェーズの考慮漏れや前提変更を行きし戻りつ進める中で必要な作業をこなしていかなければならならず、これが遅れると実現化フェーズの開始に食い込んだりするため、それなりにタイトである。
*** 構想策定/予備調査フェーズ [#oe7ebe05]
''後の工程を実現に結びつけるための報告ができなければならない。''
そのためには語るべきテーマが山程あり、しかし工期が充分に確保されづらいフェーズである。
そのため、深入りしてしまいすぎると納期に間に合わず、浅すぎると後続フェーズの品質に関わる最も重要かつハードなフェーズかと思う。
*** 提案フェーズ [#ob700185]
''提案できなければならない。''
筆者は稼働済みのユーザに対する新しい[[プロジェクト]]提案や保守ネタで「こんなことやりましょう」という提案しかしたことが無いため、新規導入の提案については想像でしか語れない。
が、明確に必要だと言えることがある。
-コンサルタントとしてだけでなく、営業活動もできること
-作業者としてでなくマネージャとしてProfitとBudetを意識できること
-それでいて、プレイヤーとして充分な力量を持っていること
-モジュールの専門家でなく、[[ERP>SAPの共通用語/ERP]]の専門家たること
-社内の利害関係を調整できること
これらをもって、経営層と現場の双方にとっての導入メリットを語り、食いついてもらい、お金を出して頂かなければならない。
~
~
CENTER:【スポンサードリンク】
#htmlinsert(amazon_book_sap_system_implement)
~
~
----
#pcomment(reply)
