エイチームライフスタイルアドベントカレンダー2017
5日目は株式会社エイチームライフスタイルのエンジニアでマネージャーをやらせてもらっています @gonjyu121 が担当します。
はじめに
これまで、いろいろなWEBサービスの開発に携わってきました。新規サービス立ち上げ（立ち上がらなかったものも含め）には１０回以上関わってきていますので、その時々でどんなことを考えていたのかを一度振り返って、当たり前の事も含めてまとめておきたいと思います。
対象読者としては、WEBサービスのプロジェクトマネージャーの役割にある人や、技術選定の権限がある方、或いはそういった役割を目指している方となりますが、それ以外の方も、知っておくと役に立つのではと思っています。
あくまで現時点までの自分の経験を元にしていますので、皆さんのケースに当てはまらない事も多いとは思いますが、少しでも参考になる部分があれば幸いです。
ちなみに、表題にある3つの視点ですが、結論から言うと
- 事業の視点
- 技術の視点
- 組織の視点
となります。上から説明していきます！
1. 事業の視点
◯ 企画から考える
・ 企画段階からエンジニアが参加する
立場上、幸いなことに、大抵の場合は、企画段階から参加させてもらいました。市場調査、ビジネスモデル、マネタイズ、ヒアリングなど、事業を 「やる」 と決定するまでの道のりは結構ありますよね。この過程に早い段階でエンジニアが入らせてもらうというのが、まずはじめのポイントです。
僕が経験したWEBサービスの一生の中で、一番工数がかかったのは、リプレイスか、この立ち上げ時の初期開発だと思います。
どこにどの程度工数をかけるかの判断が、初期開発工数そのものだけでなく、後々の生産性にも影響する一番重要なポイントです。
そして、正しい判断をするためには情報です。企画段階から参画して可能な限りキャッチしておきましょう。
・ 事業の成功する可能性を正しく知る
企画から参加してみると、事前調査やPL作成、議論を通して、その事業にどれくらいの実現可能性があるかの温度感が見えてきます。ちなみに、自社サービスでは、失敗はあるあるです！
僕も実際に、作った後にボツになったプロジェクトを何件も経験しました。
- 半年かけて作ったものが、ローンチ後半月の初速でボツになった (´・ω・｀)
- いよいよリリース、という直前に、法務的な事前調査が不足していてボツになった Σ(ﾟДﾟ)
- 外部を取り巻く環境が急に変化してボツになった （●｀ε´●）
ボツになった時「工数かけてなくてよかった」と胸をなでおろした案件もありますし、工数が結構かかってる時はがっかりします。
その事業が「ボツ」になった時のかかった工数を 無駄工数 ・・・いえ、個人や組織の成長にはつながるので無駄ではないですね、残念工数と呼びましょうか。
自社サービスの会社は、失敗を恐れずチャレンジしないと成長はありえないので、残念工数をゼロにすることは出来ません。であれば、残念工数が発生する前提で、それをどれだけ抑えられるか、それがプロジェクトマネージャーの一つのミッションかな、と思っています。
・ 可能性を左右する「タイミング」
前述した、事業が成功するかどうかの重要な要素として、タイミングがあります。
競合に少し先に出されるだけで、雲泥の差を付けられる事もあります。
過去、ある企画者と組んでいた時に、「この機能をこの日までに作って欲しい。やってくれれば事業は跳ねる。でも、もし少しでも遅れるようなら、やらない方がまし」とまで言われたことがあります。その時事業部のエンジニアは僕1人しかいない中で「こんなボリュームのサービスを数ヶ月で作る！？」かなり無理がありました。
正直、その時の僕にはなぜ「期日」がそんなに重要なのかがよくわかっていませんでしたが「そこまで言うなら」と、まわりの事業部に助けを求めて急造チームを作り、品質度外視にはなってしまいましたが、なんとか間に合わせる事ができました。
その後、その機能を使って企画者が効果的に広告を打ち、実際に事業の売上利益が跳ねるのを目の当たりにして、驚き、それまで味わったことのない達成感を感じました。後日その人から「あの時、期日に間に合わせてくれたからだ」と感謝されました。
想定以上に事業が上手くいけば、余裕も出て、あとから保守の時間を取ることもできます。
逆に、タイミングはいつでも良い場合もあります。飽和状態の市場に明確な武器を持って参入する場合などはそういう判断が多い気がします。
前項の「実現可能性」と、本項の成功する「タイミング」によって、品質・スピード・工数をどのように考えているか、について表でまとめてみました。
|
実現可能性 高い |
実現可能性 低い |
|
|---|---|---|
|
タイミング ある（早い） |
スピード重視だが、品質も諦めない | スピードと省工数優先 |
|
タイミング 特に無い |
中長期を考慮した品質を優先 | 省工数優先 |
もちろんサービスの種類は千差万別なので、実際の場面ではこれ以外の要素も複合的に考えます。あくまで基本的な考え方として捉えて頂ければと思います。
◯ KPIから考える
・ 必要な要件だけを実装する
「やる」ことが決定し、成功するか否かの温度感を把握できた頃には、その事業の核になるKPIも明確になっていると思います。
そうなると、次のフェーズは 「KPIが想定通りなのか」 という調査です。それが正しければ次はこれ、次はこれ、とロードマップを引いて試していき、想定以下だった場合に現実的にリカバリ可能か、を判断していきます。ローンチ後のKPIが想定より悪いと早い段階で「ボツ」になる可能性があります。
KPIをはかるには 「モノ」 が無いといけないので、ここで初の開発が発生するのですが、この時に注意するのは、KPIを測るための必要最小限の機能だけにすること、逆に言うと 「KPIを正しく測るため」以外 の機能は一切付けないようにして、ボツ時の残念工数を抑えます。
・ 正確に計測できるかどうかが重要
この時大事にしている事は、単に工数をかけず、簡易的に作れば良い、というわけでなはいというところです。
簡素に作りすぎて、測りたいKPIを正しく測れないと意味がありません。
例えば、KPIを測るために「Google AdWords」への広告出稿が必要なケースなら、初期の段階でポリシーを満たして無いと出稿審査に通りません。（後で落とされることもあります）
或いはターゲットが女性のオシャレなサービスであれば、エンジニア側で機能要件だけ考え開発しても、デザインが女性にうけるものでないと、滞在率など正しく測れません。
・ 確度が高ければ保守性も考慮する
前述した成功する可能性が高い場合は、KPIも測る前からある程度想定できているはずです。初期の計測も「念のため」のニュアンスが強いかもしれません。
「ボツ」にならない可能性が高いのであれば、そのシステムが長く使われる可能性も高いということなので、初期段階で下手に工数を抑えて保守性を二の次にして作ってしまうと、後々苦労します。先手先手で進めましょう。
もし苦労する事が分かっていながら開発してしまった場合は、以後の予定で遅らせてもよさそうなアクションを議論して、被害が広がらない内に早めに作り直すべきです。（こういった二度手間にならないよう、最初の判断を間違わないのが一番ですが・・・）
後々の保守性の部分は、事業のプランナーが非エンジニアだった場合になかなか理解されにくいところなので、しっかり主張して議論しておきます。
2. 技術の視点
◯ 流行りに振り回されない
測りたいKPIと、それに対しての要件が決まりました。
次はいよいよ、その要件を満たす為にどの技術（言語やFramework、インフラ等々）を使うかを決めていきます。
僕が経験してきた歴史で言うと、昔だと、WindowsServerにIIS、SQLServer、VBscript、或いはC#やJscriptでやっていました。その後LAPP、LAMP＋独自Frameworkのシステムが増え、世間ではRuby on Rails が話題になっている頃、ひたすら技術負債の固まり（独自Framework）と格闘していました。
僕の初めてのまともなFrameworkはDjangoでした。（Python on GAE）
その後PHPであればSymfony、RubyならRailsがメインになってきて今に至ります。
インフラも、自社ビルからデータセンター、クラウドと移り変わってきました。（自社ビル時代は冷房が大変でした・・・）
というように、トレンドは数年で目まぐるしく変化します。
1年前巷で賑わっていた技術が、今ではほとんど聞かなくなってる、なんてことも日常茶飯事です。
その時の状況に流されず、惑わされず、開発スピードと、中長期を見据えて選択するよう心がけています。
◯ 技術選定における主な視点6つ
さて、では技術を選定する時に考える、具体的な視点をいくつか挙げてみましょう。
・ 公式ドキュメント/事例/書籍が豊富
書籍や公式の充実は正確な情報として大事だと思います。ググって出てこなくても、公式のリファレンスが充実していればあまり困らないと思います。
とはいえ、やはり「ググって事例が多い」と開発スピードも上がります。困っているところに対して同じような事で困っている事例があると、仮にドンピシャでなくても、それをフックに早めに解決する事も多いです。
ただ、ググった情報で気をつけないといけないのは、歴史のある技術だとversionを意識して読み分けたり、行儀の悪い書き方をそのまま使わないようにすることです。このあたりはコードレビュー等で担保していくと良いのかなと思います。
また、事例と比例して意外と重要なのは採用面です。事例の数と使用者の数はニアリーイコールなので、単純に採用の母数が増えることになり、獲得の可能性が高くなります。
・ アップデート/コミュニティが活発
不具合が発見されれば早めにアップデートされる、セキュリティーホールが出たらすぐにパッチが当たるとかは、企業で使うなら必須です。個人情報を持つサービスなどは特に。
・ 上位互換
下位と互換性を保ってアップデートしてくれているかどうか。
切り捨てたアップデートが無い（少ない）のであれば、きちんと追随でき、長持ちします。
切り捨てられると、サポートが切れても使い続けるか、リプレイスするしかなくなってしまいます。
・ 新古それぞれの良し悪しを考慮
新しい技術は、基本的に古い技術の改善したい部分を踏まえて再設計されているので、良い事が多いです。
ただし、新しすぎてドキュメントや事例も出回ってない場合は廃れるリスクもあります。
大規模プロジェクトに事例の少ない新技術を投下して2年がかりで作ったのに、原因不明の不具合が出て、長期で調査しましたが、最後まで解決できずにボツった経験もあります。
古い技術でも、コミュニティが活発でアップデートが頻繁にあるPJは常に改善していくので、資産として長く有効活用できるメリットがあります。
それぞれの傾向を踏まえ、失敗した時のリスクヘッジと天秤にかけて判断します。
・ 担当エンジニアの慣れ
効率面、品質面からいっても、担当エンジニアの経験が多い技術の方が良いです。
ただし、この理論だけでやっていくと、いつまでたっても新しい技術を使えないので、他の視点とのバランスで判断していきましょう。
・ 社内に詳しい人がいる
なんだかんだでここは一番重要な気がします。
人数よりも、詳しい人がいるかどうかがポイントです。1人であっても、気軽に聞ける環境さえあれば機能します。
まったくいないのに勢いや新しいからだけで選択してしまうと、詰まった時にわりと辛いです。
（もちろん多い方がいいですが！）
◯ 作らないという選択肢
顧客のニーズを測っている段階の時に、営業部隊から、実際にサイトを見せて説明したいという要望が来た事がありました。もし感触が悪かったらサービス自体をやめる可能性もあったので、どのような交渉をしたいのかを聞かせてもらい一緒に考た結果、今の段階では作らず、デザイナーにサイトイメージを画像で作ってもらい、それを元にプレゼン資料を作って交渉してもらう事になりました。
代替え案を考えてみると意外とアイディアが出てきます。
例えば、KPIが 「SEOで上位にくる事が必須」 ということであれば、WordPressという選択肢もあります。サイトを作って記事を書いて、しばらくして想定通りのKPI（順位）が得られれば事業継続、得られなければ中止する、といったケースですね。
アフィリエイター界隈ではSEOならWordPressという認知が一般的になってきており、あまりプログラミングスキルの無い人でも簡単に導入できるよう、進化してきています。プラグインも豊富です。
インフラもセットで安く開始できるサービスも多々あり、登録してワンクリックでサーバーが立ち上がり、すぐに使えます。
実際にこれでお願いした事がありましたが、プランナー側で特に問題なくサービスを開始できました。
ただし、注意すべき点がいくつかあります。
- もしKPIが想定通りで継続する事になった場合、必ずやってくる冗長性と負荷分散の問題を考慮しておくことです。SSHすら入れないサービスだとお手上げです。将来リプレイスしやすいところが良いです。
- 複雑な機能の開発はやりにくい上に保守性が悪いと感じます。もし初期の段階からそういった機能を入れる予定がロードマップにある場合はWordPressでない方が良いです。
- 情報セキュリティ的な視点でのアカウントやサーバーの管理を決めておくこと。立ち上げが簡単なので、プランナー側でどんどん増やしてしまい、よくわからなくなった事がありました。
丸投げにはせず、管理下においておきましょう。
3. 組織の視点
◯ 会社のフェーズ/エンジニアの組織
事業だけでなく、会社の状況やエンジニアの組織規模によっても変わってきます。
どのフェーズの時に起こすサービスなのか、によって選定基準も変わります。
・ エンジニアが1、2名（立ち上げ期）
立ち上げ期
「会社」という枠組みか、「事業部」という枠組みか、形はいろいろですが、まだまだ売上利益規模が小さく、人数も少ないベンチャーな時期、という意味合いです。
この時期のWEBサービス立ち上げは、イコール起業時のWEBサービスです。ほぼ選択肢が無いと思います。エンジニアは1人、ないし2人いればいい方で、人数が少ないので、学習コストが限りなく低いものを選ばざるを得ません。余裕も無いので保守とか考えてる暇も無い感じです。
逆に、エンジニアが自分しかいない分好き勝手にやれてしまう側面もあります。この時、事業側に立たずに「やりたい」だけで慣れてないものを選定してしまうと、必ず想定外の事が起こり、予期せぬ差し込みが増え、あっという間にスケジュールをハンドリングできなくなってしまいます。なんせ自分しかいないので・・・
また、遅れる事で事業が成功する可能性がどんどん低くなるので、徹夜して体を壊すとか、結局遅れてしまうとか、いろいろ悲しい事になります。
・ エンジニアが１０名前後になった頃
そのくらいの時の会社は、1サービス目が軌道に乗りはじめた頃ですが、まだまだ余裕がありません。そんなギリギリの時に新規で立ち上げる話になる時は、事業モデルが1サービス目と似ていて且つ成功する可能性が高い事が多いです。ですので、システム的には今あるシステムの横展開を中心に省工数で考えます。
もちろん、新しい技術で挑戦するという判断も出来ますが、よほどの事がない限りは危険かなと思います。なぜなら、
- 開発チームがその技術で1セット必要になり、横展と比べて人件費が増えること。
- 言語や技術のスイッチングコストは思った以上にコストがかかるので、人が動かしづらくなり、事業の動きに合わせて柔軟に対応する事が難しくなること。
などが挙げられます。この時期の会社は、選択と集中をして効率重視でやっている事が多いので、ちょっとでも効率が悪くなると、結果的にうまくいってるメインサービスにも影響が出てしまい、メインサービスの成長が滞ると、投資を継続できなくなり結果的に「ボツ」になったり、営利が減れば人件費も削減して・・・という悪循環がおきます。新技術をやりたい気持ちはグッと堪えて、事業が安定する事を第一に考えます。
反面、うまくいった時はダイレクトに数字が見えやすいというメリットがあります。エンジニアでありながら事業への貢献を強く実感できます。そういった充実感もなかなか体験できる事ではないので、この時期はそちらを大事にする、という考え方もありですね。
うまく事業がのってきたら、少しずつ、ツール系は新しい技術を使ってみたり、くらいの余裕は出てきます。
・ エンジニアが２０名を超えてくる頃
会社的にも若干余裕も出始めて、且つ経験の豊富なメンバーも入ってきて、技術的にも組織的にも選択肢が増えてきます。一方で、立ち上げ当初のシステムの技術負債や、サポート切れ、時代遅れ感も目立ってくる頃です。
今後の事も考えると、どこかで新しい技術にチャレンジする必要が出て来るのですが、そういった議論の最中にあがった新規サービスであれば、学習コストも含めて工数がかかったとしても、チャレンジに当てます。
また、そういったチャレンジを進めると、最新の技術にチャレンジ出来るIT企業、ということで、更に専門性が高い人が入ってきてくれる傾向にあるように思います。そうすると、良い循環が生まれます。
◯ エンジニアの成長を考えて選定する
その時立ち上げるWEBサービスが成功しないと会社が存続しない、という極端な場合を除いて、基本的には失敗後も会社自体は継続します。
自社サービスをやっている会社であれば、基本的に失敗はつきものとして、その失敗を糧に次、また次と挑戦していきながら会社を成長させていくので、今回立ち上げに参加したエンジニアもまた、次があるわけです。次の成功率を高めていくために、エンジニアの成長もまた経営にとって重要な要素です。
サービス立ち上げは、非常に良い成長の機会です。しかもそんなに頻繁に発生するわけではないので、この希少な機会をしっかり成長につなげることが出来れば、人が育って事業が育ち、会社が育つ好循環になります。
・ 小規模事業、スモールスタート事業
小規模であれば若手に思い切って任せるチャンス！
事業責任者1名、エンジニア1名の最小構成で開始した事業がありましたが、この時は経験浅めの若手エンジニアにお願いしました。若手エンジニア自ら技術選定をしたり、実際に自分で選定したものでインフラもアプリケーションも全て開発していくことで、成長に繋がったのではと思います。これはスモールスタートだからこそ（失敗時の経営インパクトが少ないからこそ）、思い切ったアサインができます。
・ 規模が大きく、確度も高い事業
大規模事業はリーダー経験のチャンス！
確度が高い事業は、最初からエンジニアも数名アサインされます。チームを運営していく事や、保守面含め考慮すべき要素も増えるため、より高度なスキルセットが求められます。
◯ エンジニアのワクワクと、事業の成長を重ねる
学習コストだけドライに考えると、統一されていた方が効率が良いのですが、いくつかの組織を見てきた中での感触としては、選定ルールがガチガチに固い組織より、比較的自由な組織の方が、エンジニアが元気で活発な印象がありますし、結果的に生産性が高いように感じます。
やっぱりエンジニアは作るのが大好きな人種です。新しい技術に触れる事ができてワクワクしたり、設計の議論をしてワクワクしたり、作ったモノでみんなが喜んで嬉しくなったりします。ワクワクがあれば楽しいし、楽しいと生産性も上がります。これは本当に大事にしたいところなので、新しい事にチャレンジ出来る機会が出てきたら、トップが決めるのではなく、みんながやりたい技術を選定をするのがベストです。
ただし、そのワクワクが、うまく事業成長につながるのか、も一緒に考えないといけません。ワクワクして楽しい、けど事業が成長しない、となると、新しい事に投資する余裕がなくなって、給料が下がって、ワクワクできず、楽しくならず、生産性が上がらず、更に事業が成長しない・・・負のスパイラルです。
自分たちがワクワクして楽しく仕事をするためにも、単に「僕、私がやりたいから」で選定するのではなく、エンジニアもみんなと一緒になって経営や事業を考えていく事が大事です。
最後に
いろいろと書いてきましたが、自分自身、常にこれらの視点を完璧に持ってやってきた、というわけではなく、「あの時はこう判断したな」というのを一つずつ書いていったらこうなりました。
一つの視点しか持っておらず、凝り固まった判断になった事もあれば、複数知ってたとしても「あちらを立てればこちらが立たず」的な部分で結局迷う事が多かったりもします。
「あの時こういう視点を持っていれば、もう少し最適な判断ができたんじゃないかな」と改めて気付く事もあり、自分にとっても学びの多いまとめとなりました。
みなさんが全く同じ経験をたどることはないと思いますが、もし似たような場面に遭遇したら、参考にしてもらえると嬉しいです。
僕自身も、今後またいろいろなフェーズを経験していくと思いますが、その都度アップデートして、よりみんなで楽しく気持ちよく充実した仕事ができるように考えていきたいと思います。
以上です。
エイチームライフスタイルアドベントカレンダー2017、明日は期待の若手エンジニア @mziyut さんが「Weexでモバイルアプリを作ってみた」を書いてくれるらしいので、お楽しみに。
株式会社エイチームライフスタイルでは、一緒に働けるチャレンジ精神旺盛な仲間を募集しています。興味を持たれた方はぜひエイチームグループ採用サイトを御覧ください。
http://www.a-tm.co.jp/recruit/
※ 他にもこんな記事書いてます