Kodawari日記

人の信頼度などはどう決まるのか？
これは結構不思議。

たとえば、大手一流企業に勤めていると、それだけで信頼されたりする。
フリーになると特にそれを感じる。

何かの本に書いてあったが、ある学者が発表したとき、民族衣装で行ったときは誰も見向きもしなかったが、
きちんとしたスーツを着込んで同じ発表をしたとき全く反応が違った・・・とのこと。

同じレポートでも活字になってしまうと妙に信憑性が増す。

書籍になってしまうとなおさら。

早い話、ほとんどの人は物の判断を周辺から行っているのではないだろうか?
確かに、本質をすぐに見極めるのは難しい。
そのため、様々な経験、情報から判断しているのではないかと思う。

となれば、それを逆手にとってしまえば、信頼を得ることが可能ということになる。
活字化、名の通っている人からの紹介、きちんとした身なり。
著名人との交流などなど、いろいろ考えられる。

たとえば、facebookなどで著名人と一緒に写っている人たちがいる。
そんなに知り合いではなくとも、一緒に写っているだけで、なぜか信頼度が増してしまう。

まぁ、きちんと付き合えば、化けの皮がはがれるのは必至であるが、
一般へ認知させるのであれば、この方法は有効。

売上ランク１位とか、他にも方法はいくらでもある。
（これなんか、集中的に自分買いをしてしまえば可能なのだ。）

それだけ「本質」を見極めることが難しいということ。

これをビジネスに生かせないだろうか?

あるところでのお話。

IT部門のモチベーションが上がらないとのこと。

話をきいてみると、ほとんどの部員は
IT＝システムのお守
という意識が強いようです。

確かに、トラブルとなると夜中でも呼びだされる。
トラブルで怒られることはあるけど、ほめられることはない。
（営業などは売上上がればほめられるのですが・・・・）

確かに良く聞く話です。
IT部員を上記のように扱っている経営の方も多く見てきています。
IT部門の役割を分解すると

・設計
・開発
・運用

になります。

で、ここで重要なのは実は「設計」なんです。

「設計なんて要望を整理するだけじゃないの?」

確かにそういう人も多いです。「要件定義」だけやってあとはお任せ。

実はこれが大間違い！

この「設計」という作業。結構奥深いのですよ。

事業計画、将来の方向性まで考慮することが非常に重要。
さらに企業として差別化する部分か、そうでないかでも方針が異なります。

そこまで考える作業なわけです。

（IT設計を家の設計におきかえるとわかりやすいと思います。
　将来増改築をしたければ木造軸組み、海外の輸入窓、ドアならやはり２ｘ４という構造。
　将来子供が増えるのであれば、こういう間取りに・・・・
　
　というように、いろんな目的により設計が変わってきます。）

これにより、後ろの開発、運用が大きく影響を受けます。

IT依存の高い企業であれば、企業生命を左右しかねない部分。

こう考えると、CFO（Chief Finance Officer：財務最高責任者）並みに重要なのですけどね。
だからCIO（Cheif Information Officer：情報最高責任者）が必要なわけで。

でも、ほとんどの企業でこの（真の意味での）CIOはいないようですね。
 私が「この人はCIOだ」と認める方はごくわずかです。

ですが、どうすればできるか？どういう人材を選び出すか？
そのノウハウは「ココ」あります！

昨日はベンチャー企業でレクチャーしてきました。

題材は「事業におけるITの重要性」

現代社会人の必須要件は次のように考えられます。

Finance　財務会計
IT　情報処理技術
Language　言語
Marketing　マーケティング
（頭文字とってFILMと覚えると簡単でしょう。）

FLMはわかりやすいのですが、Iがわからない人が多いです。

というか、ピンとこないのでしょうね。実態が見えにくいから。
「あ、そこのところはシステム部門でお願い!」って人が多いわけで。
「システム屋さん」という言い方良くする人もいますよね。

実はIT力には2種類あり、
１）IT技術の応用力
２）情報処理（業務処理）設計能力

１）はわかりやすいです。たとえば、データ解析にExcel使うとかもそうですし、スマホ技術、AR、クラウド・・・
　いろいろあります。

実は２）が重要。
「どう情報（業務）を処理させるのか？」
早い話業務設計の話そのものです。

たとえば、一人で業務を行う場合、そこまで業務分担しなくてもできます。
ですが、複数の人数で実行する場合、それぞれの役割を決めたり、伝達するメッセージを決めたりする必要があります。
つまり、多くの処理を行おうとすると、それぞれを細分化したりする必要があるわけです。

場合によっては同様の処理を一括処理させたりすることも考えます。

コンピュータシステム設計ではこれは当たり前の世界。その役割、メッセージなどはきちんと定義付けする必要があるということ。
なにしろコンピュータの世界は融通効きませんから。

このような訓練を受けていると、実際の業務でも役に立ちます。
実際業務フロー図はシステム設計でのシーケンス図そのもの。

まぁ、早い話、業務全体の中に人間系システムと、コンピュータ系システムがあるだけの話で、両者を区別する方がナンセンスというわけです。

よくベンチャー組織が大きくなってきたときに業務が回らなくなることがあります。
この最大の原因が、このIT力不足です。
今まで少人数で、全部まわしていた。
人を増やしたときに、この業務設計ができないために、役割分担、責任分担があいまいで、いろんな問題を起こす。
結果非効率性を生んでしまう。

これを回避するには、やはりITを学ぶことです。
業務全体を俯瞰することでオブジェクト化＝クラス化＝抽象化を実施できる能力のことを言います。

これができるようになると、おのずといろんな本質が見えてくるのですけどね。

昨日の勉強会ではわかりやすいように比喩表現を使いました。
たとえば、システム構築を家やビルの建築におきかえたり。
　　（システム構築は家、ビルの建築に置き換えるとすごくわかりやすくなります。）

また、オブジェクト化のところは車の部品におきかえたり。
　　要件を満たすのであれば、車軸とホイールは一体化で削りだしで作っても良いわけです。
　　でも、それをやってしまうとホイールのサイズ交換は不可能・・・・
というような具合です。

わかってもらえたかな・・・・

若い人にはしっかりと理解してもらいたいです。
とにかく頭がまだ柔らかいうちに・・・。