yvsu pron. yas

元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サービスを提供しようとしている企業への就職を勧めたい。

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

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

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

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

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

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

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

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


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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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