受託開発より自社サービス
自分たちで工夫したサービスを出したい
―― 開発のスタイルに特徴などはありますか?
渡邉 多くの会社では、フレームワークみたいなものを開発して、その中でコーディングのルールがきっちり決まっているという仕組みを採用しているのではないでしょうか。しかしそのフレームワークに足りない部分があると無理矢理な実装になりがちです。そうなるくらいなら、求められている機能をいかに確実に速くシンプルに実装するかという部分に特化して、全体がグチャグチャになってきたら、積み上げたナレッジだけ引き継いでゼロからリビルドするほうが清々しいです。
ただこの方法は中途半端なものは嫌だというプログラマーには向かないかもしれない。僕らはどちらかといえば、やりたいことの大枠と途中の目標までが決まっていて、残りを自分たちが産み出す余地がある方がやっていて楽しいというスタンスです。
―― 先ほど受託開発が中心だと聞きました。そこからどのように、今の自社サービスの体制に移行されたのですか?
間下 最初は受託開発をやって収益力のある会社と、おもしろそうなことをやる会社で分社してました。でも、nice to meet youが伸びてきて、そこに全力投球しようと決めたのが2006年4月のことです。人も一気に後者に集中しました。受託で食べていけるのに……という雰囲気は現場にはありました。正直退職者も少なくありませんでした。
受託開発は手堅いんですが、常にクライアントの指示に従わないといけません。もちろん今はユーザーの意見を聞いて開発を進めるのですが、最後にどういう仕様にしようと決めるのは自分たちです。そもそも新規ビジネスなんて早々当たらないので、十発撃って一発当たればいい方くらいの気持ちでやらないとできませんし、チャレンジしないと永遠に受託開発を続けることになります。そう割り切って移行しました。
渡邉 逆に今まで自社サービスを開発したことがなくて、ずっと「TV会議チームは派手だし面白そう」って思っていたエンジニアは「待ってました!」という感じでした。自分たちで決めた自分たちのサービスを出すのって面白いと思うんです。気になっているテクノロジーをこっそり入れてみるといった、エンジニアの魂を揺さぶるような仕事は受託開発ではやりにくいです。
―― 挑戦した方が結果につながる、といった考えなのでしょうか。
渡邉 エンジニアにしてみるといい会社かもしれないですね。ダメだったとしても無駄にはしないですから。必ずなんらかの形で次には繋げるようにしています。
間下 ですから一緒に働きたいエンジニアは好奇心がある人。技術力は好奇心があれば必然的に高くなります。広い知識があってそれを組み合わせる能力がある人が力を発揮するように思います。また、コミュニケーション能力も重要ですね。
渡邉 あとはとにかくこだわりのある人かな。せっかく自社サービスを展開するのですから、○○がやった仕事だからこういうサービスができた、という形に繋げられる人。たとえどんな小さなことでも、言われたからこうしましたではなくて、「僕はこう考えて、こうしてみました」と取り組んでもらいたい。その方が最終的に製品に対する思い入れも強くなるだろうし、愛をもって取り組んでもらえる。本当に大変なときにはそれがないと乗り切れないように思います。
間下 求められている機能をそのまま実現するのは経験を積めばある程度はできるようになりますが、求められている以上にどう工夫するか。いい方に裏切るためにはこだわりがないと。求められているものがわかるのはもちろん、わかった上でこだわらないと。それができる人はやっぱり楽しいですよね。
この連載の記事
-
第12回
ビジネス
下部構造から脱却する人材育成を──ITSSの狙い -
第11回
ビジネス
なぜITSSの導入は失敗してしまうのか? -
第10回
ビジネス
エンジニアのスキルを共通の「ものさし」で計るITSS -
第9回
ビジネス
「メインフレーム終焉」のウソ(後編) -
第8回
ビジネス
「メインフレーム終焉」のウソ -
第5回
ビジネス
日本発の最注目サイト「pixiv」のヒミツ(後編) -
第4回
ビジネス
日本発の最注目サイト「pixiv」のヒミツ(前編) -
第4回
ビジネス
ビジネスの発想を身につければ研究者は即戦力になる -
第3回
ビジネス
目的がハッキリしていれば産学公連携は成功する -
第2回
ビジネス
コンテンツ消費の縮図「とらのあな」が考えていること - この連載の一覧へ