自分戦略研究所 | 自分戦略研究室 | キャリア実現研究室 | スキル創造研究室 | コミュニティ活動支援室 | エンジニアライフ | ITトレメ | 転職サーチ | 派遣Plus |

「SEサバイバル論」インデックス


第1回　ユーザー企業がSIerに対して抱く、理想と現実

エンジニアtype
2011/11/21

近年、ユーザー企業の「自社サービスの内製化」や「システムのクラウド化」などに伴い、SIerへの要求レベルが高まってきている。ここ2年で4000億円の減益といわれるSI業界の中で生き残っていくためには、どんなエンジニアスキルを磨いていけばいいのか。

※本記事は、「エンジニアtype」のコンテンツを一部＠IT表記に統一した上で、許可を受けて転載するものです。

　「発注側の方がラクなんだと思ってたんですがね……」
受託側から発注側に転職しても、「開発がうまくいかない」という悩みは付き物。問題は別のところにある

　都内にある某検索サイトの運営会社に転職したばかりのAさんは、表情を曇らせながらそう話す。Aさんはかつてソフトハウスを皮切りに中堅SIerや周辺機器ベンダ、Web開発会社を渡り歩いたSEだった。

　しかし昨年、今の会社に誘われた時点で開発者としてのキャリアに終止符を打つことに決めた。検索サイトを運営する今の会社から、外注先を管理する窓口責任者の職に就かないかという誘いを受け、魅力を感じたからだ。

　この転職でAさんは、10年以上におよぶ「受託開発者」生活から足を洗い、プレッシャーとは無縁の日々が待っているはずだったが、話はAさんの思い通りには運ばなかった。

　当時は2次請け、3次請けの仕事ばかりだったせいで、顧客の意向に振り回されるのは日常茶飯事でした。 意図も理由も曖昧にしか示されない仕様変更に、連日の徹夜作業で応えても顧客の一言で無駄になったり……。

　そんなときはお客さんに向かって「話が違うよ！」って怒鳴りたくもなりましたが、そんな機会はついに一度も訪れませんでしたね。 そもそもお客さんに会う機会なんてなかったですから（苦笑）。

　苦労の末、仕事をきっちり納めても誰に感謝されるでもなく、毎日同じような作業が続く仕事でしたしね。 長年そうした環境にいると、技術力よりも「我慢強さ」だったり「苦労に鈍感になる」能力が身につくんじゃないかと思うほどでした。

　 下請け専門の開発会社に在籍するSEにとって、顧客や発注者は"雲の上の存在"なんだと改めて思ったり（笑）。

　 だからせめて自分が発注側に回ったら、少しは仕事も楽になるだろうと思っていたんですが……。 そうでもなかったっていうのが実感です。

■ 発注者になったものの、板挟みの毎日

　今、Aさんに任せられているのは、社内の企画部門から出される要望をとりまとめ外部のSIerに発注する窓口業務だ。納期や予算をにらみながら優先順位をつけ仕様に落とし、開発会社に指示を与えて機能を実現する。また、技術的なトラブルが発生したときには、現場の最前線で火消しを行う立場でもある。

　毎週、企画側からは新機能のアイデアや改善要求が どんどん提示されてきます。 とはいえ開発に充てられる予算も人員も限られているので、 すべてを一度に満たすわけにはいきません。

　 優先順位をつけて再度調整し、 社内の合意がとれたらいよいよ発注、となるんですが、 今お願いしている開発会社にもちょっと問題があって、 コントロールが大変なんです。言いにくいんですが、担当者の技術力が少しキツい。

　 平たく言ってしまえば、開発にまつわるミスが多くって困ってるんです。

　こちらとしては、仕様をきっちり固めてから発注してるんですが、 なかなかキレイに仕上がって来ないし時間も掛かる。 見積もりも少し高めだし、対応も早いとは言えない。

　 開発会社を替えられるものなら替えたいんですけど、 契約上そうもいかなくて。 トラブルが起きれば社内からは突き上げられるし 開発会社の動きは遅いしで……。発注側に回ればフラストレーションから解放されると 思っていたんですが、結局板ばさみ状態ですよ（苦笑）。

　聞けば、Aさんが入社した前後、協力会社側で過去の開発経緯や事情を知る社員が立て続けに退職してしまったことも、この状況に拍車をかけているようだった。

 

　 もう当時を知る人がほとんどいないので分からない部分も多いんですが、 システム開発当初は社内にエンジニアも外注経験者もいなかったので、 開発会社の言いなりになっていた時期があったみたいなんです。彼らに要望を出してみて「できない」と言われても、 彼らに力がなくてできないのか技術的に不可能なのかが分からない。

　ドキュメント類もソースコードも開発会社が管理しているとは 聞いていましたが、開発の現状を見ているとちょっと不安になってきます。 果たしてどんな状態で管理されているか、社内の誰も知らないんですから、 ふたを開けてとんでもない状態になっていたらと思うと気が重いですよ。

　わたしがこのシステムにかかわり出して1年半ほどですが、 今向こうで開発を担当してくれている人も ここ1〜2年でプロジェクトチームに入った人ばかりだと言うし、 開発する上であまり良い環境とはいえないんです。

　つまり、今Aさんを取り巻く課題の根源は、かつて行われていた「チェックなき丸投げ」がもたらした弊害といえるだろう。開発工程のブラックボックス化が今になってAさんを悩ませているのだ。

　受注側、発注側の双方を知るAさんであれば、課題解決の決定打を見いだせそうだが、いまだその状態にはないという。システム全体を把握している人が発注側、受注側双方に不在という状況の中、それでも開発は続いていく。

　機能的には建て増しの繰り返しなんで、いつかはこのブラックボックスを 完全に開ききらないとマズいとは思っていますし、 社内体制を含め開発会社との関係も立て直さなければとは思います。でもどこから手をつければ良いのか、正直言って分からないんです。

　開発予算も人件費も削減傾向にありますし、 どうせ付け焼き刃的なことしかできないだろうってジレンマがあって……。 ただ、かつて開発者だった経験から言えるのは、 向こうにばかり責任があるとも言い切れないっていうことですね。

　うちの会社には、開発会社の提案を受け入れる余地がないくらい 仕様を固めてから発注するっていう ある種の伝統みたいなものがあるんですが、 心の中では『これじゃ向こうのSEもやる気が出ないだろうな』と思います。『システム開発における受発注の壁を越えたシナジー』なんてセリフ、 どこかで聞いたことがありますが、ここじゃあ夢物語ですよ（苦笑）。

■ 理想と現実のギャップに四苦八苦

　「結果的にSEのやる気を削ぐような伝統も、もしかすると期待に応えてくれない開発会社に業を煮やした、かつての窓口担当者が編み出した苦肉の策なのかも知れない」と話すAさん。そんな彼にとって、理想の開発体制とは、一体どんな体制なのだろうか。

 

　もし、過去のしがらみやお金のことを無視して理想的な開発体制を作れるなら、 社内で完全に内製化するか開発者常駐が良いと思っています。

　関係者同士が離れているとシステムに対する当事者意識ってなかなか持てないものですよね？　

　 わたしも開発者だった時は目先の作業に追われるあまり顧客のOKが出さえすれば良いって考えがちでしたし、 エンドユーザーの使い勝手はどうだとか、 仕様書の不備を指摘して改善提案するなんて発想も 正直言ってありませんでした。

　 プログラマにしてもSEにしても、 マーケティングや企画担当者などといった人たちと、 一緒に仕事ができたら良いシステムが 作りやすくなると思うんですけどね。ここでそれを実現するのは、かなり難しいと言わざるを得ませんが……。

　このように、多くのユーザー企業のシステム部門は、協力会社との付き合い方に四苦八苦しているのが現状である。

　 では、Aさんの話すようにシステム内製化を実現している企業や、SIerと上手な付き合い方を実践しているサービス企業は、外部のSEに何を求め、どんなことを実践しているのだろうか。次回から、ユーザー企業が求めるものを見ていこう。

■関連リンク（エンジニアtype）

【特集：SEサバイバル論 1/4】 ユーザー企業がSIerに対して抱く理想と現実
【特集：SEサバイバル論 2/4】 サイバーエージェントに聞く――期待するのは、優れた選択肢を迅速に用意できるマルチエンジニア
【特集：SEサバイバル論 3/4】 クロスオーシャンメディアに聞く――受・発注者の壁を超え、一歩踏み込んだ提案型エンジニアと働きたい
【特集：SEサバイバル論 4/4】 SEとして長生きするため今すぐ取るべき3つのアクション

» ＠IT自分戦略研究所 トップページへ


＠自分戦略研究所の転職関連の記事一覧
■キャリアコンサルタントのアドバイス記事などを読む
■転職事例の記事を読む
■転職・退職時の注意点に関する記事を読む

自分戦略研究所、フォーラム化のお知らせ

＠IT自分戦略研究所は2014年2月、＠ITのフォーラムになりました。

現在ご覧いただいている記事は、既掲載記事をアーカイブ化したものです。新着記事は、 新しくなったトップページよりご覧ください。

これからも、＠IT自分戦略研究所をよろしくお願いいたします。