Hatena::ブログ(Diary)

yvsu pron. yas このページをアンテナに追加 RSSフィード

2008-06-19

SIerが必要としているのは業務知識だという都市伝説

SI業界が開発するシステム目的は何か? それがつまり「業務知識」というやつで、金融保険だったり、証券取引、財務会計生産管理物流在庫管理、販売管理だったりするのだ。それぞれ必要とされる知識は非常に多い。普通新入社員OJTで身につけようと思ったら数年かかってもおかしくないだろう。

スーパークリエイターがSI業界で即戦力になれない理由 - aikeの日記

金融(ディラーが使うようなポジション計算をするフロントシステムリスク計算をするようなミドルオフィス、勘定系のバックオフィス)、流通、輸出入、製薬など、いろんな業務をやってきたおいらが通りますよ。


確かに金融は業務知識がないと歯が立たない。でも、自分の経験した限りでは、それ以外の業務は、案件が始まってから勉強しても十分間に合います。

一週間以内の勉強で、お客様のところにいってシステム仕様を話し合うことはできるようになります。もちろん、この道何年って人にはかないませんよ。でも、仕様を決める分には困らない。


ある業界用のシステムを何年もやっているとするじゃないですか。その業務知識は、すごく役に立つとみんな思っているかもしれません。しかし、同じ業界でも、お客様が違うと業務知識が結構異なることも実は多いんです。だから、業務知識が豊富でも、それが全部有効になるとは限らないのです。

特に日本は、パッケージに合わせるのを嫌うから、会社ごとに自前の業務になっていることが多いんじゃないかなぁ。


豊富な業務知識を事前に持っていないとSIができないというのは、金融以外では都市伝説だと思います。


にもかかわらず、SIerにいくと技術的なスキルより業務知識のほうが重要だと思っている人が圧倒的に多いのは事実です。どうしてかというと、そのように教え込まれたからです。刷り込みですね。

汎用機の世界では、技術的な部分で差がつくことはほとんどなかった。だから、差別化のために業務知識が重要視されたのです。

なぜ、プログラミングが軽視されたかについてはSI業界の老害が若手と下請けを蝕む理由を参照してください。


このようなプログラミングを軽視し業務知識を重要視する考えが、SIerでは、先輩から後輩へ脈々と受け継がれています。今では、プログラミングは発達し、人によって大きく生産性は違ってくるのに、その事実を知る機会がないのです。

しょうがないよね。新人のころから、「プログラミング付加価値の低いものだ。付加価値をつけるためには業務知識を身につけなければならない。」そう教え込まれたら、誰でもそうなるでしょう。


でも、現実はそうではない。(私の知ってる限りは)金融以外の業務知識は、プロジェクトが始まってから勉強しても十分間に合います。工数見積もりをする人が、業務知識をあらかじめ持っていればそれで十分なのです。

それよりは、技術的なスキルを身につけ、ユーザの要件をいかにシステムに落としこめるかを知っていることが重要です。要件を技術に落とし込むスキルは、勉強しても身につかない。経験をつむしかありません。でも、技術的なスキルは、勉強して身につけることができます。SIerに入る前に身につけた技術的なスキルが、無駄になることはないのです。


技術的なスキルのある学生は悲観的に思う必要はありません。そのスキルは、SIerに入っても役に立ちます。でも、ちゃんとしたSIerかどうかは、きちんと見分けなければいけません。技術が付加価値の低いことだと思っているSIerはさけ、「技術と業務知識は重要、そして何よりも重要なのは、要件を技術に落とし込む能力」そう考えているSIerを選びましょう。


ブクマコメントにあるように、ユーザ企業に昔から入り込んでいるベテランSEが、ユーザ企業から重宝されるのは事実です。システム部が要件を決められないから。でも、そのせいで、ベンダーロックインが起こり、高いコストを払わされているはず。

システム部が弱い企業は、高コスト体質になりやすいので、いずれは、淘汰される可能性が高いと思います。システム部ごとアウトソースする場合もあるけど、その場合もベンダーロックインが起きます。

ITを生かした企業にするには、しっかりしたシステム部が必要だと思います。

私の書き方が不十分だったので、続きとして深い業務知識が必要なのは案件の提案者と要件定義者エントリを書きました。

元SIer元SIer 2008/06/19 21:08 ・しっかりしたシステム部(独自でしっかりとした業務知識があり、なおかつ業務改善を含めたシステム提案ができる能力)があれば、外部のパートナー的SIerに期待するところは、単に人月を支える工員調達力です。そういったところでは、おっしゃっている通り「一週間以内の勉強で、お客様のところにいってシステムの仕様を話し合うこと」はできるでしょう。
・逆に、大多数のいわゆるユーザー企業のシステム部門は外注の作ったシステムのお守りが関の山であり、そのお守り自体が外注任せの現状で主業務はシステム企画になると考えます。そういった組織においては、外部のSIerに期待するところは「一週間以内の勉強」程度の付け焼刃SEではなく、業種の業務知識を持ち、業務システム構築経験を持つシステムエンジニアリング能力の提供でしょう。

・そうなると、SIerと呼ばれる企業において必要とするのは、後者の”提案力を持つエンジニア”であることは自明のはずです。SIerのSIerたる所以は、単なる労働者の派遣ではなく、より大規模なシステムの構築と提供にあるためです。だからこそSIerの個々SEに対しては、顧客と「対等に」業務設計が行える業務知識が要求されるのです。つまり、適う適わないとかそういう話ではなく、ビジネスロジックの構築と多機能間において業務レベルでのバグを出さないことが本来SIerに求められることだと、私自身は考えてきました。

・そういった意味では「SIerが必要としているのは業務知識だという都市伝説」は都市伝説でもなんでもなく、本論であるといえるのではないでしょうか。だからこそ、SIerが大枚を叩いてでも外部からキャリア採用を進めているのです。案件規模で言うと、100人月程度の数億円規模ではなく、数百人月の数十億〜百億以上の受注能力を持つSE(実態PMですが。)を求めているのです。キャリアパス的に、SE程度で終わられては教育コストや、雑な(1週間程度の付け焼刃で設計された)設計やテストで割り増しされた損失すら回収できていません。
・そもそもの、「技術的なスキルのある学生」はSIerを目指すべきか?という議論では、そのもともと持っている能力を活かせるという勘違いが不幸を生むと考えます。どうしてもSIerで働きたいというのならば(報酬が目当て?入社動機がよく理解できないが)、SIer内での技術系部門に配属されるようアピールすれば希望がかなうかも知れない。私自身としては、どうしてもその能力を活かしたいのであれば、大規模なSIerではなく、ソフトウェアハウス的な企業や、それこそWebサービスを提供しようとしている企業への就職を勧めたい。

perlbakaperlbaka 2008/06/19 23:01 まあプログラマの味方のつもりで書いてれば、アクセス集まるからエントリーしてると思うが、そのスキルのあるプログラマーとやらは、なぜ単価が安いですかね。数多く業務を経験しているとかいっている割にはプログラマー重視とかわけわかめですね。重要なのはユーザの要件をいかにシステムに落としこめるかって、それってプログラマーの仕事でしたっけ?だから数多く業務を経験できるはずです。結局いらないってことよ。

juasjuas 2008/06/19 23:21 金融だけって余りに乱暴。例えば自治体や官公庁、エネルギーとか病院とか、案件始まってから勉強するってあり得ませんね。

kenji_jpkenji_jp 2008/06/19 23:58 私も「業務知識が重要」は都市伝説論は反対ですね。
たとえば生産管理の一部とかならまだしも(これも怒られるか・・・)、たとえばバイオサイエンス、知的財産なんて1週間程度では用語さえもさっぱりわからないと思います。

おいおいおいおい 2008/06/20 00:11 大丈夫ですか、本当に。
顧客がシステム要求が分からないからこそ、業務知識とSI知識を持ち合わせたエンジニアこそが信頼を得られるんでしょ。

業務知識しらないようなマネージャがカウンターに出てきたら、即刻返品されますね。確実に。

kagehienskagehiens 2008/06/20 01:28 確かに、本来、それなりに論理的な考え方の出来るユーザ企業担当者相手ならば、
外部の業者に求められるものは翻訳して実装するスキルなので、
ソフト開発業の従事者に求められるのが業務知識だなんてのはまさに都市伝説である筈でしょう。
差別化のためにそう刷り込んだ、という発生の背景もまったくもって正しいと思います。

問題は、論理的な考えに基づいた要望を出してくる顧客というのがかなり希少であるため、
SIerがそれを代行する羽目になっていて、あながち外れでもないということと、
あまりにその都市伝説が広く浸透しすぎたため、こんどは疑うことも出来なくなってしまい、
そういうものだと思ってしまっている人が大勢だということ、ということでしょう。

一方、本来、エンジニアというのは技術屋さんという意味であって、研究者でもなければ、
営業担当者でもないわけで、そうなると、最も要求される能力というのは技術による問題解決力だと言えます。


つまるところ、SI業界では、エンジニアではない人員が多く必要だということなのでしょう。


※自分の専門分野に絡んだ問題に対しての、専門分野に拘らない対処能力(解決できない問題も存在するので)を
 保持するためには、関係各方面に対する日頃からの深い考察が絶対に欠かせないと思います。

kagehienskagehiens 2008/06/20 03:45 >tさん
的確なレスありがとうございます。

>話が抽象化されていますが対処能力(業務知識による対処)も必要である。
>つまり業務知識も必要ということですよね。

概ねその通りです。ただ、どういう種類の対処能力が重要かは、その人の環境によって異なるので、先のような書き方をしました。
顧客の役に立つためにも自社内での調整力が最重要という環境もありますし・・・。
エントリ本文にもある通り、業界が一緒でも全然必要とされる知識が違うなんてのはよくある話ですし、
ユーザ特有の事情を聞く前に全部わかってるなんて事はありえないわけですが、
業界を問わない基本的な企業内の処理については、嫌でもそのうち覚えられる筈で、
それが押さえられていないと流石に不味いとも思います。

ちょっと通りますよちょっと通りますよ 2008/06/20 07:06 >しかし、同じ業界でも、お客様が違うと業務知識が結構異なることも
>実は多いんです。だから、業務知識が豊富でも、それが全部有効に
>なるとは限らないのです。

これは日本の持っている非常に弱い部分ですね。
つまり、同じ業界内ですら業務の規格化ができていない→会社毎に対応せざるを得ない→業務知識が無くても間に合ってしまう(間にあわさざるをえない)という流れですね。
だからパッケージソフトで対応できないしその結果システムがより独自性を持って孤立する上にコストがかかってしまい何か起こったら自分のところだけの問題で誰もソリューションを即座に提供できないという悪循環。

元SIer元SIer 2008/06/20 09:01 再度粘着のように書いてしまいますが、ブコメなどで誤解があるようです。
・SIerに発注をかける規模の顧客で求められることは、業務システムの構築であってその中身が高度で先進的な技術で構築されているかどうかは問われません。当たり前ですが、業務システムは長いと10年近く使われるものもあり、基幹業務の基幹ロジックになると数十年使われるものもありますから。また、企業の業務というものは大きく変わる(新規開発する)ことは少なく、むしろ法令の改正や、細かいルール変更に対応するような(保守開発の)機会が多くなるからです。つまり、新規開発の割合よりも保守開発の割合が多いのが企業の業務システムの特徴と考えればよいでしょう。
・そうなったときに、一時的な流行りや個人の思いつきで書かれたプログラムは問題外として、変にテクニックを駆使して書かれたプログラムほど厄介なものはありません。むしろ保守作業で技術力の高いプログラマの調達が必要になったり、その部分を一から書き直したりすることまで発生するためテクニックを駆使したプログラムが嫌われたりします。自分自身では生産性を高めたつもりであっても、システムのライフサイクルから見れば厄介な種を仕込んだにすぎません。企業の業務システムは、一人でメンテナンスできる規模の話ではなく、また個々人のボランタリ精神に頼って済む話でもないのです。業務改善の必要性が出る時期(法令施行時期など)までに、必ず改修する必要のある話です。※上場企業は、今年度から内部統制の強力な縛りに追い立てられ、業務システムも当然その範疇に入っています。

・結局、SIerを求めるような企業にとっては、システムのライフサイクルこそが重要なのであって、一時期さらには一担当の生産性や記述テクニックの高度さなどはむしろ邪魔であると言い切ってもいいかと思います。だからこそ顧客データ数千万件を抱えるような企業においては、いまだにホストコンピュータやCOBOL言語を利用し続ける企業が後を絶たないのです。2000年問題の際に、そういった個々人が思いのまま書いた箇所を一から書き直している姿を多々目にしました。
・一時期、基幹業務システムをLAMPなどの基礎技術を利用して「枯れた技術で構築したからモウマンタイ」と抜かしてた企業がありますが、他人事ながら個々末端に至るまで枯れた技術だったのかどうかが不安になります。一部のメンバーがその時期にたまたまはやっていたテンプレートエンジンなどを使っていて、それがメンテナンスされなくなっている可能性などがないのか?ブラウザのバージョンアップに耐え切れないのではないのか?そこまで考慮したうえで利用する技術を選定する必要があると考えます。それが企業の基幹業務システムを構築することの厳しさだと思っています。

・私自身、すでにSIerを離れて久しいですし、未だにそんなに魅力のある職場とも思えません。ましてや、若くして技術を身につけた方々が目指すべき職場だとはとても思えません。視野を広く取り、自分が将来30歳、40歳になっても続けられるような職業を見つけるに越したことはないでしょう。

hoho 2008/06/20 10:06 >案件が始まってから勉強しても十分間に合います。

単にそれは設計フェーズだったからでは?

あと、それが単価競争となり、老害が発生するのかと。

kerker 2008/06/20 15:42 政党選びと同じで、日本人の性急性と異常なまでの安定志向の結果でしょ。

akiaki 2009/02/07 18:08 今では、プログラミングは発達し、人によって大きく生産性は違ってくるのに、その事実を知る機会がないのです。
==>根本的に思想がおかしいですね!!  プログラミングが人に依存する事自体が致命的に問題のあるポイントです。 目指すは、保守運用フェーズにおいても、どのレベルのPGMでも保守可能な技術レベルです。

なまえなまえ 2009/03/07 01:30 SIerは、1995年頃に「batch」という関西の人が「SI屋」と小馬鹿にして呼んだのが語源と言われています。
当時から元請業者は大したスキルを持っておらず、すべて下請業者頼りだったことからそう呼んだのだと推測されます。

むんむむんむ 2011/10/07 22:20 たとえば、システムが障害した場合に
排他制御がうまくいかずテーブルロックがかかったままデッドロックしたことが原因で
HTTPがタイムアウトして画面が表示されませんでした。
しかも、その後DBのロックプロセスは残り続け、DBサーバが過負荷となりサーバダウンを招いたことでキャッシュも失われ
過去どれだけ分の何とかのキャッシュデータが紛失してしまいました。

というような内容についてを、システム音痴な客でも腑に落ちる形で説明できる能力が一番大事ですね。
システム障害すら明快に説明できないようなDQNは、存在自体が不要。さっさとGCされるべき存在。

業務知識とか、技術スキルとか…客にとっては、そういう上っぺらな話ではなく
もっときちんと順を踏んで物事を説明して、共に議論できる業者が必要なんですよね。

知識だとか、ナントカりょく云々ではないと思います。

投稿したコメントは管理者が承認するまで公開されません。

スパム対策のためのダミーです。もし見えても何も入力しないでください
ゲスト


画像認証