コンサルタントになるために ～ シリーズその６

コンサルタント志望の方へのメッセージですが、コンサルタントはけっこう深夜に仕事をします。 ＳＥの時には会社で深夜(あるいは徹夜)仕事をしていたかと思いますが、コンサルタントも同様に深夜(あるいは徹夜)で仕事をします。ただ、 会社だけではなく、自宅でも仕事をするようになります。

アイデア勝負のところがあるので、会社でパソコンとにらめっこしていればよいわけではありません。 アイデアが浮かばないと、散歩したり、お風呂に入ったりします。 よくお風呂ではアイデアが浮かびます。 お風呂にメモがあるコンサルタントもいます。お風呂でアイデアがでると、 どこかにメモをして、お風呂からでると、もう一度パソコンに向かって、仕事をするパターンが おおいです。

コンサルタントの仕事は、説明資料をつくったり、プレゼンテーションをしたりするのがメインなので、 パソコンではWordやPowerPointをよく使います。 それ以外にも図形を描くソフトもつかいます。 たとえば、Visioです。

コンサルタントは、これらのソフトを扱い慣れてはいますが、それでも自分で考えるスピードよりも、パソコンの方が遅いのが事実です。 一番早いパソコンを使っていても、ソフトの動作の方が遅いのが事実です。 パソコンのスピードは充分速くなってきてはいますが、それでも、 コンサルが使うには、遅いのが事実です。

コンサルタントになるために ～ シリーズその５

コンサルタントになるためには、まずは問題発見をすることが必要です。

クライアント からは、多数の問題点がインタビューなどででてきますが、その多数の問題点から、根本的な原因を明らかにすることです。

クライアントが言っている問題点を、そのまま問題点として理解するのではなく、より根本的な問題点があるという風に考えることができる必要があります。

ＳＥやプロマネ上がりの方では、クライアント(委託者)が言っていることをそのまま信じてしまう傾向があるのですが、 コンサルタントでは、よりかみ砕いて、根本原因を知る努力が必要です。 より根本的な問題点をあぶりださないと、 当面の対処療法で済ませてしまうことになりますし、それではコンサルにはなりません。

いかに、クライアントの社内だけではわからなかったことを、明らかにして、 かつわかりやすく説明する力がコンサルタントには必要なのです。 この根本原因を考える仕事は、通常夜行われます。 日中はクライアントでヒアリング／インタビューしているので、必然的に夜になってしまいますし、じっくり考えるには、 ひとり静かに考えることも重要なので、夜(深夜)考えることが多いです。

コンサルタントになるために ～ シリーズその４

顕在化している問題点を深掘りしていくことは、非常に重要です。 たとえば、トヨタ自動車のＴＱＣでは、「なぜ？」 を５回唱えろと言っています。 その理由は「なぜ？」、さらにその深い理由は「なぜ？」と５回掘り下げていくと、 根本的な原因に至れるだろうというのが、トヨタ自動車のやり方です。 経験的には、５回掘り下げれば、根本的な原因にたどり着けるようです。

問題点をグループ化 するというのも、同じ考え方です。 グループ化するというのは、 問題点を同類項をまとめているのですが、同時に共通の根本原因をさぐっていることにもなります。

上記のような２つの方法は、問題発見の方法として非常に有効です。

逆に言えば、こういう手法があるということは、クライアントでは「問題点はわかっている」と言っても、 実は根本原因はわかっていないということになります。 ＳＥやプロマネ上がりの方は、 問題点は開発の委託者がわかっていると勘違いしていることがあります。 もしも、 本当に開発の委託者が問題点(根本原因)を把握しているのであれば、コンサルは不要ですし、 上記のような問題発見の手法は不要(いらなかった)です。 コンサルがいたり、上記のような問題発見の手法が確立されているということは、 数多くの会社では、根本的な問題はわかっていないということです。

コンサルタントになるために ～ シリーズその３

問題の発見は、非常に重要な事柄です。

発見の方法は、いろいろとありますが、コンサルタントにもよります。

１．まずは、顕在化している問題点を列記(ポストイットとか)して、グループ化していき、 根本的な問題点を探っていく方法

２．まずは、仮説を考えて、その仮説から、起こりえる問題点を考えて、 クライアントで発生している現象にあうかを考えていく方法

の大きく２つの手法があると思います。 わたし自身は、両方を使います。 １のいい点は、 クライアントにヒアリングした内容をそのままポストイットに書き込んで、いろいろとグループ化したりするので、なにより、 仕事をした気分になります。 ヒアリングの内容をまとめながら、問題点のグループ化のできて、 議事録なども書きやすく(短い時間で)なります。

２のよい点は、全体像をつかみやすいことです。 前回、４つのフェーズを書きましたが、仮説からはいると、 ２の解決策の立案以降が楽になります。 たぶん過去に同様の問題点があれば、２を使っているのだと思います。

コンサルタントになるために ～ シリーズその２

コンサルタントの仕事の基本の流れは次のとおりです。

１．問題発見

２．解決策 の立案

３．プレゼンテーション

４．解決策の実行

という４つのフェーズになります。 ＩＴの開発会社でＳＥやプロマネをしていた方には違和感があると思うのですが、 １の問題発見はコンサルでは非常に重要なことです。 ＳＥやプロマネの時には、クライアント(開発の委託者)が指示していたことですが、 コンサルでは、この問題発見が重要な事柄です。

クライアントは、自社のうまくいっていない事柄を知ってはいますが、それが根本原因であることは、めったにありません。 自分の病気がわからない(風邪だと思っていたら、実は癌とか)のが通常です。 まずは、根本原因を突き止めるのが、 コンサルの役割の重要なポイントです。

コンサルタントになるために ～ シリーズその１

今日からは、コンサルタントになってみたい方を対象に書き込んでいきます。

コンサルタントを目指している方はたくさんいると思います。 理由はいろいろとあると思いますが、

① 給料がい いから

② プレゼンテーションとか格好がいいから

③ コンサルタントという職業になんとなくあこがれて

④ 困っている人のために、解決方法を提案し、実行していきたい

などなど、いろいろとあると思います。

ＩＴコンサルタントを目指している方の場合は、違う理由もあると思います。 青山システムコンサルティングは社名のとおり、 ＩＴコンサルなので、ＩＴコンサルに特化して、これから、 コンサルタントを目指している方のヒントになるようなブログにしていこうと考えていますので、一読ください。

ＩＴコンサルタントとＩＴ開発会社の違い ～ その６

コンサルティング会社にもデメリットがあります。

① 総じて、報酬が高い
    ＳＥやプログラマーの報酬に比べて、コンサルタントの報酬は高いです。 会社の規模にもよりますが、 一般的に、月額の報酬がプログラマーが４５～８０万円、ＳＥが６０～１５０万円、コンサルタントは１２０～２５０万円です。
もちろん、、 コンサルタントは少数で、実際の開発がＳＥやプログラマーなので、 システム開発全体で考えれば、コンサルをいれても、総額はそんなに変わらないはずです。

② 口がうまいだけのコンサルが多い
    コンサルタントは、個人個人の能力による差が大きく、きちんと見極めが必要です。 会社名や報酬だけでは、優秀なコンサルタントが否かはわかりません。 一般的に大手のコンサルティング会社より、 少数精鋭のコンサルティング会社の方がモチベーションが高いようです。 口先だけのコンサルタントにあたると、 ものごとが表面的に流れてしまって、本質的なところに焦点があたらないので、悲惨です。 そのくせ、報酬だけはいっぱしですし。

まぁ、コンサルをつかえば、万々歳と考えるのではなく、必要なポイントを見極めて、コンサルを投入するのが、 ただしい方法だと思います。

ＩＴコンサルタントとＩＴ開発会社の違い ～ その５

コンサルティング会社のよい点は、いくつかありますが

① ぐちゃぐちゃになった問題点をわかりやすく、解きほぐしてくれる

② その問題点の解決方法を提示してくれる

③ 問題点や 解決策を、わかりやすく説明(プレゼンしてくれる)

④ 丁寧にドキュメンテーションを残してくれる

⑤ 実際に解決策を実行してくれる

という点にあると考えています。 ＩＴベンダーでも、ＳＩｅｒでも、ハードやソフトを提供したら、後はお客さまにお任せ、 というパターンが多いです。 ものができたら、はい、さようなら、と。 実際にそれを導入したら、業務が改善されたりとか、 利益があがったりとかの結果に責任をもたないのが普通なので、私(コンサル)からの視点だと、ずるいように感じます。

ＩＴコンサルタントとＩＴ開発会社の違い ～ その５

ラインの長になることと、プロジェクト・マネージャになることは、①と②の延長線にあるので、あまりむずかしくはないのですが、 コンサルタントというのは、視点がかわるので、なかなかものにならないようです。

コンサルタントという言葉に惹かれてくる方は多いのですが、いままでの経験上コンサルタントとして仕事ができるようになるのは、 １割ぐら いだと思います。 ９０％はプロジェクト・マネージャなどに逆戻りです。 コンサルタントとプロジェクト・マネージャのどちからが偉いという問題ではなくて、適性の問題です。 俺はコンサルタントだから、 プロジェクト・マネージャよりも・・・ということはありません。 仕事の内容が異なるし、コンサルタントはプロジェクト・ マネージャをできるというような上位互換性もありません。

コンサルタントの仕事は、いかに問題解決ができるか？に尽きます。 このブログの一番最初の話題ではあったように、① 問題発見、 ② 問題解決策の立案、 ③ クライアントの説得、 ④ 解決策の実行という４つの仕事がコンサルタントの仕事になります。

だから、ＩＴ関連で、なにがどう問題なのか、よくわからなくなって、それを解決したい場合は、 迷わずにＩＴコンサルティング会社にメールするのが、一番の解決方法なのです。 まずは、なにが問題点なのか、なんでうまくいかないのか、 ということを、明確にしてもらえます。

ＩＴコンサルタントとＩＴ開発会社の違い ～ その４

ＩＴコンサルティング会社の場合は、異なります。

プログラミングに厭きてきて、さてさて将来どうするか？ と悩み出しす２８～３５才ぐらいのＳＥがその母体です。

ＩＴ業界では、通常次のパターンが多いようです。

① プログラマー、 ② システム・エンジニア、 ③ ラインの長(係長、課長、 部長など)というラインのパターン

①②は同じで、③にプロジェクト・マネージャになるパターン。 これはプロジェクト単位の場合です。 プロジェクト・マネージャは、 マネージャとあるのですが、ラインのマネージャではなくて、１つ１つのプロジェクトの管理者です。

プロジェクトとラインの違いは、簡単にいうと、期限があるかないかの違いです。 組織(ライン)はとりあえずは無限の時間です。 これに対して、プロジェクトは、その開発期間のみです。 短いプロジェクトであれば、２週間程度から、 長いプロジェクトなら３年ぐらいと幅があるのですが、開発が終わり、無事リリースできれば、終わりというものです。

最後のパターンは、①②は同じで、③にＩＴコンサルタントというパターンです。 プロジェクトではなくて、 より上流部分を仕事にしようとするパターンです。

ＩＴコンサルタントとＩＴ開発会社の違い ～ その３

若い頃は、プログラミングというのが、本当にたのしいものです。 コンピュータを自在に操つれることがたのしいです。 それも、 かっこよくプログラミングできることにあこがれるのです。 それはサッカーでいえば、 かっこよくゴールをきめられるようになりたいのと同じようなものです。 たんにゴールできればよいのではなく、 かっこよくゴールをきめられることが重要なのです。

プログラミングも、た んにコードを発行できればいいものではなく、よりかっこよくコードを書くことが重要なのです。かっこのいいプログラミングというのは、時代にもよりますが、 よりシンプルで、より拡張性が高くて、より構造的なプログラミングです。

たとえば、若い頃はあたらしくてかっこのいい車が発売されると、乗りたくなりませんでしたか？ 男性の場合、車が好きな方が多いので、 わかりやすいと思うのですが、スカイラインＧＴ－ＲやＲＸ－７にあこがれをもったりしませんでしたか？ フェアレディＺでもいいのですが。 同じように、かっこのいい新しい言語が発表になると、わくわくしたものです。 そして、新しい車に乗るように、 あたらしいプログラミング言語を使ってみたいものだったのです。

これが、ＩＴ開発会社です。 基本的には、プログラミングが好きな社員がたくさんいるのです。 そのまま年をとって、 昇進して課長や部長になったり、あるいはプロジェクト・マネージャになったりすることもあるのですが、基本は新しい技術・ 新しいプログラミングにあこがれているのです。

ＩＴコンサルタントとＩＴ開発会社の違い ～ その２

もうひとつの側面を考えてみます。

通常、若い頃は、新しいプログラミング言語に興味をもちます。 私自身、２０年前は、 その当時のプログラミング言語の習得に興味を惹かれていました。 今はなき、 ＡＩツール(Prologなど)やパソコンでの開発言語(BASICやPascalなど)に興味をもっていました。 FortranやCOBOLなどの言語も習得していたし、新しい技術がでてくると、その技術のキャッチアップに燃えて いました。

ところが、年をとってくると、じょじょに考え方が変わってきて、新しい技術にはあまり興味をもたなくなります。

というのは、新しく社会にでてくるＳＥやプログラマーたちは、新しい技術からスタートするので、 同じ土俵で戦うのが辛くなってくるからです。 また、年をとることで、それまでへっちゃらだった徹夜などが辛くなることもありました。

となってくると、自然にクライアントに説明するところ(プレゼンテーション)にシフトするようになってきます。

若い頃は、仕事＝プログラミング(できるだけ新しい言語で)、という構図だったものが、３０代になると、 仕事＝クライアントを説得(プレゼンテーション)することに変わってくるのです。

ＩＴコンサルタントとＩＴ開発会社の違い ～ その１

今日から、ＩＴ関連企業として、ＩＴコンサルティング会社とＩＴ開発会社の違いを考えていきます。

ＩＴとつくので、どちらでも同じようなもの、と考えている方もいると思います。 あるいは、コンサルティング会社の方が、 なんだかわからないが、単価が高いと考えている方もいると思います。

考え方の違い は、ＩＴ開発会社はソフトウェアの開発をして、納品する会社ということです。

ＩＴコンサルティング会社は、ソフトウェアの開発は仕事ではありません。 ＩＴ導入にあたって、なにをどうすればよいのか、 そのベストな解を考える会社なのです。 ＩＴ導入にあたっては、いろいろなことを考えることが必要です。 会社の組織や業務手続きなどを、 より的確に変更することも必要になります。
ＩＴコンサルティング会社では、クライアントの業務改善が視野にはいりますので、クライアントの業務を深く知ることが必要です。 新規の業界であっても、業界の書籍や新聞をかたっぱしから読んで、この業界では知らないことはありませんよ、 というスタンスで仕事に臨むのがＩＴコンサルタントです。

それに対して、ＩＴ開発会社のスタンスは、より今風の開発ツールをつかって、プログラミングするのが目的なのです。 現在であれば、 ＷＥＢ２．０的な開発をするのが時流であり、その技術的なところに注力しているのです。

ＢＩツールの導入の留意点

風邪をひいてしまいました。 ２～３日ブログをアップできずにすみません。 では、気をとりなおして、またＢＩツールのお話です。

これまで、ＯＬＡＰツールを中心にＢＩツールについて考えてきました。

ＢＩツール の根幹は、システムが理解できないマーケティング部門や商品企画部門のスタッフでも、 オンラインで簡単にデータの分析ができることです。

マーケティング部門や商品開発部門に、システムの素養をつけさせたり、教育する会社もありますが、これはあまりお勧めできません。 というのは、マーケティングスタッフは、時間が許す限りマーケティングスキルを向上させるべきであり、 商品開発スタッフはより専門的に商品開発の深い部分に取り組むべきであり、なんでもかんでもできるようにすることは無駄だからです。

もしも、システムがそのギャップを埋めることができるのであれば、マーケティングや商品開発のスタッフには、 より専門分野の能力を高めてもらって、コンピュータに関することは、空気や水のように、なにも感じさせないことが有用です。

社員が１日で働ける時間は限られています。 いくら残業させたからといって２４時間は働けないのですから、 なんでもかんでもやらせるのではなくて、コアな部分にフォーカスさせるべきなのです。

Ｒ－Ｏｌａｐの効用

Ｒ－Ｏｌａｐの基本は、データウェアハウスからのデータの抽出です。

データウェアハウスからデータを抽出するには、ＳＱＬという言語を使って、さらにデータウェアハウスの構造を知って、データを取り出して、分析するという作業が必要になります。 Ｒ－ Ｏｌａｐは、このＳＱＬがわからなくても、またデータウェアハウスの構造がわからなくても、 データを取り出すことができるツールなのです。

通常のＲ－Ｏｌａｐでは、アイコンを使って、抽出ができます。 データウェアハウスのデータ項目が、 その会社のビジネス用語に変換されて、アイコンになっているのです。

データウェアハウスで は、基幹系システムのデータに依存したり、あるいはシステム開発したＩＴ会社のレベルにもよるのですが、 あまりビジネス的なシステムになっていないのが現実です。 たいていのＩＴ開発会社は、 コンピュータ(ハードウェア)の導入やシステム(データウェアハウス)の開発には熱心なのですが、 クライアントのビジネスには無頓着であったりすることが多いので、ビジネスと乖離していることが多々あります。

これらのギャップを埋めるのが、ＢＩツールであり、それがために、 ＢＩツールはＢＩツールを提供している会社やＩＴベンダーに開発を依頼するのではなくて、ＩＴコンサルティング会社に依頼すべきものです。

Ｒ－Ｏｌａｐ ～ ＩＴコンサルティング

Ｏｌａｐは昨日のＭ－Ｏｌａｐと今日のＲ－Ｏｌａｐになります。

Ｒ－ＯｌａｐのＲはRelationalのＲです。 基本はデータウェアハウスからそのまま抽出するというツールです。

データウェアハウスからデータを抽出する場合、ＳＱＬという言語を使うのですが、このＳＱＬという言語はＩＴ部門の担当者ではないと、 使い こなせないものなので、Ｒ－Ｏｌａｐを使って、 マーケティング部門や商品企画部門などのスタッフでも検索・抽出・分析が可能にできるためのツールです。

ＳＱＬの書籍を買ってきて、勉強したとしても、ＳＱＬという言語ができるようになるだけなので、実際に使いこなせるようになるまで、 専門的な教育が不可欠です。 これは、たとえれば、英語の勉強をしたからといって、 すぐに英語でビジネスができるわけではないのと似ています。

ＳＱＬができるというのは、英語ができる、というのと同じで、ビジネスをするには、ビジネスの知識やセンスが必要なのと同じように、 データウェアハウスの構造が理解できる必要があるからです。

このギャップを埋めるのが、Ｒ－Ｏｌａｐです。