情報システム部門/情報システム会社にとって重要な課題を挙げると、①データをどう戦略的に使うか、②コスト削減、③人材育成、この3点だと言われています。どれも重要な課題ですが、今回はデータの戦略的活用をからめて、強みとは何かを掘り下げていきたいと思います。　

現場の状況

　稼動中のシステムは質・量ともに増加し、ビジネス部門の要求は多岐にわたります。さらに、多くの新しい技術が提供される環境で、その中心に位置づく情報システム部門、および情報システム会社のメンバは、過去のような経験実績を積むことができない中で、ヘッドカウントを絞られつつも高い品質でのシステム運用を求められています。
　　　
　このような中で、普通にできていて当たり前で、少しでも問題が発覚すれば、IT系は業務を分かっていないと、一刀両断にされます。

　また、データ活用のポイントで、ビジネス部門や経営層から様々な要求が来ることもしばしばで、あちこちのファイルからデータを抜き出しては編集・加工する作業が発生します。いくらBI、ERPと言ってもいまだにExcelでゴリゴリ加工していることが多いのが現状です。ああでもないこうでもないというやり取りが増え、当然のことながら多くの工数を割かれることになります。

　先ほども述べたように、要員のヘッドカウントはぎりぎりまで削減され、パートナーもコスト見合いで減らされる方向にあります。そうすると一人で受け持つシステムの数が増え、以外の作業も膨大になり、今やらなくてはいけない日常の作業に埋没してしまうことになります。
　　　
　そうなれば、こうすればよくなるなど分かっていても改善に至らず、今後のことを考えて―、という思考が停止した状態になり、黙々と働くということだけが残ってしまうというのは、言い過ぎでしょうか。 　

何が強みか

　それなりの位置にいる内外の方々から、情報システム部門/情報システム会社のメンバはもっと業務に強くなり、ビジネス視点で考えることが必要だという発言をよく耳にします。
　　
　確かにそうなればベストなのですが、理想と現実は異なります。ビジネス部門とのローテーションが頻繁にあるだとか、IT採用があるなどによって状況は変わりますが、ほとんどの企業ではビジネス部門の方より、業務に詳しくなることは通常ありえません。
　　　
　では何が強みなのか。いつもビジネス部門の言いなりになっていなくてはならないのか。
　　　
　筆者が考える情報システム部門/情報システム会社の人材の強みは、まさしくシステム化する能力を持っていることです。もう少しわかりやすく言えば、プロセスをファンクションとして捉え、全体を抽象化・論理化する能力、データをモデル化して一望することができる能力を持つことです。これらは、IT系の人材でしかなし得ないことだと言えます。
　　　　
　もちろん、ビジネス部門の方と業務について会話できる知識を持つことは最低限必要ですが、IT側でしかできないことを強みにしていくのは、ごく当たり前のことです。

プロセスとファンクション

　通常、一連の業務の流れは、組織でぶつ切りになっています。組織の中にいるビジネス部門の方々は、自組織外のことより自組織内の業務に強いと言えます。さらに業務をプロセスとしてとらえていることが多く、そのままヒアリングすると、まずこうして次にこうしてという話になってしまいます。上流工程で、業務を明らかにする必要がある場合は、このインタビューの仕方は適していません。プロセスをファンクションとしてまとめ、組織の枠を外すという抽象化、論理化の手法が必要です。組織の枠を外せば、本当の業務のスタートとエンドが見えます。
　　　　
　また、プロセスは時間軸に沿って流れますが、時間軸の考えを取り去ることにより、ファンクションとしてまとめることができます。これが、プロセスとファンクションの違いです。

　プロセスはプロセス・フローなど手順書で表現され、ファンクションはDFD(Data Flow Diagram)で表現することができます。また、通常前者は組織に閉じた記述をすることが多く、後者は組織の枠を外した書き方をします。

_{Data Flow Diagramの例}

 
　組織や時間軸の考えを外すことによって、ファンクションの構成による全体像を明らかにすることができる訳です。これはIT人材にしかできないことであり、ビジネス部門の方にはできません。

　さらにファンクションを使ってDFDで表現すると、そのファンクション間でどんなデータが流れるかが明確になります。

データモデル 

　データは、それだけで独立したものです。新たにシステムを作り直す場合、例えば人事システムが対象だとすると、通常置き換えられるものを旧人事システム、新しく作り直すものを新人事システムと呼びます。

　しかし、データには旧データも新データもありません。データ移行するだけです。もちろん、新システムで今までなかったデータ項目が追加されることはありますが、基本的に項目類は引き継がれます。データ量は増えてはいきますが、構成内容としては基本的に変わらないということです。

　その考えから、DFDよりデータを取り出した時点で、システム構築の流れには左右されず、データ分析の作業を並行して実施することができ、データモデルを形作ることが可能です。ERモデル(Entity Relationship Model)を使用するのが一番分かりやすい方法ですが、筆者は中でも最も初期のPeter Chenの記述法が適していると考えています。

_{ある製造系企業のコーポレートデータモデル(ERモデル)}

 ERモデルと言えばデータベースの設計を思い浮かべる方が多いですが、ここではそのステップではなく、業務の流れをファンクションで表現し、次にデータの流れをDFDで記述し、さらにデータのつながりの全体感を書き表すためにERモデルを活用します。このレベルでの全社のERモデルをコーポレート・データモデルと呼びます。そのことからも、基礎であるモデル化技法が適していると考えているのです。　　　

システム分析全体観

　大阪の製造業・情報システム部門の方から「システム分析・3日間コース」のご依頼を受けたのが数ヶ月前で、日程調整の結果実施は今月中旬と迫りました。もともとトレーニング主体のビジネスではありませんが、重要なこのコースだけはご希望があれば提供することにしています。　

　日立SE時代にメソッド策定のチームで実践を積みました。DOA(Data Oriented Approach)の第一人者である堀内一先生に師事し、このメソッドの適用第一号である大阪の生保会社の担当SEをしていたこともあって、活用法について深く経験することができました。そのノウハウを基にワークショップ形式のトレーニングにまとめたわけです。

　日本オラクル時代には、当時の松下電器グループ向けに実施していました。ワークショップ形式なので、1回で4チーム、16名程度しか受講できませんが、200名以上の方が受講されました。結構タフな内容ですが、その後オラクル社内やHP主催で外部にも実施していました。

　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　_{システム分析の流れ}

　自分自身も3日間拘束されるので頻繁にはできないのですが、このトレーニングを望まれる大きな理由は「変わらない技術を身につけたい」ということからです。名うてのコンサルファームから中途入社してきたメンバも、このように実戦的で体系だった方法論を学んだことがない、と言っていたのをよく耳にしました。

　実装技術はめまぐるしく変化していきますが、IT人材の基本として持っていないといけないスキルは変わらないものだと考えています。クラウド化などにより、作らない時代になっても同じです。いかに情報を戦略的に使えるか、この一点に尽きます。　　　　

　裏を返すと、これができることこそ、情報システム部門/情報システム会社の強みだと考えています。　

　ベンダ系にしろユーザー系にしろ、ITにかかわる人材は、技術については貪欲ですが、処遇、特にお金に関することには淡白だと取られがちです。本当のところ、そこはとても気になる部分なのです。

■10年連続200本安打達成のイチロー

　今シーズンは少し調子が悪そうですが、10年連続200本安打の偉業を達成したイチローは、7年連続を達成したときこうコメントしています。

　「低迷するチームの中にいて、自分のマインドを保つために必ず守っていたのは、試合後、一刻も早くクラブハウスを出ること」

　しかしながら、この直後にチームメイトから総スカンにあい、信頼関係や自分の位置づけを取り戻すのに、大変苦労したというのは有名な話です。

　皆さんはいかがでしょうか？ 客観的に自身を見つめたことはあるでしょうか。また、仕事に生きがいや達成感を持っていますか？

　私の知る限り、なるべく早くこの環境（会社）から抜け出したい、と考えている人は結構多いようです。

　それはなぜなのでしょうか。

■旧態依然の人事制度

　ITエンジニアは、自分の待遇は気になるものの、制度の理解や知識はあまりないというのが、一般的かもしれません。

　しかしながら、自分の価値を認めさせたいなら、現状の制度や成り立ち、さらに世の中の動きなどを知っておく必要があることは言うまでもありません。

　高度成長期を駆け抜けてきた日本企業の取った方法は、いわゆる年功序列型の考えです。

　日本企業は、この年功序列の考え方をベースに発展してきました。年齢を重ねて人事等級が上がり、役職が上がると給与が増えるという考え方です。年令給などを中心に定期昇給があったのも、今では懐かしく感じます。

　成熟期に入り、ポジションが減少する傾向が顕著で、全員が昇格していくわけにいかず、年功序列は守りながら能力が上がると昇給し、モチベーションを維持するという職能資格制度を取ってきました。これらは、いわば上昇指向を前提とした考え方です。

　しかし、現在は上昇指向で競争を望む人は少なくなってきたようです。このような上昇指向をベースとした制度、キャリアパスがまだまだ多い現状でしょう。

　次に試行錯誤を重ねて、コンピテンシー評価や成果主義に走りました。

　ちなみにアメリカの場合は、職務等級制度という日本とは全く異なった考えを持って進んできました。誰にというより、ポジションにお金を支払うという考え方です。これは人種問題という避けて通れない課題から出た考えです。

■成果主義とキャリアデザイン

　では、成果主義はうまくいっているのでしょうか。

　仕事柄、よく人事や人材開発の方と話す機会があります。その中で結構耳にするのは、「うちは処遇制度としてMBOを使っている」というお話です。

　以前もお話ししましたが、MBOとは「Management By Objectives」の略ですが、本来は後ろに「and/through Self Control」が付くのをご存知でしょうか？

　MBOとは「期初に年間目標を出して、期末に出来たかどうかの達成率で評価すること」とだけ考えている方はいないでしょうか？

　キャリアデザインとは、将来自分がどうなりたいかを思い描き、そのために何をしていけばいいかを計画実行していくことです。PDCAを回していかなければなりません。

　その中の一番短期のサイクルとしてMBOを位置づける必要があるのです。1年1年で評価されて終わってしまうような途切れた考えではなくて、次の1年に、さらに次の1年に、また将来のキャリアにつながっていく必要があるのです。

　このように、本来あるべき成果主義の考えは、1年1年ぶつ切りになっているのではなく、将来のキャリアにつながる年間目標と、それに対するアクションが求められ評価されるわけです。そして同時に、フィードバックによる仕事の質のマネジメントと、質の理解を通じた次へのアクションが求められます。したがって、よくあるような目標の達成だけの管理は、あまり意味がないと言えます。また、数値だけではなく期待成果、期待役割を明らかにする必要があります。「成果主義≠結果主義」をよく認識する必要があります。

■その中でのIT人材の状況

　IT人材自身は、その中でどういう状況なのでしょうか。インタビューしてみると、次のような意見が出てきます。

• 自分のやりたいことをやりたいが、自社の中に将来像を描けない
• ポストが少なすぎて、上司の年令になったときに、その位置につける可能性は低い、従って給料も上がらないだろう
• 管理者と自分の給料を比べて、そのくらいの差なら責任を負うことや、残業代がつかなくなることを良しとしない
• 評価は上司が行うが、その能力があるか疑問だ、また人によって評価結果が大きく異なるので、評価指標自体や方法が信用できない

　そういう話をしている人々も、やる気があって前向きなタイプと、給料分だけ仕事をすればいいという後ろ向きタイプに二極化しています。

　前者が1～2割しかいないというのも厳しい現実です。

■なぜ日本のIT人材のレベルが落ちてきたか

　少し話の方向を変えますが、今まで日本のソフト産業を引っ張って来られた人々は、大変な苦労をされているはずです。しかし、世の中は変わりました。こうしている現在も急速に変化しています。それなりにうまくいっているからいいじゃないかというような現状肯定型では、とてもこの変化に対応できません。

　結果として、OSはマイクロソフト、ネットワークはシスコシステムズ、データベースはオラクル、ERPはSAP、挙げればきりがありませんが、日本のソフトウェア産業の基盤は、ほとんどすべて外資に牛耳られてしまいました。昨今では、クラウド・コンピューティングを筆頭に、さらに海外発の新しい波が押し寄せています。

　また、それどころかエンジニアのスキルレベルが極端に落ちて赤字プロジェクトが多発し、企業に甚大な損害を与えています。だからプロマネが重要だと、一部ではまた偏った手段ばかり追いかける方向になったりしています。

　後進を育成することを考えてこなかった、また育成する方法が分からない、なぜかというと自分もしっかり育成してもらったことがない、こういう中堅以上のIT人材が多いのは、いろいろコンサルティングしてきた筆者の実感です。ベースをしっかりと習得したIT人材であって初めて色々なことを省略したり、柔軟に対応できるのです。現実にうまくトレーニングできていないのです。

　さらに、ユニークな考えを排除し「どこを切っても金太郎飴型人材」を求めてきたのは、高度成長期の大量採用の中での人材要件から来ているとも言えます。

■IT人材はどこに向かえばいいのか

　ネガティブな話が続いていますが、少なくともその中にいるIT人材の皆さんには、この状況をしっかり認識してもらいたいと願っています。

　これらの話は、時間をかけて積み重ねてきた結果であって、簡単に感性で切り返せる内容ではありません。

　この世界で生き抜いて実績を挙げていく、そして仕事に達成感とやりがいを持って進めていくには、深い認識と理解、高い能力が必要です。そして、自分はどうなりたいかを常に強く思い続けることです。

　当たり前ですが、なりたい目標を持たない限り、そうなることは絶対にあり得ません。

　60歳で定年になるまでの気力と体力の充実した期間を、最低週に5日間、1日8時間以上も仕事に費やすのです。平日は仕事をしていないときは、ほとんど食べているか寝ているかでしょう。その重要な期間に、仕事に達成感を持ってモチベーションを上げてやっていくかそうでないかは、上下の違いになります。

　自分を高めることは、ライフプランの充実に直結するのです。

■IT部門の置かれている状況

　筆者は、人材育成の仕組みづくりのコンサルティングをしていますが、仕組みづくりを推進する方だけではなく、できる限り経営層や現場の社員の方々ともお話しする機会を持つように心がけています。また、今回のように筆者の経験実績を買われて、社外の状況を聞きたいと望まれる企業も数多くあります。

　もちろん、講演することはメインビジネスではありませんが、時間の許す限りお応えするようにしています。

　なぜなら、IT部門の方々は外部と接する機会が少なく、常に情報不足、刺激不足の状態であることを理解しており、筆者の話が役立つことを何度も実感しているからです。

　ユーザー企業のIT部門は、仕事以外にいろいろな意味で難しい側面を抱えています。たとえば次のような事柄です。

• 社内的に、IT部門の位置づけはコストセンターであり、しかもシステム化費用やシステム運用費など多くの経費を使うやっかいな部門であると思われている。

• 近年、システムの構造が複雑になり、ますます手がかかる傾向が強いが、人件費などを押さえられることになっており、部門員の多忙さは激しくなり限界に近づいている。これらに対して、特に経営層の理解不足が顕著である。

• IT部門員の多くは、IT系の仕事がしたくて入社したわけではない場合も多く、たまたま配属された上に仕事柄異動が難しく、長くIT部門に属している状態である。

• IT部門員の処遇について、全社のものに合わせるのが難しく、情報子会社化を検討することや、実施している企業が多い。多くは本体からの出向になるが、将来の見通しが立ちにくく、社員としての位置づけが中途半端になっている場合も多い。

• IT部門の仕事自体が、他の部門から見てうまくできていて当たり前で、少しでもシステム障害など不具合が発生した場合の影響があまりにも大きく、責任重大になっていて部門員に大きなストレスがかかっている。

■過去の成功と、行き止まり感の強い現在～シニア層、ミドル層、エントリ層

　IT部門を構成される方々は、3つの大きなグループに分かれるのではないかと考えています。1番目を、仮にシニア層と呼びましょう。

　シニア層は、IT部門長を含め管理職でも年齢が上で、大抵は自らの経験に自信を持っている方々です。IT創成期は、メインフレームを使って人の行っている仕事をコンピュータ化するだけで、かなりの効率アップを実現することができました。また、それが一番大きな目的でもあったのです。技術的にも今ほどの広がりはなく、1人で何役もこなすことが可能でした。従って、全体を見渡すことができたわけです。しかも、IT関係の仕事をしている人はまだまだ少なく、花形といわれる中での達成感のある生産的な仕事をこなしていました。

　2番目をミドル層と呼ぶと、そこにはシニア層の方々に、どちらかというと師匠と丁稚のような関係で鍛えられた方々が存在します。技術的にも広さと深さが増して、とてもシニア層の方のような経験はできませんが、想像することも含めて前向きに捉えた仕事の仕方ができましたが、新しい技術が頻出するようになり、ついて行きづらくなって、マネジメントの方に偏っていく傾向にありました。

　シニア層の方々は役職者で、ミドル層も続く役職ですが、上のポジション数が限られていて、その位置に付けるかどうかという不安が徐々に頭をもたげてきました。役職が上がらないと給与が上がらない日本式の処遇制度が主流の真只中にいたわけです。そして景気後退で、リストラ対象になったのは、記憶に新しいところです。自分の身を案じるのが精一杯で、部下の育成など考えることはできないわけです。

　3番目をエントリ層と呼びましょう。ここには、ITというキーワードを頼りに、過去の成功のイメージだけで参加した方々が多く存在します。現在は、技術的にも深く広くなっており、IT戦略が企業にとって生死を分ける位置づけにもなっています。そのような中でいくら多くを経験したくとも、1人の人間ができる範囲はおのずと限られてしまいます。つまり、経験を重ねて今の位置づけになったシニア層、もしくは多くを経験できなくとも、何らかの役職についているミドル層とは、かなり落差のある位置づけです。しかも、シニア層ほど広い経験を持たない、言うなれば経験実績の面では中途半端なミドル層に指導され、かなり中途半端さが増幅されたようになっているといっても過言ではないでしょう。

■絡み合った不安

　この3つの構造の中で、シニア層の方は自分の経験や実力と比較して、ミドル層以下の方々について、「いつも待ちになっていて自主性がない、文句だけ言って建設的でない、自分が若いころは上を押しのけてでもやったものだ」と言われるのをよく耳にします。また、ミドル層の方々は、自分の立場を守ることと、上と下を見てなるべく「事なかれ主義」に徹するという傾向があります。それに対して、エントリ層の方々は、企業の考え方の変化や技術の進歩についていけず、 実際にどうしていいか分からないのが実情でしょう。

　会社が明確に何かを提供することや、考えるための環境を提供するのは至難の業です。一方で、ここ数年自殺者やうつ病の方が急増しています。IT 関係も例外ではありません。筆者の感覚では逆に顕著に思えます。それぞれ理由は違うのでしょうが、ミドル層とエントリ層の方々がその大半を占めるようです。

　よく言われるIT関係職の低い待遇や勤務時間の多さに、さらにこれらの現象が追い討ちをかけて、IT関係に対する学生の人気は急激な落ち込みを示し、企業におけるITの重要性と逆行して深刻な人材不足に陥っています。

　これらの状況の中で人材に関して考えると、IT関係特有の現象が出ていると言えるかもしれません。過去はもてはやされたIT関係職の栄枯盛衰が、まともに現れているようです。

■客観視の重要性

　今回の講演に話を戻します。講演に際して、筆者は事前に詳しく社内事情を聞いたわけではありません。逆に聞きすぎると偏った話になる可能性が高いので、あえて必要最低限しか聞かないようにしています。また、講演を聞いている皆さんにとって、先にあげた状況の中で、

　「一体自分の将来はどうなるのか、何を考えどう実行していけばいいのか」

　ということが一番の知りたい答えであり、最も不安なことなのです。

　一番真剣に身を乗り出すような反応があったのは、次の内容を話したときでした。

　企業の魅力とは

• Visionや理念、戦略の共感
• 会社の基盤に対する安心
• 事業内容への興味
• 仕事の醍醐味
• 組織風土との合致度
• 人的な魅力
• 施設や環境
• 制度や待遇への納得感

　上司の魅力とは

• 情報提供
• 情報収集
• 判断行動
• 動機形成、助言

　職場の魅力とは

• 顧客接続（接点、反応確認）
• 目標達成
• 意欲相乗
• 業務効果（効果的な業務プロセス、効果の追求）

　自分の周りの環境は、これらの中でどのくらい過不足感があるのか。また、自分は何に魅力を感じて今この会社で働いているのかを客観視することは、今後を考える上で大変重要です。自分の置かれている状況、また自分自身を客観的に捉えることができなければ、将来を見据えるどころか不安を拭い去ることはできません。

　自らの人生設計をよりよいものとしていくには、Goalを明らかにする努力をするとともに、しっかりと現状を見つめることも重要でしょう。

データベースが得意というだけでは不安！？

　前回は、ITプロフェッショナルの道をさらに究めていくには、「基礎的な技術知識をしっかりと身に付ける」、「会社の外に出て、自分の可能性を広げる」といったことを述べました。

　また、多くの方は、ITエンジニアならば、もっと広い領域で活躍したいと考えているでしょう。しかし、経験もなく自信が持てない、そういった思いもあると思います。

　実は筆者も、日本オラクルでの執行役員時代に様々なエンジニアと会話しましたが、「自分はデータベースに関しては、人に負けない知識とスキルが付いたという自負があるが、それ以外のことは知識や経験が少ないため、今後もIT業界でやっていけるかどうか時々不安になる」といった相談を持ちかけられることがありました。確かに、データベースのことばかり専門的にこなしていると、システム開発全般を担当しているエンジニアや、ユーザー企業へのコンサルティングを担当している他社のエンジニアと比べて、対象領域の広さの違いに「自分はこのままで大丈夫だろうか？」と不安になるのかもしれません。

　業務システム全般の企画／設計や、ユーザーへのコンサルティングを担当する場合、これまでよりも活躍の場を広げる、あるいは上流領域に活躍の場を移すことになるわけですから、経験のない自分が「本当にできるのか？ 大丈夫か？」、また「そんな場が自社にあるのか」と不安になるのも無理はありません。

　しかし、そうした道を志す方にまず言いたいのは、「データベースの専門家だからといって、憶することはない」ということです。むしろ、現在主流のデータベース技術、つまりリレーショナルデータベースに精通したエンジニアには、他のエンジニアにはない強みがあります。

データベース・エンジニアの強み

　データベース・エンジニアだからこその強みとは、すなわちRDB自体の強みです。

　RDBは、今日の企業システムにおいて中核を成す重要なソフトウェアですが、単に大切なデータを格納する器だからという理由で、現在の地位を獲得できたわけではありません。これまで、RDB以外にも、階層型やネットワーク型など、さまざまなデータベース・アーキテクチャが使われてきましたが、企業システムの核としての地位を確立できたのはRDBだけです。それはなぜでしょう？

　RDBは、1つ1つの情報（データ）を、どういうかたちに分解して格納すれば最適か、また取り出したときに扱いやすいのかを考え尽くしたアーキテクチャで成り立っています。したがって、RDBを使いこなすためには、「情報を要素に分解し、次にその要素を組み合わせて再構造化する」という考え方が不可欠です。
　わかりやすく言えば、情報システムはその名のとおり、情報を扱う仕組みであり、「有効な情報を蓄え、それを戦略的に活用する」ことが究極の目的なのです。データベース・エンジニアの皆さんは、日ごろからそのことを考えてデータベースの設計に取り組まれているはずです。

　そして、この「情報を要素に分解し、再構造化する」という考え方こそ、今日の企業の情報システムをとらえるうえで根幹となるアプローチなのです。この考え方の上に、さらにこれを発展させる知識／技術を習得していけば、データベースを含む業務システムを広い範囲でとらえられるようになります。
　企業の情報システムとは、換言すれば「データを溜めて（要素に分解して格納し）、それを取り出して戦略的に使う（再構造化する）」ということをやっているに過ぎないのです。How（手続きや実現手段）を追いかけるのではなく、What（何のため＝目的）にフォーカスすれば、自ずと見えてくるのです。

核となるのは「情報を要素に分解し、再構造化する」という考え方

　先述のように、RDBの核を成す「情報を要素に分解し、再構造化する」という考え方が、システム開発全般にも広く応用できるわけです。では、RDBにかかわる知識／スキルをベースにして、さらにそれを発展させていくには、どうすればいいのか。

　実はこれに関する知識／技術は、システム開発の世界では随分前から確立されています。

　まず「情報を要素に分解し、再構造化する」うえでの基礎技術として「データ正規化」があります。さまざまな形で分散して存在する情報を、一定のルールに基づいて分解／最適化させる手法です。データベース・エンジニアの皆さんには、なじみの深い技術でしょう。まずは、この正規化の知識／スキルがベースになります。

　次に、正規化した情報を見える化するための技術として、「E/R（Entity/Relationship）モデル」があります。これを使い、個々の情報要素をどのように関連づけてデータの構造体を作るかを概念から定義するわけです。

　正規化とE/Rモデルは、いずれもデータベース・エンジニアにとって基礎的な技術ですが、思いのほか理解できていないエンジニアが多いのも事実です。

　また、正規化の手順をそのまま実行すると時間がかかりすぎて大変ですが、考え方や手順はしっかりと理解しておく必要があります。これらの技術を身に付けたデータベース・エンジニアが、さらに視野を広げたいと思ったら、ジャームズ・マーティンやトム・デマルコらが提唱した「機能モデル（Function Model）」について学ぶとよいでしょう。これは、業務／システムの要素を機能に分解し、システム要求をもとにそれらを組み合わせて新たな業務／システムを構成するというアプローチです。
　この成果物に、正規化とE/Rモデルで再構造化したデータ構造体を組み合わせれば、業務／システムの設計図が出来上がります。

　なお、業務／システムを構成する機能の中を、データがどのように状態を変えながら流れるのか、機能に対してどういったデータの入出力があるのかを設計するには「データ・フロー図（DFD：Data Flow Diagram）」を使います。このDFDも使いこなせるようになっておくと、さまざまな場面で役立つはずです。

本質を見定めて、必要な知識を効率良く学ぶ

　機能モデルやDFDの考え方は、近年、企業システムの世界で注目されている「BPMBusiness Process Modeling）」にも通じるものです。RDBの基礎技術を理解し、正規化とE/Rモデルのスキルを習得した上に、機能モデル／DFDの知識／スキルを積み上げていけば、業務システム開発のさまざまな領域／工程で応用が効きます。

　ただし、マーティンやデマルコの方法論はいずれも壮大であり、一からすべてを習得しようとすると、途中で挫折してしまうかもしれません。それを避けるためにも、ここまでにお話ししたポイント、すなわち「情報を要素に分解し、再構造化する」ことの重要性を念頭に置き、それを実践できるようになるために彼らの方法論を学ぶのだということを常に意識して臨むことが大切です。そうすれば、重要な点に絞り込み、効率良く知識を吸収できるでしょう。

　こうして、データベース・エンジニア必修の技術（正規化、E/Rモデル）に論理化の技術（機能モデル、DFD）を身に付ければ、活躍の場は一層広がります。
　業務に詳しくないエンジニアは、ユーザーとのコミュニケーションで引け目を感じがちです。どんなに努力しても、現場で業務を担っている方々に勝てるわけはありません。しかし、これらの知識があれば、業務の詳細を知らなくても、業務を機能の視点で整理し、それを再構成したり、ITシステムに落とし込んだりといったことが可能になります。
　プロセスを逐一ヒアリングしていくと、とめどもない作業になりますが、モデル化を目的に聞き出していけば、はるかに効率的に、しかもエンジニア側が優位な立場で進めることができます。ユーザーの側にはそうした知識がないので、エンジニアがこの考え方でリードすれば、彼らにとって頼もしいパートナーと映るでしょう。このとき、ユーザーとITエンジニアがタッグを組むという関係が生まれるのです。

　今回お話しした考え方をベースにすれば、企業の情報システム開発の世界で必要となる論理的思考力や問題解決力も自然と伸びます。それにプラスしてコミュニケーション力があれば、おのずと選ばれるITエンジニアになります。

　ただしその前に、まずは自分が今後、どういう道を目指したいのかを、ある程度明確にしておくべきでしょう。ゴールも見定めず闇雲に学んでも、どこにも行き着かなかったということになりかねません。なりたいと思う姿を描けない限り、そうなれるわけがありません。

■最近のエンジニアは技術力が低下？

　今日のITエンジニアの状況をとらえると、一口にITエンジニアと言っても、いろいろな立場の方がいるでしょうが、総じて感じるのは、「以前と比べて技術力が落ちた」ということです。具体的に言うと、技術の基礎となるアーキテクチャの理解不足が目立ちます。その結果、応用力が不足し、ある特定の技術／製品には詳しいけれど、それ以外の仕事はできないという人が増えているように思います。

　そうしたエンジニアは、活躍の場が限定されてしまいます。エンジニアを使う側からすれば、ある局面で、ある部分に関する能力を提供してくれさえすれば事足りるわけですから、下手をすると"使い捨て"にされてしまうのです。

　技術力低下の理由としては、組織の縦割り化が進んだ、扱う製品の数が増えた、また技術の発展速度が速まったなど、原因はいろいろと考えられます。いずれにせよ、一定範囲のことをキャッチアップするのに精一杯で、アーキテクチャの基礎をじっくりと学んだり、研究したりする余裕も時間もないと思われます。

■必要とされるためには、基礎をしっかりと身に付ける

　広く、そして長く必要とされるエンジニアになるためには、やはり基礎の部分からしっかりとした知識を付けなければいけません。完成した技術や製品の使い方を知っているだけではダメです。例えば、リレーショナルデータベースなら、どういったアーキテクチャに基づき、これまでどのような経緯で発展してきたのかといったことを知らなければ、データベース・エンジニアとして長く生き残ることはできないでしょう。E.F.コッドの関係モデルに関する理論などは必修です。パラレル機能などのオプションの機能は年を追うごとに増えていますが、RDBの根幹の部分は何十年もの間、何も変わっていません。その部分に関する知識をしっかりと身に付けることが大切なのです。

■会社の外に出て、自らの可能性を広げる

　近年は、ITSSやUISSのようなスキル標準を導入し、エンジニアのキャリア・プランの設計を支援する企業が増えてきました。ITSSやUISSではなくても、独自の専門職制度を設けている企業は、実は多く存在します。しかし、組織／業務の実態と合っていなかったり、うまく機能していなかったりといったケースが多いという現状です。それに、「あの部署の、あの仕事がしたい」と思っても、簡単に部署異動できるような会社はあまり多くありません。

　そもそも、会社としては、一度何かの仕事で良い成果を出した人には、その後も、その仕事を頼み続けたいものです。その人に頼めば、うまくやってくれることがわかっているわけですから当然です。一方、本人の側も、それを仕方ないと思ってやり続けていると、段々と別のことをやるのが怖くなってきてしまう、できなくなってしまう。これをキャリア・パスの視点で見ると、「短い距離をまっすぐ上って終わり」というかたちになってしまいます。

　では、まっすぐ上って終わりになるのではなく、横に、あるいは斜めにキャリア・パスをつなげていくために、個人でどう努力すればいいのか？

　今、所属している組織の中だけでこの問題を解決しようとしても、選択肢は非常に限られてくるでしょう。では、選択肢を増やすにはどうしたらよいか？ 自ら組織の外に出て行くことです。有志による勉強会や公的機関などがやっている研究会などの活動に参加し、視野を広げ、新たなキャリア・パスを見つけるよう努力することが大切です。単にセミナーに出て誰かの話を聞くだけでは足りません。自分の考えを基にディスカッションしたり、何らかの成果物を出したりするような活動に参加しないと、なかなか視野は広がりません。

　もちろん、普段は仕事があるので、こうした活動は定時後や休日などに行うことになります。結局、そうした時間を割いてまで自分の視野／可能性を広げたいという人が、一段も二段も突き抜けていくことになります。それに、外の世界を見ることで、自分が居る組織の良さや、自分が担当している仕事の良さに気づくこともあります。

　また「外の世界を見よう」と言うと、いきなり会社を辞めてしまう人がいますが、それは違います。確かに、会社を辞めることも、いずれは手段の1つになるかもしれませんが、その前に大切なのは、まず外の世界を知ることです。外の世界を見て視野を広げ、新たなキャリア・パスを模索し、そのうえで必要なら会社を変えるというステップになるはずです。

■「相手が何を求めているのか」を考えて行動する

　ここまでは技術スキルに関する話題が主でしたが、それとは違った視点で、もう1つ重要なことは、「相手が何を期待しているのかをつかみ、それに応えるよう努力する」ことです。

　技術力が高くて尖ったエンジニアというのは、往々にして我が強いものです。そのこと自体は問題ないのですが、そうしたエンジニアにもぜひ心掛けてほしいのは、自分が相手から何を期待されているのかを常に考え、その期待に応えるよう努力することです。

　相手の期待に応えるには、もしかしたら新機能は必要なくて、昔ながらの枯れた技術を使えば済むかもしれません。無数の選択肢の中から相手の期待に応える方法を見つけるのは大変ですが、それができるようになると、「この仕事はAさんにお願いしたい。Aさんが必要だと考える技術／製品／機能を導入したい」と頼られるようになります。これこそ、突き抜けたエンジニアです。ITプロフェッショナルたるもの、いずれはこうなりたいものです。

　相手との間で、「その製品／機能を使えるからAさんに頼む」というのではなく、「Aさんが勧めるから、その製品／機能を入れる」という関係を築くということです。ぜひそうした立ち位置を目指していただきたいと思います。

　昨今のオフショア開発の拡大や、今後はクラウド・コンピューティングの普及が現実的なものになることから、「ソフトウェアを作らない時代」への急速なシフトが考えられます。

　それに対応するIT人材の可視化や能力定義が喫緊の課題となっており、さらに作らない時代へのシフトから、OJTなどでの経験を積める環境が無くなる可能性が大きく、IT人材の能力向上策やキャリアプラン策定に、大きな障害になることが考えられます。

IT人材の将来は

　IT企業では、筆者の知る一番深い下請け構造は16階層でした。大手が請けて利益を差引き、下請けに投げるというゼネコンのようなシステムです。下請け構造が一概に悪いとは言えませんが、少なくともIT業界の場合は、マイナスに作用してきたことは確実です。これでは、元請けは外注管理（これをプロジェクト管理と呼ぶらしいですが）で、下請けは部分的な開発になってしまい、全体観が分からずどこにもスキルやノウハウが蓄積できない、非効率なモデルだと言わざるを得ません。

　ここ数年は、何とかこの下請け構造を脱する必要があるということで、国が有識者を集合させて策を練ってきたわけですが、それも必要なくなる可能性が高いと思われます。

　何故なら、ご存知のSaaSやクラウド・コンピューティングの出現で、そんなに遠くない将来「開発しない」という方向に大きく舵を切ることになると予想されるからです。アジア勢と開発単価で競うこともなくなるでしょう。

　一方、企業の情報システム部門、および情報システム子会社のIT人材は、新規システム開発が少ないため、総じて運用管理やメンテナスの作業に従事しているという現実があります。

　また、アウトソーシングやパートナー企業への一部業務委託を多用している場合が多いため、外注管理的な業務が増え、IT戦略策定やその実現のためのシステム開発に携わることのできる人材は、ごく一部に過ぎないというのが実情です。

　これでは、経験実績を積む機会に乏しく、間近に迫るクラウド・コンピューティングの時代に対応するための能力開発に支障をきたすと言わざるを得ないでしょう。

　ITサービス企業、ユーザー企業の情報システム部門、情報システム子会社に共通して言えることは、今後必要なコア人材として、大きく次の3通りの人材が考えられるということです。

●イノベータ

　IT活用に有効かどうか常にアンテナを張って新しいテクノロジや製品を察知し、その評価や選定などを主導し新しいことを発想するする人材

●アーキテクト

　様々な技術を活用して統合的なアーキテクチャを構想する人材

●コンサルタント

　業務改革や課題解決を主導し、クラウドで提供されている様々なファンクションをインテグレートできる人材

　これからの変化を乗りこなしていくために、「イノベータ」「アーキテクト」「コンサルタント」の3種類のコア人材をモデル化した上で、早期育成していく必要があります。

これからのIT人材の能力定義

　作らない時代におけるIT人材のあり方について、明確な能力定義をすると共に、能力向上を促進するための手順、および実現策を明確にしていく必要があります。

　能力定義については、経済産業省/IPAから公表されているのITスキル標準（ITSS）／情報システム･ユーザースキル標準（UISS）などがありますが、双方共にクラウド・コンピューティングなどの最新技術、および激変するであろう環境を想定していないことで、かなりの見直しが必要であると考えられます。

　それらの見直しによる改善は、期待できるものの少し時間がかかるものと思われます。新バージョンの公表を待ちつつも、先行した対処が必須となるでしょう。

　その前提において、IT人材の能力開発の考え方としては、先の3つの人材モデルをベースに、次の観点を入れ込むと効果的です。

• 知識ベースと応用力でカバーできる能力と、経験実績を積上げなければ形成できない能力の明確な定義
• 次世代の環境に合った企業IT戦略を具体的に策定、実現できる人材
• 比較的少数での戦略的IT推進体制と役割の実現
• 企業で経験できない研究、開発（ものづくり）などに関する「経験する場所」の確保
• 能力形成のための効果的なOff-JTとOJTの結合

「経験することができる場所」の考え方

　機会減少が著しいと考えられる経験実績を積み上げなければ形成できない能力を対象にし、その向上を図るための施策を具体化していく必要があります。

　例えば、企業とは離れた位置づけで、実証研究する場所（コミュニティなど）を設けるなどです。企業での実運用を前提とし、新技術を活用した業務システム開発を行うことで、企画から運用にいたる実経験を積むことができるようにするということです。

　対象システムは、SNSのようなものから、既存システムをクラウド化するようなものまで、幅広い選択枝がありますが、これらを実現するためには、企業の協力が不可欠です。

　その後半で、彼が作詩する場面がありました。見ていると、われわれがシステム構築を進める場合の上流工程、システム分析の中でもシステム要求をまとめる要求分析の局面で使用する、ロジックツリー法と同じ手順で進めているのに気付きました。

　実際は、進行役のCMクリエータ箭内道彦が考えた詩を、福山雅治が組み立てなおし、メロディをつけるという流れでしたが、その作詩の部分に目をみはりました。

　前もって作られた歌詞は、次のようなものでした。

-----------------------------------------
    　　　　　－I Think－

    僕は思う　
　　「がんばったね」ってのは
　　一番悲しい言葉なんだと

　　僕は思う
　　緊張するのは
　　あなたを大事に考えているからだと

　　僕は思う
-----------------------------------------

　特徴的な詞をいきなり見せられた福山雅治は、それを360度検証するところから入りました。

　「がんばったね」といったのは、悪気があったとは考えられない。だから「悲しい」とはならない。従って、「一番悲しくてうれしい言葉なんだ」、もしくは「一番くやしくてうれしい言葉」では？

　ここに、「なぜ」という観点が入って理解を増す意味合いが注入されたことと、悲しいというオリジナルを大事にするという感覚がうかがわれます。

　次に、「緊張する」のは「自分を自分以上に見せたい」とするほうが分かりやすいという話がありました。これも、先ほどと同様で「なぜ」という観点が入って分かりやすくなっています。

　この一連の作業の中で、「吐露したものからさかのぼっていく」という話もありました。つまり、現状をできるだけ素直に表現して、その原因を「なぜ」という観点で追究していくのです。

　さらに、「導入部分が重要」、ということや「さび（強調）は？」ということも出てきて、これぞ見ている側が分かりやすい、いいたいことを理解しやすいものにするという感覚です。

　そのあと一文づつ紙を切り取ってテーブルに並べ、目的－手段で並べ替え、構造化をはじめたのです。KJ法ではないですか！

　これには心底驚きました。

　なんと論理的な思考なのでしょうか。彼の作る歌詞が、どうして分かりやすく、なぜ心に響くか分かったような気がしました。

■ロジックツリー法

  ここで、論理的思考のメインストリーム、ロジックツリー法を簡単に説明します。　大きく分けて「目的－手段」で組み立てる、「全体－部分」で組み立てる、「結果－原因」で組み立てる、の3通りです。要件分析で使うのは、システム要求を目的－手段で組み立て、要求モデルを策定するという方法です。

　残念ながら、おととしお亡くなりになった川喜多二郎先生の「KJ法」を使い、次の図のように同じ目的のものをグループ化し表札を付ける、今度はその表札を同じ目的のものでグループ化し、表札を付ける。この作業を繰り返して階層化するのが、ボトムアップ的なアプローチです。

　ただし、これだけだと、上位に向かって拡散していく傾向があるので、トップダウンアプローチと併用してまとめていきます。

　最上位は、新システムを構築する一番の目的になります。その下位はそのための手段、今度はその手段を目的と読み替えて手段を見いだす。これがトップダウンの考え方です。

　上から2、3階層目くらいまでは、新システム構築の目的を把握できていれば展開することが可能です。

　そうしておくと、ボトムアップで積み上げるときに目指すべき位置が見えやすくなります。それらがうまくつながらないときは、どこかか矛盾しているということなので、見直しをすればいいのです。

　こうしてボトムアップとトップダウンを併用しながら要求モデルとして組み立てていきます。

■WHYツリーの活用

　そうはいっても、うまく展開できない場合に必ず遭遇することになります。

　例えば先の要求モデルの中で、「部品表を起こす工数の削減」とありますが、そのためになにをすればいいか分からない、といったようなケースです。

　こういう場合は、ロジックツリー法で原因解析すると分かりやすく解けます。一般的に「WHYツリー」と呼ばれていますが、次の図のように結果から原因を導き出していくのです。

　次の図は、結果から原因を突きとめるために展開した例ですが、問題を解決するにはツリーの右端に登場した6つの原因を解消しなければなりません。

　その原因を要求表現に変換したものが、一番右側に記載されています。

　原因を解消する解決策でないと、いいシステムを構築するためのシステム要求にはなりえません。原因を突きとめることができれば、それを要求モデルに追加していくと、うまく目的－手段で展開されたものができます。

　福山雅治の論理的思考は、このWHYツリーの考え方と似ています。WHYツリーはシンプルで使いやすい方法でありながら、なかなかの説得力を持ちます。いろいろな局面で使えますので、ぜひ使いこなしてください。

皆さんが働いている職場を評価してもらうために、10個の質問を投げかけました。

　（1）従業員の持っている能力のレベルを測定し、高めていく仕組みがあるか？

　（2）それは、教育研修と連携しており、従業員の多くが活用しているか？

　（3）会社から新しい仕事や学習のための機会を提供しているか？

　（4）それは、従業員側から手を挙げて挑戦（参加）できるか？

　（5）それらは、職場の活性化やモチベーションの向上につながっているか？

　（6）それらは、多くの職場で活用されているか？

　（7）従業員の強みや持ち味、希望を把握した上で、組織力（プロジェクト含め）が最大化されるような体制になっているか？

　（8）経営層、職場リーダークラス側は、（個別では無くて）組織（プロジェクト）の最適編成を進めるような意識を持っているか？

　（9）経営層と職場リーダークラスとの意識を合わせの定期的な対話などが日頃からなされており、経営に生かされているか？

　（10）職場リーダークラスが最適なマネジメントができるように、適切な教育が実施されているか？

　回答の仕方は、次のようにお願いしました。

　そう思わない：0
　ややそう思う：1
　そう思う　　：2
　強くそう思う：3

　12名の方から回答が寄せられました。ありがとうございました。結果は次の表のとおりです。

（クリックで拡大）

　大企業の方が1名、11名の方は中小企業との回答です。残念ながら母数が少ないので、平均値（3.67）などはあまり意味がありませんが、全体に低めのポイントになったのは、IT企業の実態を表していると思われます。

　質問の形態としては（1）～（2）が、効率的な育成計画を進めるための仕組みのあるなしを聞いていて、（1）で0を回答すると（2）も0になってしまうことになります。（3）～（6）も同様で企業の姿勢や制度のあるなしを聞いています。以外は独立した質問ですので、全体で6つの分類の質問となります。

　単純に各質問への回答が2以上で、10問あることから合計20ポイントあれば、成長できる環境として満足できそうな状態だと言えますが、先ほどの6分類での加重平均を考えると、12ポイント以上でそれに近しいと割り切ることも出来ます。

　また、質問内容は先に進むにつれて、「企業での実施は難しい」とされている内容にしています。

　ポイントの順でいくと、10番目の中小企業に勤務の回答者が11ポイントと最高で、2位の8番目の大企業勤務の方の8ポイントを上回っています。ほかは、ほぼ1桁前半に集中しています。また、合計ポイント0の方が2名ですが、質問内容と実態のかい離が大きすぎて、どこにもポイントが付かなかったと推測されます。今回アンケートの回答人数が12名と少ないのも、同様のことが原因であきらめた方もいたものと思われます。

　あくまで、この12名の方の回答からですが、次のような傾向があります。

• ITエンジニアの能力を測定して効果的な対処を考えるための仕組みがない
• （3）～（6）で示される「育成に対する企業の姿勢や制度」はそれなりに用意されているが、有効活用の面では今一歩物足りない
• 仕事のアサインやプロジェクトの体制作りには、本人の強み弱み、希望などを考慮されていない場合が多い
• 経営層と職場リーダーのコミュニケーションは、企業によってかなり格差がある
• 職場リーダークラスに対して適正な教育がされていない

　筆者の経験では、自身のスキルやキャリア向上を目指しているITエンジニアは、能力測定などの見える化の仕組みを取り入れることに大賛成ですが、あまり技術力に自信がなく向上心も低い人は、拒否反応が激しい場合が多いと言えます。

　分かりやすく言うと、残念ながらITエンジニアと言えど、上だけを見て要領よく立ち回っている人もけっこういるということです。

　また、能力をしっかり把握できないということは、好き嫌いや過去の経緯、上司の言いなりでプロジェクト体制などを決めている場合も多いでしょう。

　ただ、現実には人もいなくて現有勢力でやるしかないということや、直感でのアサインであってもかなり的を得るような優秀なリーダーがいることは確かです。しかしながら、しっかり能力を見極める仕組みがある方がいいに決まっています。

　IPAの『IT人材白書2010』のIT企業のアンケートでは、人材過剰の傾向が現れています。スキルを持っていてやる気のある人材しか登用されなくなるという流れです。企業がこぞってITSSなどの可視化の仕組みを取り入れつつありますが、ITエンジニアも恐れることなく、実力を出していくための準備をしていくことが大切でしょう。

　経営層の考え方は企業によって千差万別ですが、筆者の考えは「経営方針に共感が持てて、この会社と一緒に進みたい」と思わなければ、早く別の環境を探したほうがいい、ということです。説明の必要はないと思いますが、要は「魅力を感じない企業にいても、自らの成長はない」と考えるからです。これは、自分には無理とあきらめてしまうことや、逃げることを言っているのではありません。チャンスは向こうからやって来ないので、自分でつかみ取るしかないのです。視点を変えることも含め努力をした結果、出てくる決断だと考えます。

　もちろん、生活があるので簡単に割り切れるものではないのは誰もが承知していると思いますが、達成感がないことほど、モチベーションが下がることはありません。仕事でやる気が出ない場合は、仕事以外のプライベート側を充実させることに比重を置くしかありません。その場合、給料をもらうただけのために仕事をするということになりますが、昨今の人員過剰傾向や成果主義の中では、将来どうなるかが予測できません。

　また、1日8時間以上、1週間に5日以上、体力も気力も充実した時期を仕事に費やすわけですから、仕事に面白みや達成感がないということは、自分の人生の上でかなりのインパクトになるに違いありません。

　そうなると、自分の実力を上げて達成感のある仕事や立場を勝ち取っていくしかないということになります。

　このような現実の中、筆者の提言は「個人でPDCAを回す」ということです。

• 3年後の自分のなりたい姿を強く思い描き、能力、立場、処遇を詳しく定義する
• そうなるためには何をしなければならないかを、半年単位に具体的に計画する。計画できないような目標であったなら変更する
• 半年後に計画通りに進められているかをセルフチェックする。チェックして取り戻せないようなギャップがあれば、目標も含めてリプランする

　以前も書きましたが、「なりたいと思う姿を描けない限り、そうなれるわけがない」ということです。

　目標を持ってそれに向かっていくくせをつけないと、毎日の仕事に追われ時間だけが過ぎ去っていくということになりかねません。

　この考えで、自らを高めようとする姿勢を持つITエンジニアは、必ず花咲くと信じています。

　中には、ユーザー企業に就職して、本人が希望したわけではないのに情報システム部門やシステム子会社でIT系の仕事をしている人もいます。ITに目覚めた人は別として、そうした状況下でITに関わっていることを重要視せず、キャリアのほんの一部としか捉えていない人もいることは事実です。

　そうではなく、「職種に関わらず、一生ITに関わった仕事がしたい」と切に願っている皆さんに、ぜひとも試してほしいことがあります。

　普段、皆さんは仕事上で達成した成果を、上司や管理側に評価されているはずです。それが自分の報酬に大きく影響する場合がほとんどでしょう。

　一方、ある程度の役職の方は別として、皆さんから会社や上司、管理側を評価する機会はほぼないと言っても過言ではないと思います。360度評価などの制度を取り入れている企業もありますが、少し意味合いが異なるケースが多いと言えます。

　先に書いたように、キャリアアップやスキル向上を目指すとすれば、成長という観点で自分のために会社が何を提供してくれるか、働いている環境がいかに適しているかが重要です。

　もちろん、会社側から提供してくれるのを待つだけでは、本来のキャリアアップやスキル向上を目指せるわけはなく、自らの意識が高いことが前提です。自分は何もせず、会社の責任だと文句ばかり言っているのは論外です。双方に責任があり、それをしっかり認識できて初めて成り立つ話です。
　
　しかしそうは言っても、会社や管理側をITエンジニアから評価するすべがないことも事実です。いろいろな団体が、企業評価の制度を持って表彰や認定を実施していますが、どうも筆者には大企業が大企業を評価しているようにしか見えません。

　今回は、皆さんの力を借りて、ITエンジニアが自分の働く職場を評価するとどうなるか、ということにチャレンジしてみたいと思います。

　以下に、10問の問いを作成しました。会社や管理層が、ITエンジニアのキャリア向上やスキルアップを考えている環境かどうかを問う内容です。合計ポイントが20点以上であれば、適した環境であると考えていいと思います。

　賛同いただける方は、コメントを使って次の要領で1問ずつ回答してください。ある程度回答がいただければ、集計・分析してみたいと思います（これを回答フォーマットとしてコピペしてお使いください）。

------------------------------------

問い（1）：0
問い（2）：0
問い（3）：0
問い（4）：0
問い（5）：0
問い（6）：0
問い（7）：0
問い（8）：0
問い（9）：0
問い（10）：0
合計　 ：0

職場規模：

• 大企業/資本金の額・出資の総額3億円以上 or 従業員300人以上
• 中小企業/資本金の額・出資の総額3億円未満 or 従業員300人未満
  　　　　　　　（「中小企業の新たな事業活動の促進に関する法律」より）

質問の改善要望などご意見：

------------------------------------

（回答ポイント）

そう思わない：0
ややそう思う：1
そう思う　　：2
強くそう思う：3

（質問）

問い（1）
従業員の持っている能力のレベルを測定し、高めていく仕組みがあるか？

問い（2）
それは、教育研修と連携しており、従業員の多くが活用しているか？

問い（3）
会社から新しい仕事や学習のための機会を提供しているか？

問い（4）
それは、従業員側から手を挙げて挑戦（参加）できるか？

問い（5）
それらは、職場の活性化やモチベーションの向上につながっているか？

問い（6）
それらは、多くの職場で活用されているか？

問い（7）
従業員の強みや持ち味、希望を把握した上で、組織力（プロジェクト含め）が最大化されるような体制になっているか？

問い（8）
経営層、職場リーダークラス側は、（個別では無くて）組織（プロジェクト）の最適編成を進めるような意識を持っているか？

問い（9）
経営層と職場リーダークラスとの意識を合わせの定期的な対話などが日頃からなされており、経営に生かされているか？

問い（10）
職場リーダークラスが最適なマネジメントが出来るように、適切な教育が実施されているか？

　ひととおり眺めましたが、一番気になったのは「キャリア」についての考え方、そして先が見えずに将来を不安視しているITエンジニアの実態が浮き彫りになっていることです。

　下記の図は、現在IT系企業に勤務している人への質問です。「なぜIT業界を選択したか」を年代ごとに集計したものです。

　上位の3つを見ると、年代に関らずIT系の仕事自体は面白そうに見えていたということがうかがわれますが、「将来性がある」と答えたのは20代以外の世代であり、しかも倍ほどの開きがあるのが象徴的です。この傾向は、3番目の「先進的だと思ったから」という項目でも見られます。

　20代の若手からすると、就職する前は「仕事は面白そうだが、将来性や先進性の点では評価していなかった」ことになります。

　4番目の「技術やスキルが身に付きそう」という回答は、次の図の「定年までIT関連の仕事を続けたい」という考えにつながっているようで、IT業界の将来を考えると少しほっとする部分です。

　前回お話ししたように、給与に対しての満足度はそれほど高くありませんが、かといって他業界と比較して特段IT系が低いとはいえないという結果が出ました。また、勤務環境も良好だということで、いままで言われていた3Kのイメージが変化してきているといえるでしょう。

　しかし、一方で自身の将来についての不安が顕著に現れています。

　次の図は、将来のキャリアに対する不安の内容を示しています。

　「いま自分が持っているスキルが将来通用しなくなるのではないか」という不安がダントツで1位です。これはクラウドを筆頭に、SOA、BPMなど目まぐるしく変化するビジネスモデルや技術動向についていけるか、そのためにどうすればいいか分からないなどというところから来ていると考えられます。

　次の図は「自分の将来の目標を持っているか」というアンケート結果です。

　「明確な目標を持たない」という回答が圧倒的ですが、なぜ自分のキャリアについて考えないのかという理由が、次の図で示されています。

　仕事をこなすだけで精一杯というのは、勤務環境が良好という結果からも、時間不足の問題ではなくて、能力とやる気の問題だと推測されます。

　つまり、極端に言うと、「仕事をする時間は仕事をするだけで、ほかのことを考える余裕や気持ちがない」ということかもしれません。

　なぜ考えられないか。下記では、「将来設計に関して企業が責任を果たしていない」という技術者の気持ちが見えます。

　60％以上のIT人材が「キャリアパスを提示するのは会社の責任である」と考えています。

　それに対し、企業側の同じく60％強が「キャリアパスについては個人の責任である」としています。

　ここから、キャリアアップに関して、企業と個人が押し付け合いをしているという構図、また、個人の考えとして自身のキャリアアップは大きく企業に依存している、ということが見えてきます。
　
　キャリアアップのために、キャリアパスの提示だけではなく、企業として実施してほしいこと（実施中も含めて）をまとめたものが、次の図です。

　たとえば、キャリアカウンセリングについて、50％近くの人が必要だと考えているのに、現実は10％強しか実施されていないということになります。

　プロフェッショナル・コミュニティに関しても、同様の傾向です。

　キャリアカウンセリングなどは、企業が専門家を用意しないと現実的には実施不可ですが、コミュニティなどはやる気さえあれば、現場から声を上げて進めることは可能です。

　企業ができること個人のできることを明確にして、どうするかを考えること、つまり目的－手段と役割分担を決めることはできそうです。

　やる気次第でしょうが、このあたりがヒントになるのでは……と考えています。

　皆さんはどう考えますか？

　http://www.ipa.go.jp/jinzai/itss/activity/2010summary_of_ITHR.pdf

　P38以降に、興味深いことが書かれています。以下はP38の抜粋です。

「実態とは異なる3Kイメージ」

• 「IT人材の仕事や職場の環境に関する満足度調査」から、職場の雰囲気に対する満足度が高く、休暇の取りやすさやプライベートとの両立に対しても満足している様子で、世間で話題に上がる3Kのイメージとは異なる結果となった。状況は変化してきている。
• しかしながら、現下の景気低迷による業務量の減少が、職場環境に大きく影響を与えていることは否めない。景気の回復を待つのではなく、産業自ら変化してゆくことで、3Kイメージを払拭することが重要である。

　次のチャートは、対象者1000名のアンケート結果「仕事や職場の環境に対する満足度」（P39）です。

　P39の最下部に、注釈として以下の内容が記載されています。

　（注）「給与」についての満足度は今回調査においても高くないが、「IT人材白書2009」の分析結果から他業界と比較してIT業界の水準が低いとの認識は伺えず、また2008年度後半から調査時まで続いている景気低迷の影響も考えられることから、IT業界の水準や満足度が特別低いとの結論には至っていない。

　また、P41～46では、現状や問題点などの意見をまとめています。

　上記資料では「自分の将来についての不安」が最も色濃く表れているようですが、IPAは次のようにまとめています。

　「現在のような不透明な時代であるからこそ、IT企業は、自社の方向性や将来ビジョンを明確に伝え、IT人材が、産業や企業の将来に魅力を感じ、誇りを持って生き生きと働ける環境を創り出すことが重要である」

　企業側の心構えとしては、そのとおりかもしれませんが、ITエンジニアサイドは、どう考えればいいのか、ここからは見えてきません。「営利を追求する企業がそれなりのものを用意してくれれば、ITエンジニアが幸せになる」とは考えにくいと思います。

　このような状況の中、仕事内容や職場環境の満足度、給与に対する考えなど、批判や批評、ましてや文句ではなく、建設的な意見をお持ちの方、ぜひお考えを聞かせてください。

　なぜか、このシーンをはっきりと覚えているのです。それは、答えられなかったからではなく、先生が言ったことが強烈に印象に残ったからです。

　「明日を生きるために、今一生懸命生きてるんだ」

　当時理解できたかどうかは定かではありませんが、この言葉が記憶にしっかりと残っていてあるタイミングで頭に浮かんできます。

　変な話ですが、それは大変な失敗をしでかしてしまったときです。

　失敗といっても通常レベルのものではなく、例えば、以前勤めていた外資系企業で、あることを良かれと思ってごり押ししたせいで顧客に大損失を与えてしまい、社長はじめ何人かの役員をかんかんに怒らせてしまったことがありました。そのような場合です。

　かなり極限状態になりますが、そんなときいつも割り切って「そうはいっても殺されるわけではない」と考えるようにしています。

　そのタイミングが微妙で、限界に近づいていないと、いくらそう考えても冷や汗が出ている状態から開放されません。今だから冷静に（気楽に）分言えますが、その状況の中ではいかんともしがたく、終始落ち着きがない状態で、大声を出して走りたくなる有様です。

　それが限界に近づき、殺されはしないということを受け入れることができた瞬間に、先の「明日を生きるために今を生きている」というフレーズが出てきて、だから「頑張って生きているからいいじゃないか」という気持ちになることができます。そして、恐ろしい（と自分では思っている）状況から見事に開放されるのです。

　思い返すと、社会人になって責任を感じはじめたあたりから、これを自覚し出しました。

　不思議なのですが、今まで何度か経験した、頭から深みに落ちていくような強烈なインパクトの「大変な失敗」は、必ずこのサイクルにはまっていきます。

　客観的にうまく書けませんが、考えてそうなるわけではなく、無意識のうちに流されていくのです。

　企業の人材体系を構築し、育成のPDCAを廻すための仕組みづくりをするためのコンサルテーションがわたしのビジネスですが、その仕事柄「人」について深く追求することになります。

　成功体験を持つ人材は、どのような能力を持っているか、特性は、失敗体験とその克服方法は……といった具合です。

　特に先述の失敗体験中の自分を分析しますが、まとまらずどうもうまくいきません。他者にはできて自分にはできない、これでコンサルタントかとみじめになる気持ちではありますが。

　唯一参考になるかなと思うのは、心理学の人材に関する理論でしょうか。

■人材要件の定義

　著名な心理学者、及び人材開発に関わる方々の見解によると、人材に関する要件は以下の3層に分かれるということです。

・第1層

　自分が相手にこれだけのことをすれば、必ず相手もこれだけのことを返してくれると信じる感情（心理学ではベーシックトラストと呼ばれる）。就職するまでに固まり幼児期の体験で決まる、元来変えられないもの。

・第2層

　思考特性や行動特性を表し、＜好奇心→チャレンジ→認知＞のサイクルのことである。このサイクルがうまくいかないことが続くと、チャレンジを避けるようになる。30～35のビジネスマンの最初の10年で固まり、以後変えにくい。

・第3層

　経験や知識で蓄積されて行く特定分野の具体的能力、知識やノウハウなど。

　この内容で考えると、本来重要なのは第2階層であり、言い換えると自分自身の中でPDCAを廻せる人材を登用したり、育成するというのがあるべき姿です。ところが、一般的には第3層だけを見て採用(調達)や評価をしているケースが多いように見えます。

　好奇心やチャレンジ精神が旺盛な人は、第3層の特定分野の知識やノウハウを自分自身でキャッチアップして行く能力を持ちます。それにかかる時間だけの問題です。

　ユニクロのファーストリティリングは、採用の際に自分でPDCAを廻した経験を持つ人かどうかを確認し、その経験のない人は選択基準から外れるという考え方を持っていると聞いています。

　いかに第2層が優れている人を見分けるか、その能力を伸ばして行くような環境を作れるか、ということが「ビジネス目標の達成に貢献する」人材を育成するかが、企業にとって重要かということでしょう。

■自分の場合

　そうすると、わたしはある程度PDCAを廻すことができると自分では思っていますが、Doのときの大きな障害で停滞してしまい、Check、およびActionの機能が働くのに時間がかかるということでしょうか。

　もちろん、次のReplanも時間がかかるということになります。

　突き詰めると、想定以外のことが発生し、そのインパクトが大きいときにオロオロしてパニックになる、という単に器の大きくない奴ということですか。情けないですね。

　こんなに吐露すると、もしクライアントがこれを見れば、あきれられるかもしれませんね。

　皆さんはどうですか。失敗したとき、どうなってどう克服するか、ぜひ教えてください。

　先日、ある団体で企画されたパネルディスカッションに出ました。そのパネルの主題は、「情報戦略実現に向けた高度IT人材の役割と育成」です。

　大手ITベンダ、金融系の情報システム部門、会員代表、わたしと4名のパネラー構成です。モデレータの方の絶妙な誘導で、進行自体はスムーズでしたが、気になったことが何点かありました。

■「高度IT人材」について

　「高度IT人材」の共通認識ができていないのです。

　おおむね話の流れでは、「下流工程を十分経験して育ってきた上流工程に長けた人材」という感覚でしたが、どうもわたしにはスッキリしませんでした。

　確かにそれは必要条件の1つと考えられるのですが、十分条件ではないと思うのです。当然、ユーザー企業とIT企業では異なるとの前提はあると思います。

　さらに話の中で、パネラーの一人からITSSのレベル4以上の人材だ、という話が出てきてスッキリしないことに追い討ちをかけました。どういうスキルを持つかということも1つの要素ではありますが、これらだけではピンとくるものにはなり得ないと思います。

　高度IT人材というと、どうしてもITスキルが高い人材、つまり上流ができることや、ITSSの高レベルという発想になってしまうようです。

　わたしは、人材戦略の一環であるリーダーの育成プラン策定と、それに関る一連のコンサルティングをしていますが、ある企業で、ここしばらく次世代リーダー候補というべき、30代前半ばから40代初めにかけての中堅層の方々30名と話を続けています。

　そこで一番驚いたのは、5年後の自分のゴールは？ の問いにまともに答えられた方が1人もいなかったことです。

　以前のコラムで、「なりたいと思う姿を描けない限り、そうなれるわけがない」というタイトルで書いたことがありますが、まったくそれを地でいっているようなものです。

　大変抽象的な表現ですが、わたしには「HowではなくてWhatが定義でき、周囲に示しリードして結果を出せる人材」が必要な人材であり、「高度」も「IT」も基本的に関係ないと考えています。

■IT企業のあり方について

　気になったことのもう1点ですが、質問の中で「情報処理学会で報告された内容として、グーグルが今や技術者というより、統計などの分析者を採用している。育てるにはどのようにしたらいいか」といった質問が出ました。

　この質問に、日本のIT企業と人材の戦略のなさ、その根深さが表れていると感じました。

　うまく意見できずにもどかしかったのですが、グーグルには戦略があって目標設定が柔軟で明確です。したがって、もっと先を見ているのであって、現在の採用計画などの取り組みは、一時の手段にすぎないと考えます。それを目的のように捉え、右に倣（なら）えとは……。

　少し観点は異なりますが、前職の日本オラクルのときの面白い話があります。

　6、7年前の話ですが、戦略ミーティングで3カ月に一度、シリコンバレーの本社に出張していました。そのときに見る見るうちにインド人の技術者が増えていくのを目にしました。その1年半後には急速に見かけなくなりました。

　彼らは仕事をインドに持ち帰ったのです。どんな仕事かというと、データベースの設計・開発です。オラクルのビジネスのコアであるデータベース開発を、です。それ以前から24時間サポートで、時間帯で拠点分けしてサポート・サービスを提供していましたが、これにはさすがに驚きました。インド人が英語をしゃべれて勤勉であることや、コスト削減効果を考慮しても、かなりのリスクがあるように見えます。

　現時点の状況を見て評価するのは容易ですが、これは経営戦略に基づく方法であって、さらに先を見た目標を持っているということを理解する必要があります。

　我々の悪いところは、手段を目的化することです。

　何に関しても浅すぎる流れを断ち切って、日本流の迫力ある企業とあるべき人材を創造するには、リーダーシップが重要だと考えています。

　おかげさまで（？）、その一翼を担えればと深く決意することになってしまいました。

　皆さんの考える「高度IT人材」をぜひ教えてください。高度IT人材という言い方が気に食わない方もいらっしゃるでしょうが、別の視点でもかまいません。

　また、「日本のIT企業のあり方」も議論したいテーマです。ご意見をお待ちしています。

　要求分析のアウトプットである要求モデルは、ロジックツリー法を使い、目的／手段の関係で階層化すると便利です。

　組み立て方は、上位の3階層ほどを仮にブレークダウンしたあと、KJ法を使用してボトムアップでそこに向かってまとめていくことになります。

　その作業の途中に、うまく組み立てられないときに、ロジックツリー法の「WHYツリー」を活用すると、うまく解けていくことをお話しました。

　さらに進めると、「対立要求」が表面化します。つまり、ある部署の要求では「在庫を減らす」なのに、別の部署の要求では「在庫を増やす」ということで、相反するような要求内容が登場することになるのです。

　なぜこうなるかというと、業務は部署などある範囲で閉じていますが、システム化対象として見ると組織枠を外すことになるので、それぞれの利害関係などが、浮き彫りになるということです。

　対立関係には次のような種類があります。

• 両方とも必要であるが背反関係にあるもの
• どちらか一方があればよいもの
• 包含関係にあるもの
• 共通目的を補完し合うもの

　競合度の評価は次のような考えで実施します。

1.　背反関係・包含関係にあるもの

　　＜背反関係＞
　　要求モデル上で現す共通手段を検討する。

　　
　　＜包含関係＞　　

　　この段階で、上記要求ｃ，要求ｆがみつからない場合は、結論を代替案検討に持ち越しても構いません。

2.　どちらか一方があればよいもの

　　両者の特性を比較し、総合的に評価の上、どちらかを選択します。

3.　共通目的を補完し合うもの

　　共通目的へのそれぞれの貢献度を評価し、どの要求を採用するかを判断します。

　各部署より出された要求をうまくまとめることによって、1つの目的に向かって実現手段が並ぶという、理想的な要求モデルになります。

　策定の途中で常に意識しないといけないのは、「何のために」という目的視点と、その目的に合わない要求は範囲外として明きらかにすることです。

　外された要求を、その理由とともに該当部署にフィードバックすることの重要さは、言うまでもありません。

●評価基準の設定

　要求モデルができれば、次にシステム活用時に評価する基準を決めておく必要があります。

　要求分析の最後でこれをまとめることはセオリーとして守りたいものです。

　システムが出来上がってから評価基準を作るのは、後出しジャンケンと同じです。このタイミングで、構築したシステムの価値について、何を評価するかを明確にしておくことが肝要です。

　評価基準体系は、次の条件を守る必要があります。

• 評価要因のもれがない
• 確実に関連がある
• 測定可能である
• 重複は最小である

　また、基準体系例としては次のようなものが挙げられます。

1．プロジェクト特性をベースにしたもの

• ユーザの満足度
• 要求達成率
• アプリケーションのポテンシャル
• 開発コスト
• 運用コスト
• コスト発生時期
• 効果発生時間
• 開発期間
• 実施時期
• 必要要因
• 成功の確率
• 予算達成の確率
• 必要新機器
• 機能の優先順位

2．経済的基準をベースにしたもの

3.企業経営効率をベースにしたもの

　これらの基準は、システム提案のときにも内容のチェック項目として利用することができます。顧客のＲＦＰにマッチした提案にするための指標とするのです。

　次回は機能分析に入っていきます。

　先回は、システム要求をまとめていく最初のステップとして、関係部門から要求を一件一葉の形で抽出し、精査していくことを説明しました(○○を○○する、という要求表現)。

　各部門の方々は、自部門での業務はよく理解していますが、インプットされる情報やアウトプットされてからの情報について、どのようなプロセスで扱われて、どう形を変えていくかは、あまりご存知ないのが一般的です。

　従って、極端な表現をすると「自分さえよければいい」的なシステム要求になりがちです。

　これらを是正し、共通認識を持ってもらい、さらに前向きな要求にしていくために、関与者利害管理表を使います。

　他部門でどのようなことを課題としているか、自部門からの要求が他部門に与える影響は……、などといったいいシステムを構築するためには欠かせない共通認識や全体観をイメージできるいい機会となります。

■要求モデルの構築

　対象領域での要求がある程度出た時点で、ロジックツリー法を活用して要求モデルを構築していきます。ロジックツリー法の中の１つで、要求を「目的－手段」の関係で階層化していく考え方です。

　次の図は、一件一葉で記述された要求を階層化した簡単な例です。

　残念ながら先日お亡くなりになった川喜多二郎先生の「KJ法」を使い、次の図のように同じ目的のものをグループ化し表札を付ける、今度はその表札を同じ目的のものでグループ化し、表札を付ける。この作業を繰り返して階層化するのが、ボトムアップ手法です。

　ただし、この手法だけだと、上位に向かって拡散していく傾向があるので、トップダウン手法と併用してまとめていきます。

　最上位は、新システムを構築する一番の目的になります。その下位はそのための手段、今度はその手段を目的と読み替えて手段を見出す。これがトップダウンの考え方です。

　上から2、3階層目くらいまでは、新システム構築の目的を把握できていれば展開することが可能です。

　そうしておくと、ボトムアップで積み上げるときに目指すべき位置が見えやすくなります。それらがうまくつながらないときは、どこかか矛盾しているということなので、見直しをすればいいのです。

　こうしてボトムアップとトップダウンを併用しながら要求モデルとして組み立てていきます。

■ＷＨＹツリーの活用

　そうはいっても、うまく展開できない場合に必ず遭遇することになります。

　例えば先の要求モデルの中で、「部品表を起こす工数の削減」とありますが、そのためになにをすればいいか分からない、といったようなケースです。

　こういう場合は、ロジックツリー法で原因解析すると分かりやすく解けます。一般的に「ＷＨＹツリー」と呼ばれていますが、次の図のように結果から原因を導き出していくのです。

　次の図は、結果から原因を突き止めるために展開した例ですが、問題を解決するにはツリーの右端に登場した6つの原因を解消しなければなりません。

　その原因を要求表現に変換したものが、一番右側に記載されています。

　原因を解消する解決策で無いと、いいシステムを構築するためのシステム要求にはなりえません。原因を突き止めることができれば、それを要求モデルに追加していくと、うまく目的－手段で展開されたものができます。

　ＷＨＹツリーはシンプルで使いやすい方法でありながら、なかなかの説得力を持ちます。いろいろな局面で使えますので、ぜひ使いこなしてください。