[特集:SEが消える] 富士通・組織人事改革担当者「SEにはWebエンジニアのような創造性が必要」と話す真意

2012.02.14 ITニュース

2012年1月19日、日経新聞に掲載されたある記事が大きな話題を呼んだ。

「富士通、余剰ＳＥ変身作戦」

そう銘打たれた記事では、富士通がグループで抱える約3万人のSEの大がかりな職務転換に乗り出したと書かれていた。

事実、多くのSIerは、クラウドの普及や市場のグローバル化による開発単価の低下、受託開発市場の縮小といった大小さまざまな問題を抱え、変わることを余儀なくされている。

ではそんな中、生き残りをかけて変わろうとしているSIerは、具体的にどのような対策を打っているのか？また、SIerが変わることにより、そこで働くエンジニアにはどのような変化・適応が求められるのか？

人材革新への取り組みを発表した富士通と、実際に従来のSIer型ビジネスモデルから脱却し、すでに新たな方向へシフトチェンジを行っている企業の例から、これからのエンタープライズ領域で活躍できるSEの条件を明らかにしたい。

「顧客利益」を第一に考えるなら、エンジニアは役割別に分類すべき

今回、富士通が発表した新しい取り組みは、「これからのSIerはどう変わらなければならないのか？」という問いに対する、富士通なりの回答と見ることができる。富士通が発表した人材革新の骨子は以下の3つだ（下図参照）。

■これまでスキルベースで機能別に定義されていた職種区分
　（コンサルティング／プロジェクトマネジメント／業務アーキテクチャ／
　品質マネジメント／ITアーキテクチャ／プロダクトアーキテクチャ／
　サービスマネジメント）を撤廃

■ビジネスプロデューサ／フィールド・イノベータ／コンサルタント／
　サービスインテグレーターという役割ベースで職種を再定義

■従来のSI業務や、カスタマイズや運用・保守を伴うクラウドサービスへの
　ニーズがあることも想定し、一部例外としてアプリケーション保守／
　コンバージョン／開発／サービスマネジメントの４職種を設ける

そもそも富士通は、何を現状の「問題」と認識し、こうしたSEの職務転換に踏み切ったのか？

「SIerに対するこれまでの顧客ニーズは、主に『人が担っていた仕事を機械で置き換え、業務効率化を図ること』でした。しかし、今やITは『機能から戦略』というフェーズ。

『何を効率化できるか？』から『どんな新しい価値を生み出せるか』という方向にシフトしていて、ただモノづくりをこなすだけのSIerには価値が認められにくくなっている。こうした顧客ニーズの変化が、そもそも今回のSE職務転換のきっかけです」

そう話すのは、富士通共通技術本部本部長の柴田徹氏だ。ITの役割の変遷が、なぜ職務転換に帰結したのか、さらに柴田氏は続ける。

「もともとSIerには、3つの職種しかありませんでした。メインフレームを扱う技術者と、プログラムを作る技術者、そしてプロジェクトマネジャーです。ところが、技術の進化・深化によって分業化が進み、その都度、ネットワークエンジニアやデータベースエンジニアなど新しい専門家が生まれてきた。

ただ、それは顧客にとってはどうでもいいこと。ITの役割が変わった今、むしろ役割ごとに職務を分ける方が、顧客のニーズに応じやすいと判断したのです」（柴田氏）

エンジニアに必要なのは「クリエイター」としての目利きだ

今回、大々的に職務転換を打ち出した背景には、自社のエンジニアに対する「われわれは顧客ニーズを起点に変わらなくてはならない」というメッセージングの意図もあったという柴田氏。

では、職務が大きく変わることで、現場で働くエンジニアに求められるスキルに変わりはあるのだろうか。

「まずは、顧客の意思決定にきちんと関与できる能力が、これまで以上に必要になる。言われたことを忠実にこなすだけではなく、自ら企画し、戦略的な視点で提案できることが大切になります。

それに伴い、日々生まれてくる技術・製品の中で、これからメインストリームになりそうなものを見極める『目利き力』も重要になるはずです」（柴田氏）

現場のエンジニアとして取材に同席した迫田誠太郎氏も、うなずきながらこう加える。

「さらに、これまではそれほど重要視されてこなかった『クリエイティビティ（創造性）』も必要となる場面が増えるでしょうね。従来、受託をメインにやってきたSEは、御用聞きをして言われたことをやれば良かった面がありました。しかし、今は違います。

顧客の想定を超える提案を行って実現するためには、自分から問題を見つけ、その解決法をゼロから『クリエイト』できなければならないと感じています」（迫田氏）

個々のエンジニアに「クリエイター」としての自覚を持ってもらうべく、富士通としてもバックアップ体制を整えつつあるという。

迫田氏が開発を担当するクラウド型プラットフォーム、「ＩＮＴＡＲＦＲＭ開発クラウドセンター」の設立は、そんな試みの一つだ（右図参照。クリックで大きく表示されます）。

「『ＩＮＴＡＲＦＲＭ開発クラウドセンター』は、エンジニアが社内ですぐに開発を始められるよう開発環境をオンデマンドで提供する仕組みです。イメージとしては、Web系の人たちがよく利用しているPaaS（Platform as a Service）に近いですね。

社内のエンジニアが思いついた新しいソフトウエアを簡単に開発・公開できる場を設けることで、最近のWebエンジニアのような『クリエイト』に励んでもらいたいという狙いがあります」（迫田氏）

もともと、富士通には社内に散在する個々のエンジニアが持つナレッジを集合知化する目的で作られた「Knowledge Base」があった。そこには43万を超えるコンテンツが所収されているものの、実際には単なるナレッジの「貯蓄庫」となっていたため、一昨年より本格的な整備が始められていた。

そんな「Knowledge Base」と、ソフトウエアを走らせることができるプラットフォームである「ＩＮＴＡＲＦＲＭ開発クラウドセンター」を融合させることで、ＳＥのワークスタイルを刷新したいのだと、迫田氏は言う。

「組織重視の従順型」から「個重視の巻き込み型」への転換

「クリエイティブなエンジニア」を育てようと奮闘する富士通。最後に、今回の変革に伴い、SEのワークスタイルがどのように変わるかと思うかを予想してもらった。

「ひと言で言えば、『面白いことができる人が勝つ』時代になるのではないかと思います。

専門分野や社内外、組織の違いなどにこだわらず、新しい課題を自ら見つけて楽しみながら解決していく。SEはそんな仕事になるでしょう。その影響で、『ここからは仕事、ここからはプライベート』といった区分があいまいになるかもしれませんね」（柴田氏）

「ワークスタイルとはちょっと違うかもしれませんが……今、富士通では、異なる拠点のエンジニア同士がワイワイ集まって開発する環境が整いつつあります。ゆくゆくは、社内の人を巻き込んで『オレの作ったプログラム、すごいだろ？』なんて自慢できるようになるかもしれません。

逆に言えば、こうした環境でも創造性を発揮できなければ、それは自己責任（笑）。わたし自身も、クリエイターへと脱皮しなければと気を引き締めているところです」（迫田氏）

大規模な人事組織の改革プランを打ち出したことで、一歩先を行った感のある富士通。とはいえ、人月計算や多重下請け構造など、まだまだSIerは構造的な問題をはらんでいる。

また、現在のプランにしても、「そもそも顧客の要望をそのまま実装していたエンジニアが、クリエイティブな役割を担えるようになるのか？」など、超えるべきハードルは決して少なくない。

大きく打ち出した人事組織改革を起点に、どう従来型SIerを脱却するのか？富士通の実力が試されるのはこれからだろう。

後半では、いち早くSIerの問題点を捉えて「次の一手」を実行し、着実に歩みを進めている会社のキーパーソンをピックアップ。これからのSEに求められる変化・適応とは何かについて、対談形式で話し合ってもらった。

富士通しかり、SIerを巡る環境は、急激に変わりつつある。それに伴い、エンジニアの働き方も変わらざるを得ない状況だ。

では、エンジニアはどう動くべきなのか。そして、今後はどのようなエンジニアが求められるのか。従来型の受託開発から脱却し、新しいビジネスモデルを実現した企業の経営者2人に、本音を語ってもらった。

株式会社ソニックガーデン代表取締役社長　CEO
倉貫義人氏(@kuranuki)

大学院を卒業後、東洋情報システム（現・TIS）に入社。同社の基盤技術センターの立ち上げや、社内SNSの開発と社内展開、オープンソース化などに携わる。2009年、社内ベンチャー「SonicGarden」を立ち上げ、2011年にTISからのMBOを行い、ソニックガーデンを創業

デジタルコースト株式会社　代表取締役
荻島浩司氏(@kogishima)

SIer勤務、フリーランスを経て、1996年にデジタルコーストを設立。2011年3月よりワークフォース・マネジメントサービス『チームスピリット』の提供を開始。同サービスのリリースをきっかけに、2011年10月下旬には、米セールスフォース・ドットコムより出資を受けることが決まった

月額定額制を採用することで、「納品しない受託開発」を実現

――今回は、従来型の受託開発モデルから脱却し、新しいビジネスモデルを打ち立てたお二人に集まっていただきました。まずは自己紹介の意味も兼ね、それぞれの会社のビジネスモデルをお教えいただけますか？

倉貫　わたしたちが手掛けているのは、ひと言で言えば「納品しない受託開発」。人月ではなく月額定額で顧客とパートナーシップを築き、オーダーメイドのシステムを作る方式です。

クラウド上で動くアプリケーションだけに限定し、小さな機能から開発を進めてすぐ運用。そして、顧客のニーズに応じて要件を変えながら、さらに次の機能を開発していきます。

現時点では、このスタイルの売り上げが半分。残り半分が、社内ナレッジ共有ツール『SKIP』など、自社で企画しているクラウドサービスという状況です。

荻島　わたしたちは、ワークフォース・マネジメント分野のアプリケーション『チームスピリット』などを作り、サービス提供型のビジネスを展開しています。

会社設立から10年ほどは、コンサルティング寄りの受託開発がメインだったんですが、それだと結局顧客に対してアドバイスしかできない点に限界を感じ、自分たちでものづくりをしたいと方向転換したのです。

倉貫今はサービス提供型ビジネスだけですか？受託開発はゼロなのでしょうか？

荻島　サービスに付随したインテグレーションを受託することもあります。ただ、全体の1割弱ですね。今後も割合は減らしていくつもりです。基本は、自社サービスの開発・提供です。

生産性を上げるほど利益が落ちるビジネスモデルに疑問。起業を決意

――お二人が「従来のSIer」を脱却し、現在のビジネスモデルに舵を切ったきっかけとは何でしょうか？

倉貫　わたしの場合は、大手SIerでエンジニアとして働いていた時期の苦い経験が出発点です。当時は、人月でコストが決定。エンジニアが生産性を上げると、かえって利益が落ちるという構造でした。また、一括発注なので、要件が変わってもすぐに対応できません。

こんなビジネスモデルでは、エンジニアにとっても発注側にとってもデメリットばかり。そんな問題意識を抱えていましたね。

荻島　すごくよく分かります（笑）。

倉貫　状況を打開するため、アジャイルの方法論を勉強して現場で適用してみました。ところが、一介のエンジニアや、あるいはマネジャーとして取り組んでみても、どうもうまくいかない。

もしかしたら、営業の仕事の取り方が悪いのかと思って自分で営業もやってみたのですが、それでもダメ（笑）。

これは、「従来型の受託開発」というビジネスモデル自体がダメなんじゃないかと確信したんです。そこで、社内SNSのクラウドサービスの提供を2年ほど前に開始し、昨年にはクラウド上で「納品しない受託開発」をするスタイルで、2年ほど前に独立しました。

これなら、生産性を高めればその分利益が上がるだろうと。

荻島　わたしたちは、2007年くらいにクラウドが登場したころに、自社開発中心に切り替えました。ちょうど、海外のASPが銀行などでも採用され始めた時期。

クラウドなら、ハードもミドルウエアも運用もいらない。それらを扱って利益を上げるような、古いタイプのSIerは半分くらい消え去ると思いました。

だから、わたしたちもASPを目指そうと考えたんです。また、その前後にお客さまからの要望が変わり始めたことも、きっかけの一つでした。

――顧客の要望は、どのように変わったんでしょうか？

荻島　それまでは、人が担当していた仕事をシステムに置き換える案件がほとんど。作る側からすれば、ある意味単純な仕事でした。ところが、そうしたフェーズが急に終わろうとしていたんです。

お客さまの中には、「要件」そのものを持たない、見つけられないところが多くなりました。これも、SIerがなくなると思った理由の一つです。

倉貫　2007年後半くらいから、SaaSという言葉が広まり始めたんですよね。

荻島　そうです。当時、わたしたちはASPの事業を考えていたんです。ただ、ASPにはハードなどの設備投資が必要なんですよね。

倉貫　わたしも最初に事業計画を作ったときは、ASP型で行こうと思ってたんですよ。でも、経費を計算してみたら気が遠くなるような額（笑）。そんなときに出会ったのが、Amazonのクラウドサービスなんです。

これなら、コスト的にゴーサインが出ました。クラウドがなければ、わたしは事業をやってないですね。

大手は背負うものが大きく、中小は人がいない

荻島　わたしたちはセールスフォースのプラットフォームを使っていますが、こちらもまったく同じです。コスト負担も少なくて済むし、何より、運用やハードの管理にパワーを割かなくて済む。アプリケーションやサービスを作ることに集中できる点が大きかったですね。

倉貫　その点、メーカー系のSIerは、自社のサービスやデータセンターを使わなきゃいけませんよね。これは、クラウドと競争する上で大きな不利でしょう。

荻島　おっしゃる通りですね。SIerもそれは認識していると思いますが、ハードや設備という今までの自分たちの存在価値を全否定することから始めなくてはいけないので、変わるのは難しいのではないでしょうか？

――すると、大手より中小の方が方針変更は行いやすいんですね。経営者が決意すれば、すぐに針路を変えられる。

倉貫　背負っているものがない分、身軽なんです。ただ、必要なのは決意だけではありません。受託から自社サービスに切り替えるためには、それにふさわしい人材が必要です。

荻島　そうそう。まず大切なのは、営業ができる人材ですね。受託の場合は、元請けだけに営業しておけばいい。でも、自社サービスの場合は、幅広い顧客に営業しなければなりません。

倉貫　企画やマーケティングができる人も必要になりますね。でも、受託ばかりやっていた企業は、特に中小の場合、適任者を見つけるのが大変です。「大手は背負うものが大きくて、中小は人がいない」というのが、業界に共通した問題でしょう。

荻島　当社では、エンジニアが営業やマーケティングを兼務しています。最近は、TwitterやFacebookなどのメディアを使って営業やマーケティングができますから、営業・マーケ畑生え抜きの人よりも、むしろ最新技術になじんでいるエンジニアに分があると感じています。

特に、マーケティングの対象が一般よりITリテラシーの高い層なら、エンジニアでも十分対応できると思いますね。

――なるほど。非エンジニア職種への転身も、人によってはあり得るわけですね。一方、エンジニアであり続ける人に求められる素養は変わっていますか？

倉貫　当社では、プログラマーがお客さまと直接相談しながら、1人で設計・テスト・運用まで担当します。設計や要件定義、プログラミングなどの役割分担を決めると、効率が悪いと判断したんです。もちろん、お客さまにとっての価値は動くソフトウエアなわけですから、プログラミングできることは必須で、かつ最も大事なことだと思います。

でも、「決められた設計通りに作ればいいんでしょ」という人はムリですね。逆に設計しかできなくて、「なんでオレがプログラミングまでやらなきゃダメなの？」という考え方の人も、どうぞ他社に行ってくださいという感じ。必要なのは、何でもできる人です。

荻島　分業制の時代はもう終わりました。受託開発にせよ、自社サービス開発にせよ、今はお客さまと一緒に試行錯誤しながら要件定義をし、各業界の動きを予測しながらサービスの企画を立て、さらにプログラムとして形にできなければ、「エンジニア」は務まらない。特に、ゼロからものを生み出す企画力は、今後さらに重要になるでしょうね。

昔なら、例えば「営業管理システムならこれ」というデファクトがあったじゃないですか。でも、今のお客さまには「これを作って欲しい」という確固たるイメージがない。ものづくりのゴール地点がないんです。

だから、お客さまのビジネスのレベルから見直して企画・提案しなければダメ。そういう役割を、従来型のSIerは忘れてしまったように見えますね。

倉貫　大手SIerには、インフラエンジニアとアプリエンジニアがいます。でも、クラウドの世界では、そもそも専門のインフラエンジニアはいらなくなるんです。だから、アプリを作るプログラマーがインフラの知識を身に付けたり、逆にインフラエンジニアがアプリの作り方を覚えている。幅が広がっていますね。

SEはインフラやアプリといったポジションにこだわるべきではない

荻島コミュニケーション能力もますます大事になるはずです。もちろん、お客さまとやりとりする力もいりますが、それより必要なのが仲間内のコミュニケーション。会社をサッカーチームに、営業をFW、マーケティングをMF、開発をDFに例えてみましょう。

FWがMF・DFに「ここにパスを出せ」とアピールしたり、誰かがピンチになったらほかがカバーに回ったりしなければ、良いサッカーはできません。そのためには、同僚と積極的にかかわったり、周囲を俯瞰できるような人が望ましいですね。

倉貫　サッカーの例えは、わたしもよく使います（笑）。「トータルフットボール」のように、空いているスペースがあれば誰でも飛びこんでいけばいいと思うんです。

インフラエンジニアやアプリエンジニアといったポジションにこだわる必要はありません。「自称スペシャリスト」ほど使えない。

荻島　そして”球団職員”もいらない。

倉貫　おっしゃる通りです。必要なのはプレイヤーだけ。今のご時世、球団職員はアウトソースが可能ですし。

荻島　プレイヤーであるエンジニアには、素直さと勝とうとする意識を求めたいです。成長するためには、素直で周りの意見を吸収する姿勢が必要。同時に、自分の意思で点を取ろうという気持ちが欲しいです。その上で、日本代表級の選手であれば言うことはないですね（笑）。

倉貫　要件定義だけして人に投げたり、手を動かすことだけしかしない人は、エンジニアとは呼べないと思いますね。ただの部品ですよ。人と話せて、企画ができて、ものづくりができて、サポートもできる人こそがエンジニア。それがプロですよ。

締め切りがなくなったことで「クリエイティブ型」にワークスタイルが変化

――お二人の会社同様、多くのSIerが変わろうとしています。それに伴い、エンジニアのワークスタイルは今後どう変わるでしょうか？お二人の会社での実例もご紹介いただければと思います。

倉貫　よくある開発現場では、進ちょく会議などでメンバーの担当範囲と締め切り日を決めます。でも、わたしたちの仕事の進め方は、そういう「締め切り駆動型」ではありません。各自が担当しているタスクを、リストの上から順にこなしていくんです。

その結果、何が起こったかと言えば、残業がなくなったんですよ。やるべきことはたくさんありますが、締め切りは設けられていないので、時間が来たら「今日はここまで」と切り上げるようになったんです。

逆に、人間って締め切りが近づかないと着手しないところがあるじゃないですか。納期がなくなったことで、そういうサボる心理も消えました。残業は減り、仕事の密度は高まりましたね。

荻島　受託中心だったころに比べて、残業が減ったという話はよく聞きます。大手SIerから転職してきた人によれば、以前は2月まで正月休みが取れないケースもあったそうです。でも、今はきちんと休めている。一方、オフに仕事のことを考えることが増えたと話していましたね。

このあたりは、企画職やクリエイターと似通った感覚じゃないかと思いますね。仕事は生活の一部で、ことさらに分ける必要はない。休みの日でもふと仕事について考えてしまうような、楽しい仕事ができる会社を作りたいですね。

倉貫　同感です！生活のために働くなんて、すごくつまらないですよ。わたしたちは、働く時間は基本的にフリーにしています。年俸制で、いつ出社していつ退社してもいい。働く場所も、どこでもいいんですよ。スタッフの1人はアイルランドにずっといて、スカイプでやりとりしながら働いてます。9時から5時まで会社にいるという働き方は、今後変わっていくでしょうね。

荻島　当社のメンバーは、出社すると一日の行動予定をチームスピリットに入力します。そして、退社時に成果を書き入れて、上司のチェックを受けるんです。「日報」みたいなオールドスタイルな雰囲気ではないですよ（笑）。SNSを使い「いいね」したりして、肩ひじ張らずにやっています。

こういう仕組みを取り入れたのは、古いタイプのエンジニアから脱皮するため。古いマインドを変えるために、行動から変えようと考えたのです。もし、自分自身が古いタイプのエンジニアだという自覚があれば、行動から変えてみてはいかがでしょうか。