元ド底辺SIerの私が心機一転、スタートアップに参加して約1年半が立ちました。
今後の自分の仕事を占う意味でも、ここらで自分がこれまでに感じたこと、悩んだこと、考えたことを整理しておこうかと思います。
もしも現在、SIer系の仕事をされていて、いずれはベンチャーで働いてみたいという人の参考になればもちろん嬉しいのだけど、ベンチャーってのは本当に千差万別で、ここで書いたことがそのまま他のベンチャー企業に当てはまるとは限らない、ということだけはご了承を。
「仕様」って言うな！
最初の問題はこれ。
SIerにとって「仕様」って言葉は絶対的な意味があるわけですよ。
お客様から要求を聞いて、要件を定義して、「はい、コレコレこういうもの作りますよ。この製品ではこういうことができます。逆にこういうことはできません。よろしいですか？」と約束した結果が仕様だから当然と言えば当然。だからこそ、仕様を定めることに多くの時間と労力を費やすわけです。最終的に納品してみたら、「え、何コレ？ こんなものを作ってくれなんて言ってない！！（怒）」とか言われるとか、まーありえないですよね、ふつーw
当時、聞かされた言葉に「バグか、それとも仕様か。そのどちらかしかない」というものがありますが、これこそまさにSIerの命題を言い表しているような気がしてなりません。
しかし、ベンチャーでは「仕様」という言葉を使っちゃダメなんですよ。
なぜなら仕様なんてハナから存在しないから。そもそもベンチャー企業には最初、顧客すらいないんですからね。
あるのはアイデアとかビジョンとかそういったものだけ。それをブレイクダウンしていき、やがて最初の製品として具体化する段階ではたしかに仕様らしきものは定めなくてはならないけど、それはあくまで一時的なものだと言うことを理解する必要があります。
ベンチャーにとっては製品＝実験なので、実験の結果によっては素早く修正、ときには丸ごと破棄することさえしなきゃいけません。
SIerの「仕様がすべて」みたいなマインドだとそういった動きについていけないです。それに自分から積極的にアイデアを出し、バグとかのリスクも承知の上で一種の冒険心を持って開発していく、ということもまずできなくなるでしょう。それでは、ベンチャーとしては致命的です。
自分も最初の頃は、「この画面のリスト表示の順序はどういった仕様にしましょうかね？」みたいな質問をしてましたよ。今考えると馬鹿みたいですが、それだけ前職の思考法に染まっていたし、重要なことだと思っていたわけです。
それにしても「仕様」って言葉には、「約束通りコレコレこういうものを作ったんです。それ以外のことは私は知りません！」という責任回避的な意味合いが感じられて仕方がない。まあ、当時は自分もよく使っていたわけですけどねw
ともあれベンチャーで働くならば、自分の頭の中から「仕様」という言葉は削除しておいたほうがいいでしょう。
「品質」ではなく「価値」
SIerの場合の品質とは大体、お客様が希望するものと一致した製品を作り、かつバグがない状態で納品することです。だからこそ、膨大な手間ひまをかけてテストをし徹底的にバグを取り除く訳です。よく言われていることの一つとして、製品に「バグがない」ということを証明するのは、それこそ何億年も費やしても絶対にできないわけですが、とにかくものすごい努力を費やして、その可能性をゼロへと近づけていくわけです。もしもバグによってお客様に経済的損失を与えようものなら責任問題、ひいては賠償問題にまで発展しますからね。当然と言えば、当然のことです。
しかし、納品した後にバグがでない限りは、お客様がその製品を使って最終的にはビジネスゴールに達成できたかどうかまでは責任は持たない、というのが普通でしょう。
一方でベンチャーの使命は、新しい価値、ひいてはビジネスモデルを生み出すことです。
たとえまったくバグのないプログラムを書いたとしても、それが誰にも使われなければ意味がないんですよ。
バグがあってもいい、というわけではないけどベンチャーで働く際には「品質」という言葉の意味をもう一度考え直す必要があるわけです。
何かの本で読んだ話ですが、その昔、初期のMySpaceではHTMLサニタイジングのバグがあって、ユーザが自由に任意のHTMLを自分のプロフィール画面に入れこむことができたらしいんですよね。でも、それがむしろ「自分にぴったりのプロフィール画面が作れる！」とアメリカの女子高生の間で話題になって、MySpaceが広まる要因になったそう。
HTMLサニタイジング漏れなんてセキュリティ観点から見るととんでもないバグで、こんなものSIer系エンジニアからすると、どんな吊るし上げを食らうかわかったんもんじゃない、と想像するだに恐ろしい事態なわけですが(笑)、このエピソードは「バグがない」といったことよりも、ベンチャー企業がフォーカスしなければならない重要なことが他にあるんだ、ということを示す良い例だと思います。
SIer出身のエンジニアはバグに対する恐怖が他の業界のエンジニアに比べて大きいような気がするんですが、その恐怖心を克服して価値とかビジネス的なチャンスに対して意識的にアクセルを踏み込んでいかないといけません。
とは言っても基本的にはバグが出ていいはずもないので、トレードオフを意識しながらクリティカルなところはちゃんとテストを書いておくとか、ちゃんとCI的な環境は用意しておくとか、そういった目配りも重要です。
でも、カバレッジをとにかく100%にするだとか、盲目的に条件網羅試験をするといったようなことはやめましょう。そんなの、ただの自己満足ですから。
スピード、そして作らないこと
スピード、超重要。いや、SIerにだって重要ですよ。だって納期が短いもん(笑)
しかし、違うんです。SIerの場合、納品物の対価としてお金を頂くわけですから、「そんなもの作っても無駄だから開発しません」というジャッジはしにくいわけです。最終的な顧客満足度を引き上げるために、あえてそう物申す剛毅な業者もいるかもしれませんが、基本的にはお客様が欲しいと思う物を作って、結果としてお金が頂ければそれに越したことはないわけで。
なので、SIer系エンジニアは「とにかく作ろう」というマインドになりがち。少なくとも私はそうでしたね。
もちろん素早く形にすることも重要。でも同じくらい重要なのが、作らないという決断をすること。
作るより、作らない方がそらもう格段に速いので。
でも、じつは日頃から色々と情報収集をしていないと「作らない」という意思決定は難しいんですよね。
自分も、ライブラリとか、類似サービスとかの存在をただ知らなかったために作り始めはしたものの、後で存在を知って「ああ、しまった」となったことが何度かありました。
いや、ちゃんと事前にリサーチはしてますよ。しかしまあ、調査しきれない場合もあるので、やはり日頃からの蓄積が重要ということですよね。
あと自分たちのビジネスゴールを含めて、目的意識を明確に持たないとなかなかそういった思考になっていかない。
ベンチャー領域にやってきて、ビジネスゴールの重要さが身にしみましたが、以前はあまりそういったことを考えていませんでしたね。
まあ、SIerのビジネスゴールは顧客満足度を維持しながら納品してお金を頂くことなので、あまり深く考える必要がなかったというのもありますけど。
ともあれ、そういったことを含めて、一番速くゴールにたどり着ける方法をいつも考えないといけませんよってことで。
「分業」より「協力」
SIerの特に多人数が関わる開発の場合、一人一人の役割分担が明確になっていて、効率のよい分業の仕組みが構築されていることが多いと思います。
※というか、そのように体制が構築できていないとしたら、マネージャーの管理責任が問われるでしょうw
しかしながら、そういった体制を長年続けていると、決められた範囲はやるけど、それ以外は一切手を出さないというマインドにどうしてもなりがちです。
そりゃあ、担当外のところに手を出して、結果としてバグを作り込んじゃったら責任を追及されますからね。とても割に合わないw
ところがベンチャーではこういった分業はできません。そもそも、何をするべきか？がわかっていないことだってあるんですから。
自分たちなりに仮説を立て、施策を考えて、やってみて結果を確認する、の繰り返し。
SIerの大規模プロジェクトで事前に作業をすべて洗い出して、工程表を作成しておく、とか今思い出すともう世界観が違いすぎるのですよw
人員だって絶対的に足りないし、対処すべき問題は大抵は複合領域上に存在していて、プログラミングなどの専門知識だけでどうにかできるわけじゃありません。
「それ、マーケティングの領域でしょ。おれ、プログラマーだし」
「そこのHTMLはデザイナーの言われたとおりにしただけ」
みたいな不毛をやっている余裕、ベンチャーにはないんですよ。
重要なのは「自分の強み」を生かしながら、互いに協力しようという姿勢です。たとえ専門外でも下手くそでも、他の仲間にその余力がなければ自分から手を出していかないと仕事が回らないんです。「俺、そんなのやったことねーよ」とかすぐ口にする人はベンチャーには来ない方がいいです。きっと、すぐに心が折れますから。
必要性に気がついたら、まずは自分自身で行動するようにしないと「〇〇が何々をしてくれない」「××がないと仕事ができない」という不満ばかりがたまってしまいます。
何もないところから始めるのがベンチャーなんですから。文句を言ったって始まらんのですよ。
そういったことの一例として、私は毎週、事務所のトイレ掃除することにしています。
事務所の掃除をメンバーに呼びかけた手前、他人がやりたがらないところを引き受けたというわけ。結果、他の仲間たちもしぶしぶ掃除をしてくれていますw
最後に
なんか書いてみたら、思いのほか長文になってしまった。
読み返してみると、なんだかSIerという業種をdisっているような内容になってしまいましたが、そんな思いは全然なく、ただ色々と違うんだよ、ということが言いたかったのです。
SIer時代に叩き込まれ、身につけた論理思考力とかマネジメント力、分析力はきっちり血肉となって今の自分を支えてくれています。あの時代に自分が周囲の人々に助けられ成長したように、ベンチャーという異なった領域でも大きく力を伸ばしていきたいと考えてます。
(苦|楽)しいぜ、ベンチャー！
記事の内容について、ご意見、ご批判、その他なんでもあればぜひとも藤井までご一報ください！
2013/1/15 追記
わりと身近な人向けに近況報告をかねて書いた記事が、想像以上にたくさんの人に興味を持ってもらえたことに、正直驚きながらも感謝でいっぱいです。
頂いたはてブコメントを眺めていて印象的だったのは、SIer業界に対する批判のように受け止められていることが多いな、ということ。
まあ私の書き方もあるのでしょうが、単純に自分がSIer->ベンチャーとフィールドを移した際に、どうしても考えや仕事の仕方を変えなければいけなかった点についてまとめただけなので、各業界についてどーだこーだという気は私自身ありません。
たかだか私の数年やそこらの経験が、すなわち業界の一般解だとは到底思えませんので。
ただ、読んで下さった方々の感想は大変良い刺激になりました。「そういう見方もあるのかー」と感心することもありました。
この場を借りて、私の拙い文章につきあって下さった皆様にお礼を申し上げます。ありがとうございました！
それにしても働き方とか、業界ネタとかに興味を持っている人はけっこう多いのだなー。
よし、調子にのってまた書こう！w
