メイン

ITエンジニアの育ち方 アーカイブ

2010年09月29日

ITエンジニアの育ち方(1)

これまで、業務システムの作り方だとかプロセス設計法といった議論が主体だったのですが、非常に重要な問題として、ではいったいそれを誰が遂行してくれるのかというのが大きくたちはだかっています。要するに、そういうスキルをもったエンジニアの養成というのが課題になります。

昨日から、日本BPM協会で「情シス若手勉強会」というのを立ち上げたので、この機会にそこらあたりを考えていきたいと思います。ここでITエンジニアと言っているが、皆さん、おそらくそれぞれ勝手にイメージを抱いているので、ちゃんと定義しておかないとまずいと思うのです。

ITSSとかUISSといったスキル標準にはそれぞれの領域でのエンジニアのもつべきスキルが規定されているのでそうした区分けで見ている人もいるでしょう。しかし、これはいかにもシステム寄りでしかも細分化しすぎです。もっと大きな括りでかまわないと思っています。すなわち、ITエンジニアには、ソフトウエア開発エンジニアと業務システム構築エンジニアの2種類だけがいると考えます。

だいぶ乱暴かもしれませんが、広義にとらえてみればこうした区分けでもいいと思っています。前者のITエンジニアは、ソフトウエアというプロダクトやサービスをつくる人たちで、ソフトウエアといっても様々あって、業務パッケージのようなものから、ツールとかフレームワークのようなものまであります。別な見方をすると、顧客の依頼があってそれを受託して作るのではないということです。あるプロダクトを企画して設計してそれに従ってプログラミングするという開発です。

一方、後者の方は、業務システムを受託開発するという仕事のやり方の中のエンジニアのことです。ユーザの要求を獲得して、それにもとづく要件定義を行い、設計・開発するというスキルをもったエンジニアになります。さらに、システ運用・保守というエンジニアもここに含まれるでしょう。

プログラミングということに限っていえば、前者が自発的なコーディングであることに対して、後者は受身的なコーディングなのです。この差は大きく、よくプログラマーとひと括りで言いますが、このように性格がちがうのです。あきらかに自発的なコーディングの方がモチベーションが上がります。ですから、できるだけ、受身的なコーディングはしないというのが大事なことなのです。

別な面でみると、めざすところがちがうというか、利害の対象が違うというのがあります。システムを提案し実装し、それがビジネスに貢献することをめざす人材と、極論すればビジネスに貢献しようがしまいが関係なく、いい道具を作ることをめざす人材とは別物なのです。

世の中では結構こうした区分けと定義をしないで語る人が多く混乱してしまうことがよくあります。これから取り上げるITエンジニアの定義は、後者の業務システム構築エンジニアになります。ということで、ITエンジニアというと従来のようなシステム技術に寄った人材をイメージしがちですが、そうではなくてビジネス寄りのITエンジニアが対象になります。

ここで、タイトルが「人材の育て方」ではなく「人材の育ち方」としたのは、若手を集めて年寄が講義形式で教え込む方式はとらないということを意味しています。こうしたプッシュ型の教育はなかなか身につきません。重要なのは、自分の頭でとことん考えることです。そこの“とことん”考えるようにお手伝いし、ちょっとしたガイド役になるのが講師だと思います。しばらく、勉強会の進行に合わせてエントリーしていこうと思います。


2010年10月02日

ITエンジニアの育ち方(2)

自分の頭で考える

技術や知識を習得しようとするとき、本を読んだり、誰かに教わったり、最近ではネットで調べるというのもあると思いますが、それはそれでけっこうなことなのだが、それを単に鵜呑みにするのはやめた方がいい。そこから、自分の頭で一生懸命考えることが大事になってきます。

徹底的に考えぬくことです。そして、その結果として、I think that ・・・と言えなくてはいけません。According to ・・・は、あまり言わないほうがいいでしょう。受け売りでさも自分の意見のように言うのも考えものです。

特に注意しなくてはいけないのはITに関することです。というのはこの世界では3文字熟語に代表されるように、中味が変わらなくても新しいことのようにいう言葉が氾濫しています。最近はクラウドですよね。ちょっと前はSaaSなんて言葉もはやりました。

これは、ITベンダーが自分たちの商品を売らんがために煽っているだけのものがほとんどのような気がします。こうしたことは、ITに限らず売り手の論理として本来的にもっています。それを買い手がたいした評価もせずに受け入れてしまうのです。

そこでよく陥る間違いは、世の中でこんな者がはやっているからそれを入れるんだと思ってしまうことである。例えば、さっきの例でいえば、クラウドを利用すること、SaaSを導入することと考えるわけです。このエントリーに関連して言えば、BPMをやること、あるいはBPMSを入れるということになります。

ここでは、気がつくと思いますが、目的と手段の混同がおきています。今言ったことはみな手段にすぎないわけで、本来の目的からはずれています。現実にはこうした誤謬があちこちで起きています。業務パッケージなんかもそうです。そのパッケージを入れることが目的となっているケースも多くあります。

ですから、思考の順番を入れ替える必要があります。すなわち、目的から考えることです。目的が設定されたらその目的を達成するために、どんな手段をとるかというアプローチになります。そう考えると、現にある手段は必ずしも目的に合致したものではないというのがわかる思います。

そうしたらどうするかは、自分の頭で手段を徹底的に考えるしかないのです。そして自分の頭から導き出された目的達成方策に対して、使えるツールやソフトウエアを選択するか、なかったら作ることになります。だから、自分のBPMを考えるということです。例えば、調達コストを20%下げるためのビジネスプロセスの構造はどう変えたらいいのか、それをマネジメントするにはどうしたらいかを自分で作ることです。

世の中でこんなものですと言われていてもそれをそのまま鵜呑みにするのではなく、自分の頭の中で考え抜いたコンセプトを貫くことだと思います。そのために大切な態度は「ビジネス視点、ユーザ目線」です。なぜなら、業務システムの目的はビジネス側からの要求によるものだからです。
  

2010年10月15日

ITエンジニアの育ち方(3)

人材育成にもマーケティングを

従来からの人材育成については、様々な取り組みがなされ、数多くのプログラムが用意されています。しかしながら、真に効果があるものはそれほど多くはないのではないでしょうか。なぜ、そうなっているのかを考えてみましょう。

それは、誰に対して、どんな人材にしたいがためにどういう教育を施していくのかという体系的なプログラムが未整備であるような気がします。これって、一種のマーケティングですよね。そうなんです、教育・研修のマーケティングができていないのです。それともう一つは、実践的でないといことに起因していると思うのです。

最初の問題は、まずは誰に向けて教育するかなのですが、その誰もいろいろな種類があります。年齢とか経験年数とか、あるいは職種や役職なんてものもあるかもしれません。ただ、専門教育だとこういうセグメンテーションが必要かもしれませんが、もう少し基本的なところになると、どういうモチベーションを与えるかが重要になってきます。そうなると次のような区分けが有効かもしれません。

Aタイプ:能力も高くて、やる気があり、よく働く人
Bタイプ:能力は高くはないが、やる気があり、よく働く人
Cタイプ:能力は高いが、やる気があまりない人
Dタイプ:能力も低く、やる気のない人

このそれぞれのタイプで教育・研修のやり方が違います。というか違ったやり方にしないと効果がでません。Aタイプの人はほっておいてもかまいません。Dの人は困った人ですが、何とかBかCに持っていかなくてはいけません。コーチングで指示に対して実行できる力をつけさせBにもっていくか、スキルアップ教育を施してCにまずもっていくという手もありますが、あまり期待はできないというのが実情でしょう。

さて、力を入れるべきは、BとCの人をAに引き上げる教育です。Bに対しては、自己啓発支援になります。あくまで自発的にやるように仕向けてそれを支援する形です。一方、Cの人は、やる気を起こさせるためのインセンティブを付与することです。単純に報酬というのもあるでしょうが、むしろ名誉とか承認の喜びのようなものを与えるのがいいと思います。

結局、マーケティングで言えば、顧客志向、顧客満足度向上をめざした教育プログラムを用意することが大切なのです。どうもまだ、一律で教育しているように思います。例えば、ある年齢層だけを集めるとか、決まりきった職種教育とかがなされているのではないでしょうか。

それは、おそらく教育する側にほんとうに人材を育成したいという切実な思いがなくて、単に義務感だけでプログラムを設定している現状もあると思います。これからは、もう少し、従業員個人個人のスキルレベルやキャリア、コンピテンシーなどを勘案したきめ細かい対応が望まれます。

2010年10月19日

ITエンジニアの育ち方(4)

教育は実践的でなくては

前回、効果のある教育になっていない理由として、マーケティングの概念がないのでそれを持ちこむべきだというエントリーをしたが、もうひとつ実践的でないことも同時に問題であると指摘した。そのことについて考えてみる。

研修や教育の基本がどうしても座学中心になります。それは、簡単だからです。何かを知っている人を連れて来て、知っていることを話してもらえばいいのです。しかし、それは教えてもらうほうからしたら、自分の知りたいことと違っていたら教育の意味はありません。

ここで少し大げさな言い方ですが、教育の目的は何でしょうか。個人を成長させるというのもあるかもしれませんが、教育を施しているその組織体が生き延びるためにあります。国が教育を行っているのは国が亡びないためです。そう考えるともっと真剣に教育に取り組んでもいいように思います。

ちょっと脱線してしまいましたが、座学だけではなく、OJT(On the Job Training)があるじゃないか、これは実践的だという反論があるかもしれませんが、実戦に放り込むからといって実践的でしょうか。いまのOJTは放置プレイ(すいません下品で)になっていやしないでしょうか。昔のように、面倒みてあげるほど人的余裕がないというのが現状だと思います。

そして、何よりも重要な要素が自発的かどうかです。何であれ、無理やりやらされているうちは効果は期待できません。自らが学びたい、知りたいという気にならなければ身に着かないということです。実践的な教育もこれが前提です。

さて、その実践的であるといことの意味はなんでしょうか。ここは、ITエンジニアの人材育成ですから、ITに関する知識を覚えるとか、システムの機能を勉強するとかは実践的ではないでしょう。そうではなくて、実際に開発するとか、設計するとかといった現実業務に近い動作を通じて学ぶことだと思います。

さきほど自発的であるべきと言いましたが、いまできていないことを自分の頭で考えて、自分の手でやってみるということが自発的であるところだと思います。これは、本当の実務では危ないから、研修でチャレンジしてみるということです。

別の側面で実践的であるということを考えると、教育・研修で得た結果がどうも精神論的で意欲論であるような気がします。どういうことかというと、たとえば、問題解決型研修などで、その課題解決策を立案するわけですが、それが、「○○について理解してもらえるようよく説明する」とか「○○に関する相談窓口を設置する」、「○○についての検討会を立ち上げる」といった類いの解決策をつくります。

これって、答えになっているでしょうか。だいたいにおいて、最初は勢いよく始めますが、続かないことが多いのではないかと思います。ですから、実際の仕組みや仕掛けに落として、それを運用するところまでやらないと意味がないのです。特に、ITエンジニアはそれを作るのが仕事ですから、中途半端なところで終わるような研修では、それこそ実践的ではないと言えるのです。


2010年10月26日

ITエンジニアの育ち方(5)

研修の進め方

さて、だいぶ前置きがながくなったが、実践的な研修の進め方についてみていきましょう。だいたいの進行は次のようなことになります。

1.問題の発掘・認知し課題を設定する
2.その課題に対する解決の方向性を探る
3.ビジネスの構造を考える
4.プロセス志向とはどういうことかを学ぶ
5.ビジネスモデルとビジネスプロセスの関係を知る
6.ビジネスプロセスを構造化してみる
7.業務プロセスの設計作法を身につける
8.実習(ビジネスモデルービジネスプロセスー業務プロセス設計)
9.プレゼンテーション(自分で設計したビジネスモデル、プロセスを説明する)
10.自分たちの役割と使命を確認する

こうした研修のポイントは、最初のところでも書いたように、覚えることではなく自分の頭で考えることであり、実際に設計したり、それを発表して、理解してもらえるかといった実践的なものであることです。

このように業務プロセスを設計できて、ユーザに向かってこんなプロセスにしましょうという提案ができるというのは、これからのITエンジニアのもつべき重要なスキルでしょうう。それを、研修をとおして実地にやるわけなので実践的と言っているのです。

ところで、もうひとつの狙いがあります。ここでの効果は実務的なスキルの習得をあげていますが、実はもっと一般的なスキル、ビジネスパーソンとして持つべき基本スキルの習得もしようじゃないかということです。それはどんなもかというと、「「日本で最も人材を育成する会社」のテキスト」(酒井穣著 光文社新書)に出てくる技術スキル、対人スキル、概念化スキルという3つのスキルのことである。

技術スキルというのは、特定の業務を遂行するのに必要な知識や技術で、対人スキルとは、ときに衝突することがあっても、長期的に他人とうまくやっていくことができる力です。3つ目の概念化スキルは、あまり言われないのですが実は重要なスキルだと考えています。

そのスキルとは、複雑な物事をシンプルに理解する力で、カオスに思える物事の中に何らかのルールや共通項を見出すスキルです。日本人があまり得意ではないことではないでしょうか。しかし、業務システムなどを考える上では必須の能力です。

こうした、一般的なスキルもこの研修で身につけることができたらいいなあと思っています。さて、これから、アジェンダに従って個別に内容を議論していくことにしましょう。

2010年11月02日

ITエンジニアの育ち方(6)

問題を発掘・認知する

最初のセッションは、「問題を発掘・認知し、課題を設定する」ですが、ここでは、問題を発掘・認知するまでを議論します。これは字句の通り、まずは自分が普段不満に思っているあるいは、悩んでいる問題を書き出すことをします。問題点というのは、簡単に言えば理想と現実とのギャップのことですから、理想をもっていないひと、考えていない人は問題点がありません。

そうした問題点をメンバーの人たちで出し合い、それを整理していくわけですが、ただ漠然と問題は何ですかと聞いてもなかなか出てこない場合もありますし、範囲が広すぎて拡散してしまう場合もあります。そんな時は、範囲を決めておくとか、だいたいのテーマを決めておいてそれに対する問題点を挙げていくというやり方でもかまいません。

今は、若手のITエンジニア、それも業務システムのITエンジニアを対象としていますので、その人たちの問題点はおおかた次のようなエリアの問題が抽出されてきます。このエリアごとで出てきた問題点をグルーピングしてそれに問題点の名前をつけていきます。

(1) ユーザとの関係
(2) システムの構造や機能に関すること
(3) システムの作り方の問題
(4) 組織や個人のスキル

(1)のユーザとの関係では、ユーザから要求獲得がうまくできないとか、ユーザがまともに対応してくれないとか、要求をなかなか出してくれないとかといったシステムに対する意識が低いことなどがあげられます。

(2)の問題は、部門ごとで勝手にシステムを作ってしまうので部門間の連携ができなかたりというサイロシステム化とか、ユーザ要求にちゃんと答えられていないので結果使われないとか、ビジネス環境がどんどん変化しているのにシステムが追随できていないといったことが出てきます。

つぎに、そのシステムの作り方にも問題があって、よくあるのは属人化してしまい、その人だけがわかっているとか、プロジェクトの最後の方は人に依存した開発になってしまうということが上がってくる。それと、ユーザ要求をつなげるべき業務プロセスが書けないという設計時の問題も横たわっている。

最後は、組織や人の問題で、ここでも属人化というか組織的な対応ができていなくて、個人にたよってしまうのだが、その個人にしても業務知識が乏しいのでどうしてもシステムに寄っていってしまうという傾向が指摘される。

ざっと、こんなふうな問題点があがってきます。もちろん個別にあたっていくともっと違ったものが出てきますが、この時点であまりディテールに突っ込む必要はありません。要は、ある程度抽象度を上げた重要な課題が設定できればいいのです。

ということで、問題点のグループは、「要求獲得がうまくできない」、「ユーザの意識が低い」、「システムがばらばら」、「システムが役にたっていない」、「業務フローが書けない」、「属人的な開発」、「業務知識がない」、「組織的対応ができない」といったところでしょうか。

次回は、ここから重要課題の設定を行っていきます。
   


2010年11月09日

ITエンジニアの育ち方(6)

重要課題の仮設定

前回は、ランダムに出してもらった問題点をグルーピングして、少し抽象度の高い表現で括って行きました。今度は、そうした問題点をさらに絞っていって重要課題という形で設定していくことを行います。

そのやり方は、それぞれの問題点の因果関係を書き出していきます。つまり、原因と結果の関係線を引くわけです。そうです、ロジックツリーとも言われますが、この問題の原因はどこの問題から生じているのかを追いかけます。問題点を丸で囲んでおいて、矢印でつなげていけばいいでしょう。

前回の例で言えば、「要求獲得がうまくできない」のは何が原因なのかと問うわけです。「ユーザの意識が低い」とか「業務知識がない」といったものが該当することがわかります。また、「システムが役に立っていない」のはなぜだろうかと考えると、「システムがばらばら」、「業務フローがうまく書けない」、「業務意識がない」、「要求獲得がうまくできない」など多くの原因がでてきます。

ここで、重要な課題とは単純には線の出入りが多いものとなります。多くの問題点の原因になっている、あるいは結果になっていることがそれにあたります。それと、もうひとつの見方は線がループしているかどうかをチェックすることです。

つまり、それが原因でおきた事象がまわり回って自分のところに来るというものです。例で言うと、「ユーザの意識が低い」ので「要求獲得ができなく」なり、「役に立たないシステムが作られる」、「システムが役に立たない」ので、「ユーザはシステムに対する意識が低下」してしまうという負のループです。

こうした評価をしていくと、例で言えば「ユーザの意識が低いので、要求獲得がうまくいかず、作ったシステムが役に立っていない」という課題が上がってきます。次に、もう少し絞った表現にします。課題が拡散してしまうのを防ぐことと、精神論、意欲論に陥らないためです。

それから行くと、ユーザの意識が低いというのは、精神論的なことのようであり、意識が高くなったらそれで多くのことが解決するというわけにはいかないのではずした方がいいことがわかります。

次に、今までは○○が不足しているとか○○ができないといったネガティブ型での表現になっていますが、課題設定ではそれを逆にしたポジティブ表現に変換します。すなわち、「ユーザから要求を獲得して、役に立つシステムにするには」といったものになります。

これは、仮の設定課題ですので、さらに精査して最終化していきます。これは次回に。
  

2010年11月16日

ITエンジニアの育ち方(7)

重要課題の最終化

前回、重要課題を「ユーザから要求を獲得して、役に立つシステムにするには」というふうに設定しましたが、これはまだ不十分です。もう少し、その内容を深堀し、具体化していきます。

例えば、この表現では、ユーザとか役に立つとかシステムといった言葉が書かれていますが、その定義をきちんとしておく必要があるわけです。この言葉はちょっと抽象的ですから、そうしておかないと人それぞれで解釈が違ってきます。

ということで、まずユーザとはどこの誰のことなのか、誰のために役立てればいいのかという観点で攻めていきます。具体的には、経営者なのか、事業部長とか部長なのか、業務担当者なのか、はたまた顧客なのかといった問いをしてみます。

次に、そのユーザの要求とは一体何なのか、ユーザが役に立つと考えているのはどんなことなのかといったことになります。単なるコストダウンなのか、はやりの見える化なのか、新規顧客の開拓なのかといったことが浮かびますが、それらは何となく個別プロジェクト目標みたいで、もうちょっと概括的な表現がいいように思います。

そして、ここでいうシステムとはどんなものを指しているのかを検討します。システムと言っただけでは範囲が広く、ITによる自動化システムなのか、コンピュータの構成のようなことを言っているのか、業務パッケージのようなことを言っているのかがあります。

さて、こうした深堀、具体化でどういった最終課題になっていくのでしょうか。ユーザの問題では、顧客というとちょっと遠くなるので企業内のユーザというふうに考えた方がいいと思いますが、まずは経営者はユーザでしょうか。どうもITを使ったシステムが対象ですから、そこに対する経営者の関わりは小さいと思います。

では、業務担当者でしょうか。確かに、足腰をしっかりすることが大事で、そのためにも業務担当者の役に立つものが望まれるというのは間違ってはいませんが、部分最適に陥る危険性がありそうで、全体感が要りそうです。そう言う意味で、事業に責任を持っている人がユーザというのが妥当ではないでしょうか。

そして、役に立つとはということに関しては、先に言ったように概括的な表現ということになると、ビジネス上に何らかの利益をもたらす、すなわち事業に貢献できることが役に立つことにつながりそうである。

システムについては、単なるITシステムだけではなく、また一部の業務アプリケーションでもなく、包括的な仕組みを想定すべきであろう。ということで企業の基本的な実行プラットフォームということで業務システムというものがよいのではないでしょうか。

こうした考察により、最初に設定した課題を最終化すると「事業に貢献できる業務システムを構築するには」ということになります。このように、詳細化と概念化のバランスをとりながら、できるだけ分かりやすくし、あいまいさをなくすことが大切になります。

2010年12月11日

システム屋の解体

佐藤治夫さんの「ダメなシステム屋にだまされるな!」ではないが、ダメなシステム屋がけっこういるとなると、そうしたシステム屋を再教育する必要があるとか、がんばってくれよという議論になるが、どうもそれでは限界があるように思える。

ではどうしたらいいのかになるが、それにはシステムの作り方がどう変わってきたのか、あるいはどう変わっていこうとしているのかをみていく必要があると思うのです。そのことは、従来のやり方ではもはや今の問題を解決できないということを暗に言っているわけです。

もうひとつ、いま問題があるのかという認識が共通化しているかという「問題」も同時に提起していますが、これは佐藤さんの本にも書いてあるし、経営者のIT部門およびITベンダーに対する信頼度のなさ、CIOの存在の希薄さでほぼ説明がつくと思うので、おそらく皆さんの共通認識だと思います。

議論というのは、事実認識と前提条件の置き方がすごく重要で、そこの齟齬でいったい何を議論しているのかが分からなくなることがしばしば起きます。ですから、従来のやり方には問題があって、そうした問題があると言うことは共通化されているという前提で議論してもかまわないでしょう。

それでもこういうとき、うちではできているとか、あの会社はやっているじゃないかという反論があったりしますが、それはあくまで特殊な例になっているかが問われるべきだと思います。どこまで6割の層に浸透するかである。そういう意味で、今のままではまずいのではないかというのが大方の問題認識という点はメジャーではないかと思っています。

さて、ではどうしたらよいのでしょうか。どうもいまの問題を解決するには、やり方を変えることと、それができる人を新たに育成することにつきるのではないでしょうか。ここができていないと思うのです。いまの延長で何とかしようというあがきが感じられます。

それで、やり方は別のエントリーで書いているので、もう一方の人材の話です。ここでの提案は、従来のシステム屋をプロセス屋とIT屋に分けたらどうかと言いたいのです。少なくとも今はこれを十把一絡げにしています。簡単にいえば、上流から下流まで同じようにシステム屋と呼んでいます。

すなわち、ビジネスモデルからビジネスモデル、ビジネスプロセス設計ができる人と、それを受けて実装できる人に分けて考えてみたらどうかという提案です。ただ、ここで注意しなくていけないのが、境界をはっきり線引きしてしまわないことです。ある部分は重なり合う、溶け合うところを持つことだと思います。

それは、簡単に言えば、相手を知ることだと思う。実装する人は上流のところを、ビジネスモデルを書く人はどうやって実装するのかということについて、お互いを詳細ではなくてもいいか概略どんなことかを知ることから始まると思のである。この続きはまた書きます。

About ITエンジニアの育ち方

ブログ「mark-wada blog」のカテゴリ「ITエンジニアの育ち方」に投稿されたすべてのエントリーのアーカイブのページです。新しい順番に並んでいます。

次のカテゴリはオペレーション志向です。

他にも多くのエントリーがあります。メインページアーカイブページも見てください。

Powered by
Movable Type