SIとスタートアップの違いを知ろう

ちょっとした行動の違い

新しく現場に入ってきた方の、技術的なオリエンテーションを担当しています。技術的って言っても、そこに密接な「仕事の仕方」的な話もします。

やはり、ポイントとしては、
「SIとスタートアップ」
要は...

SIerと事業会社でのプログラミング仕事するときのちょっとした行動の違い

で、今まで何度も何度も話をしてきたので、さすがにちょっとブログにまとめようかと。

Lastaの資料がちょうど

とはいっても、ここにつらつら書くの大変なので、まずはこちらの資料をご紹介。

LastaFluteの誕生 | Speaker Deck

こちらの「A」の章をごらんください。

ケースバイケースではありますが、特徴をポイントごとにまとめてみました。

まあ、こういった特徴の違いがあるってことは、その分、プログラマーの行動にも、ちょっと影響があるわけで。

ここって、巷でよく話題になることはありますが、その時々のポイントでアドリブで語られるだけで、
あまり...
「こういうポイントだとこう違う、
　ああいうポイントだとああ違う」
みたいに、整理されてるのって少ないかなと。

このスライド資料自体は、LastaFluteというフレームワークを公表するにあたって、そもそもそこの違いが明確になっていないと、そのフレームワーク自身の存在意義を語ることもできない(DBFluteも同じく、DB変更の話をしないといけない)、ということから、ちょっと色々な人にヒアリングしたり、自分の経験もまとめたりして書いたという感じです。

それが、ちょうど役に立つなぁと。

もちろん、SIerでもスタートアップっぽいところ、事業会社でも堅くやっているところもありますから、あくまで「どちらかといえば」という感じです。

SIのことを知るきっかけにも!?

ちなみに、こないだ講演会してきて、ちょっとおもしろい反応もらったのが、スタートアップの話をメインに紹介しているのに、「SIのつらさ話」の方に深い頷き反応があったりw... まあ、SIの方にも理解してもらえたと言えるでしょうかね笑。

あと逆に、昨今の事業会社だと、SIを経由したことのない人も多くなってきました。なので、SIってどんな仕事の仕方してるのか、よくわからないって人も周りに多く、「ネット上のSIあるあるネタがわからないー」ってよく言ってるから笑、自分たちの大切にしている特徴を知るためにも、SIの特徴も知っておくといいんじゃないかと。

例えば「本当はこうした方がいい」というところも、スタートアップだと色々な都合でわざと捨ててるけど、最初から無いものだと思っちゃってると、それが本当に必要になるタイミングを知ることができないので、「わざと端折ってる」っていうのを意識しておくことは大切。

ちなみに、個人的には、事業会社に行って使わなくなった言葉って、「仕様」「人月」「炎上」ですかね。

要件はあるけど仕様はないって感覚。人月って考え方はどっかへ吹っ飛んで。炎上は常に炎上してるから炎上じゃない。

OrderByの仕様は？

ちょっと簡単な例をちょっと挙げてみます。これをプロトタイプに色々なケースに当てはめて頂ければと。

とある画面を作ってくれ、と頼まれて、作っています。実装しているとします。

とある一覧部分のデータの検索をしようとしたとき、そういえばソート順がはっきりしていない。

「あれっ、OrderByの仕様は？」

さて、どうしましょう？

SIでよくあるのが、プログラマーがソート仕様を仕様策定者に確認を取りにいきます。仕様策定者が決められないなら、お客さんに決めてもらい、そこで決めたものがソート仕様になります。(決めてもらえなかったり...)

スタートアップでは、プログラマー自身が仕様策定者であることが多いです。画面を作ってくれと言った人も、「そんな細かいことまでは決めてらんない」
という感じでしょう。その人がもっと大きな粒度のビジネスを考えてる人だったりするとなおさら。

A. プログラマーが自分で決める

だから、プログラマーが自分で決めます。実装しながら。でも適当でいいわけじゃないです。その画面の役割を考えて、こう並んでたら良いだろうと想像をして、会員が喜びそうなソート順を導きます。

仕様を探すのではなく、あるべき姿を探す

というところがポイントです。

B. プログラマーが提案する

逆に、ソート順が決まっていたとします。聞いたら教えてもらったとか、決めてもらったとか。でも、そのソート順よりも良いソート順があれば、プログラマーがそれを提案して議論して実装します。

言われた通りに作って「そのソート順は微妙じゃない？」って後から言われて、「いや、それは言われた通りに作っただけなんで」ってのは通用しません。

通用しないというか...そのプログラマーの責任は回避できるかもしれませんが、会員は集まりません。それはサービス全体のロスです。そのプログラマーの給料は、そのサービスで儲けたお金で払われてますから、言われた通りに作って外したら、自分の給料が下がるだけです。

C. そもそもA/Bテストする

もし、ソート順がそんなに大切なのであれば、そもそも、仮説検証の流れに沿って、「A/Bテスト」するかもしれません。

ソート順を二種類用意して、会員IDの偶数奇数で分けて、クリック率の高い方を選ぶとか...あるべき姿を探すのです。

まあ実際、ソート順でそこまでやることはないかもですが...

D. どうでもいいのかもしれない

それを考えるのに時間をかけるくらいだったら、もっと別のことやる、みたいな状況もあるかもしれません。そこのソート順を議論するだけの価値がなさそうであれば、もう適当にPKで並べておしまい(ただ、todoコメントを入れておきたいですね)。もっと時間をかけたい大事な実装があるかもしれない。

実際に運用してみて不便だって言われてから考えるとか。リリース後も気軽に直せますから、直して明日にでもリリースすればいい。

細かい話なら、そういうケースもあるかもですね。

サービスの価値を高める事業者のひとり

別にソート順でよくこういう話があるわけじゃなく、馴染みのある誰でもわかる話題として、プロトタイプになるようにと紹介させて頂きました。

実際にソート順でもありえますが、それよりも、もっともっとケースバイケースで、色々な例で似たような話がありえるわけです。この話を応用していって欲しいと思うのです。

バグ修正なんかもそうですね。そのバグを直すくらいなら別のことやった方がいい、そんなこともよくあります。費用対効果が常に耳元に…

間違っているから直すんじゃなくて、問題になっているから直す

SQLのチューニングなんかも…遅いから速くするじゃなくって、遅くて問題になってるから速くする、ですね。

まあそんな単純じゃないケースもあって、なかなか難しいことも多いですが...

とにもかくにも！

「プログラマー」というよりかは、「サービスの価値を高める事業者のひとり」であって、たまたま主にプログラミングの役割をしているだけ、って感覚なのかもしれません。

プログラムを書いたからお金がもらえるのではなく、書いたプログラムが価値を出したからお金がもらえる

jfluteも、技術的なフォローイングをするとき、単に聞かれたことの技術的な回答をするだけじゃなく、そのビジネス的な背景や問題などもヒアリングします。すると、場合によっては違う答えになることもありますし、そもそも技術的に解決する話ではなかった！なんてことも(^^。技術というより問題解決のアドバイスを心がけています。

【追記】
こういうのも書きました:
　=> サービス開発者は、それ必要？いつ必要？スキルが求められる

フリーランスやパートナーでも

フリーランスやパートナーさんの立場であっても、それはそこまで大きくは違いません。ただもちろん、パートナーさんのビジネスは、言われたものをしっかり作ることが最優先で、余計なリスクを背負わないことが基本です。

ですが、違う視点で考えると、事業会社のスタイルに慣れて有機的に行動できる人は、非常に重宝されます。もともとスキルが高くて来ているわけですから、なおさら。極端な話、そういう人の方が単価の面で良い影響があるだろうと個人的には考えています。

さすがに "A" の勝手に決めるはやはりしづらいでしょうが、"B" の提案するというのは、やりやすいことだと思いますし、非常に価値が高く重宝されることです。逆にそういう提案がWelcomeされない現場だったら、すでに事業スピードを失った現場かもしれませんので、それはそれで次のこと決める情報になっていいのかなって。