PR

 幸せなSEとは---。野村総合研究所(NRI)の淀川高喜・研究理事が長年考え続けているテーマだ。企業経営にIT活用は重要と言われているのに,それを担うSEを活性化させる取り組みは不足している。ユーザー企業のIT部門やソフト会社のSEに漂う閉塞感に危機感を覚えているという。

 20年前まで,企業情報システムに携わるSEは花形の職種で,やりがいのある仕事であった。IT活用による効果も比較的わかりやすかった。ところが,ITが企業内に浸透したことで,IT活用は当たり前になり,以前ほど魅力的な価値をアピールできなくなってきた。

 加えて,数多くのITシステムが構築され,それらのメンテナンスに日々追われるようになり,企画や開発よりも,維持管理に多くの時間が割かれるようになった。ほとんど新しいことに取り組まない,取り組んでも目覚しい効果をアピールできない,という状況になっているのだ。

 この間にSEの仕事の分業化も進んだ。メインフレーム技術だけを熟知していればよかったのが,オープン時代になり様々な技術を覚える必要が出てきた。だが,その技術の寿命は短い。

 一方で,業務のことはよく知らないので,ユーザーから言われたままIT化することになる。技術の詳細もわからないのでITベンダーに聞く。IT部門は主体性を持てなくなっている。「ITは有望な経営資源となりうるのに,それを担うべきSEは目の前の不良資産への対応に追われている」と淀川氏は指摘する。

 淀川氏は「結局,経営者が意識を変えること」と説く。現場のSEが意識改革するだけでは,この問題の打開は無理だからだ。そこで淀川氏が提案するのが,NRIが開発したという手法「VOICE」である。VOICEの採用云々はともかく,活性化への道筋を議論するためにその目指すところを紹介する。

 VOICEを一口で言えば,「元気な企業」の共通点をまとめたものである。最初の「V」は「バリュー」。「ビジョン」で価値観を鮮明にし,共有することだという。淀川氏によれば,自分たちの仕事が利用者(顧客)に役立っていると実感させる仕組みが必要だという。ただ言われた通りにやる,という状況からはこうした実感は生まれないので,経営者がIT部門に対し,ビジョンを明確に示すべきだという。

 「O」はオポチュニティ。成長の機会を与えることである。ローテーションや研修などを通じて,スキルアップやポジションアップさせる。確かにSEという職種では,ある仕事に一度アサインされると,そこで塩漬けになり成長のチャンスが狭まることがよくある。意図的に仕事内容を変え,成長の機会を作るべきである。

 「I」はイノベーション。新しいものを創り出しているという実感である。面白がって仕事をやれるようにする。これは後述するとして,「C」はコミュニケーションのC。社員を孤立させてはいけない。風通しをよくし,お互いが取り組んでいることを理解し,補完し合える環境にする。

 SEという職種は,同じ仕事を続けるうちに,いつも同じ人としか話をしなくなり,コミュニケーションに閉塞感が出てくることが多い。あるいはメールでしか会話をしなくなる恐れもある。これを防ぐために,チームで作業を進める形態にし,IT部門内,さらにはユーザー部門との対話が必要な状況を作る。自ら提案し,責任を持たせることも必要だ

 そして最後の「E」はエンパワーメントのE。能力を発揮できるような場を与えたり,権限を委譲したりすることである。「失敗したら大変だから,言われたことしかしない」という組織にしてはいけない。これは個人に限らず,IT部門に対しても同じことが言える。「危ないことはするな」と言われ続けているIT部門からは,「I」(イノベーション)も生まれないだろう。

下請けや派遣ビジネスでの実現は難しい

 何よりもこれらの取り組みに欠かせないのは,「IT部門長,担当役員,さらに経営者が『IT部門は大事なのだ』と意識すること」(淀川氏)だという。

 ソフト開発会社にも当てはまる点は多いだろう。ただし「下請けや派遣ビジネスでは,どうしても言われたことをやるだけになりがち。ここを変えない限り,VOICEの実現は難しい」と淀川氏は語る。下請けではビジョンを意識する必要もないし,成長も相手次第。「小規模なサブシステムでもいいから,一括で請け負うべきだ」(淀川氏)。

 製造業でいう「セル方式」のような考え方である。システム構築の需要は縮小傾向にある。市場が少々回復しても,インドや中国などコスト構造の異なる海外企業との競争には勝てないだろう。詳細設計以降の作業は安いところに流れていくので,小さくてもいいから上流工程からすべてを手がける。

 淀川氏が薦めるのは「アジャイル開発の採用」である。そして,ユーザー企業と一体となってプロトタイプを作り,検証し,それが役立つと分かった時点で設計に入る,という流れで開発ビジネスを進める。顧客密着型の開発ならば,容易にオフショア企業にリプレースされることはないだろう,というわけだ。