SIerのこと知ったかしている子たちへのツッコミ

前回、システム開発でベンダ任せをやめようとした日本、ベンダに任せた米国 - プロマネブログの記事でコメントを頂いたのを思い出したので。

id:sayurin7
paiza開発日誌　2015-01-26
【エンジニア対談】SIer・大手からスタートアップへの転職前に知っておきたい事
でSIerのこと知ったかしている子たちにも何かひとこと、ぜひ

あ～、あまりにも酷かったのでブコメでツッコむ気も失せていた記事ですね。。。

まあ、せっかくコメントを頂いたことですし、確かに間違いを指摘するのも大切なことなので、カンタンに。

自分の知らないこと≠存在しないこと

ITを後付けするんじゃなくて、ITをベースにして今までに無い事業やビジネスモデルを考えるべきだと思ってました。そういう事やるのって受託ビジネスでは無理だから、やっぱり自分はSIerじゃなくて自社サービスを開発する仕事がしたいと。

ATMも、電子マネーも、ネットの電子送金もきっと知らないんです。金融取引などは既に高度な電子化がされてますが、それを受託で開発したのではなく、独力で作られたと思っているんです。多分。

もちろん、ウソですけど。

彼らにとってはおそらく、見えないこと＝存在しないこと、なんです。だから、SIerの仕事は自分の経験した範囲でしか語れない。過去、paizaの記事に何度かツッコミ入れましたが、大体の結論は「狭い経験でしかSIerを語らないし、きちんと業界分析ができてない」です。

SIerの受託の仕事は、当然ですが「裏方」仕事です。ユーザの手助けをする仕事なのに、自分の成果だと喧伝するわけはない。外からはとかく見えづらい。

だから、前述のような思い込みが発生してしまいます。残念なことに。

SIer≠受託ソフトウェア開発

自社サービスに向いている人、SIerに向いている人

前述の、SIerの仕事を知らないってことにもつながりますが、SIerの仕事は受託開発だけではないです。転職前の経験が受託ソフトウェア開発だけなので、それしかイメージ出来ないと思うのですが。。。

実は、オッサンはASPを作ってます。自社サービスですね。パッケージを作っていたりもしてます。

他にも、電話システム構築など、ソフトウェアはパッケージで、回線の敷設や機器導入など、非ソフトウェア開発の仕事も多い。

会社にもよるけど、ウチなんかは受託開発が3割、その他が7割だったりします。*1

SIerと自社サービス開発は相対する概念でないことは、きちんと理解しなければなりません。

そもそも、受託開発のイメージすらも怪しい

佐藤：とにかく能動的な人でしょうね。SIerで開発をしていた時は、何もしなくても仕事を振られたので、それを淡々とこなしたい、受動的でいたいという人はそれでいいのかもしれませんが、僕は「この機能を追加した方が便利になる」と思ったら、「やるな」と言われてもやってしまうような人間なので、受動的でいると楽しくないんですよね。

伊藤：同感です。ルールの中できっちりやっていきたいという人は、SIerがいいかもしれませんね。自社サービスの場合は自分達でルールから作っていかなければならないので、難易度が高い面はありますが、それも含めて楽しいですよね。

受託開発の現場の怨嗟の声を度々聞きますが、「お客が要件を決められない」「SEが仕様を決められない」なんてあります。オッサン自身が淡々とこなすだけで仕事ができた、なんていうのは新人時代のカンタンな仕事ぐらいしか無いので、相当恵まれた職場だったのじゃあ無いのかな。右も左も分からない、新人時代の経験で語っているのかもしれませんが。

SIerの仕事でも、当然誰かが動かなければ仕事は進みません。そして、大体の場合は自分が動かなければいけないわけです。

あと、過去、受託開発時代、「この機能を追加した方が便利になる」と思ったらきっちりお客さんに提案してお金貰いに行ってましたね。ユーザが「やるな」といっているにも関わらずやってしまうのは、「ユーザの反応を見てないこと」になってしまいますし。

便利になることを喜ばない人はいません。もし便利になると思って提案をしていないのであれば、「能動的な人」ではないし、提案しても通らないのであれば、自分の考えに誤りがあるか、きちんと説明するだけの提案力が足りてないのじゃないのかな。

こう言うと「アンタは元請けだから」って声が上がりそうですけど、そんなことはない。元請けの人間だって便利になる提案は大歓迎だし、実際にパートナーさんからの提案を採用している。

佐藤：どっちが良いとかではなくて、きっちり仕様を詰めて設計したものを安定的に作っていきたい人は、SIerの方が良いんじゃないでしょうか。自社サービスは何か機能を作るにしても、仕様書等があるわけじゃないので。

伊藤：仕様書じゃなくてユーザーの反応を見ながら作っていかなきゃならないですし、さっきも話に出ましたけどマネタイズとも向き合っていかないといけないので、そこが厳しいところですよね。でも、そういう厳しさを面白いなと感じられる人は、自社サービスの開発に向いていると思います。

ちょっとこれはいただけない。

前述した通り、ASPの自社サービス作っておりますが、きちんと仕様書は作っております。

ソフトウェア製品ライフサイクル管理を真っ当に理解している人間なら、開発から破棄まで、ソフトウェアをどのようにマネジメントするかを考えなければいけません。

少なくとも、長期（経験的には2年以上）にわたってソフトウェアを使い続けるのであれば、保全計画を考えなければならないわけですが、アーキテクチャを崩さないようにするため、過去開発した機能の理解を形式知としてとどめておくため仕様書は必要となります。

仕様書がなくてもなんとかなるのは保守期間が短期（もしくは使い捨てに近い）のプロダクトだけです。

スタートアップのプロダクトの場合、長期の見通しも立たないことがあるから「仕様書より開発」を優先するのはわかります。おそらくギノもそうなのでしょう。

ただし、その限定的な経験を持って「自社サービスの特徴」とするのは主語がでかすぎる話です。