転職ブログは最終出社だった1月に公開していたのですが、有給消化などがあり、実際にアルプに入社したのは2019/02/19でした。つまり今日でちょうど半年になりました。アルプに転職意思を伝えたのは一番早かったのですが、採用が順調なアルプには他の社員がすぐに集まり、入社日は一番ではないという話は今後何度もすることになりそうです。社内では論理1号社員とか社会的1号社員と言われています笑 社員証みたいなものはまだないので、今から楽しみです。
冗談はさておき、入社半年という節目にめでたくサービスをクローズドβ版としてリリースできました。🎉🎉🎉🎉🎉プロダクトのページや正式なリリース・アナウンスは9月以後を予定しています。
直近はリリース前の追い込みでしたが、これから徐々にプロダクトを知ってもらえるようなコンテンツも増やしていくと思います。
週刊東洋経済「すごいベンチャー100」にアルプも選んでいただきました。本当に載っているだけですが笑、ありがたい！ちょうど今週でアルプは1年、プロダクトもいよいよ提供していきます。もっと頑張っていき💪
— 伊藤浩樹（H.Ito）/ Alp, Inc. (@itokin) 2019年8月19日
大化けに期待！47社厳選リスト | 有望ベンチャー https://t.co/DmGIBWAQDm #週刊東洋経済
実はプロダクトを公開するのはこれが初めてです。名前は Scalebase といい、サブスクリプションビジネスの収益最大化・管理プラットフォームになります。 サブスクリプションビジネスのプロダクトやプランの管理を柔軟かつ簡単に設計できることで収益の早期拡大を実現 したり、それを支えるオペレーション、いわゆる「バックオフィス業務」みたいなものを一気に受け持ち効率化するプロダクトです。
商品管理、顧客管理、契約管理、請求管理など複雑なドメインと言ってきたのが伝わるでしょうか。あ〜、めちゃくちゃ大変そうだな…とわかったかたは、絶対ワクワクしてもらえるプロダクトなので、自社導入でも一緒に作りたいでもいいので連絡お待ちしております。
リリースまでの話も含めて、入社してから半年の 激 活動を振り返りたいと思います。
toCサービスの開発からtoBサービスへ
前職ではtoCサービスの開発しか経験したことがなかったのですが、その難しさを一言でいうと「出してみないとわからないことが多い」でした。いくらユーザーを分析してもニーズや流行りは変わるので、全く新しいものを作っても使われなくなったり、習慣になるようなものを作るのが本当に難しいなと感じてきました。
それが嫌だったわけではないですが、新しいアイデアやサービスをもっとよくしようというときに「とりあえずこれでやってみよう」という結論になってしまいがちで、これで本当にいいんだろうかという不安がいつもまとわりついていました。でも基本的にそれが普通の世界です。仮説、実装、検証、改善を高速に回すのが当たり前でした。
toBになると問いがすべて明快というわけではないですが、少なくとも目の前にいる使ってくれる人を幸せにするにはどうするべきか？という発想の仕方が好きです。これで誰かの問題を解決できるかもしれない！という期待が開発のモチベーションを膨らませてくれると今は感じています。もちろん実装、検証、改善は変わらず高速に回す必要があります。
より多くの人に使ってもらいたいという気持ちは変わりませんが、まずは小さく始めるというスタンスがエンジニアとしての自分の行動規範にマッチする感じがするのだと思います。そこから問題を一般化、抽象化してより良いものにしていくのが僕は好きです。
目の前で困っている人も自分たちの問題をきちんと理解していないことは多く、本来解決しなければいけないことは何なのか？を見極める難しさ(イシューから始めたい)もありますが、違った楽しさを感じています。
開発
これまではモバイルアプリ開発をしてきた自分が突然バックエンドの開発へいくことへの不安はありました。慣れてない言語を使いつつ、スピードが大事なこの時期に自分の価値が出せるのか？と思っていました。結果としてはめちゃくちゃ上手くいったとは言い難いですが、半年後にリリースできるくらいには貢献できたと思っています。
前職でも退職直前まで忙しかった記憶がありますが、アルプでのリリース直前に比べたらまだまだだったように思います。笑 GitHubの草だけを見れば休日も仕事をしているように見えますが、デスマーチをするような感じではなかったので、疲弊したりはしていません。
PRで開発スピードは測れませんが、230くらいでした。書き慣れてないのもあってかまだまだScalaを理解しきれてるとは言えないので、引き続き書いていきたいと思います。リリースまでの流れは
- 必要な機能のためのモデリング(1~2月)
- 実装してみないとわからない部分を作り始める(3~4月)
- スケジュール確認と調整
- ドメイン理解が深まった状態で再設計、実装(5月~)
- e2eテスト(8月~)
おおまかにこんな感じで進んだと思います。この過程で開発に関する多くのことを学びました。
- DDDを実践するためのモデリング手法やアジャイル開発の一部メソッド
- ユースケースシナリオ作成
- ユーザーストーリーマッピング
- CRC(Class-Responsibility-Collaborator)
- プランニングポーカーとファンクションポイント
- Scala
- 言語仕様や関数型への理解
- Effを用いたアプリケーション開発
- バックエンド開発
- マイクロサービスを意識しているが、スピード優先したモノリス
- SQLのクエリ最適化
- e2eテスト手法、品質管理など
- インフラ周りの基本的な知識
- 見積もりとリスク管理
などなど。細かいこともたくさんあるんですが、バックエンドを作って、初めてシステム全体が動いている実感を得てきました。また、複雑なドメインの扱い方、システムへどのように落とし込むべきかというものが経験できました。今後も絶対に活きる貴重な経験でしたし、これからも練度を上げていきたいと思います。
バックエンド開発
とにかくモデルを正しく作ることの大切さを感じました。そしてそれを実践するにはDDDが不可欠だとも思いました。クライアントアプリにはない、システムとしての「正確さ」がハイレベルで求められ、それにはやはり多くのソフトウェア開発手法が役立つということもわかりました。Scalsebaseは DDD + Clean Architecture + Effが設計への影響が大きいです。最初から徹底できていたことで良かったことが色々あります。
- クライアントとのモデル共有はprotocol buffer、通信はhttp
- テストがないと実装完了とならない
- 難しいモデリングや実装はCRCで認識合わせ、モブプロで素早い共有
- ユースケース、モデルの実装＞repositoryの実装＞Controllerとエンドポイントの実装という順でインターフェースを生かした開発
- 外部サービス連携などでドメインを汚染しないような工夫
どれも当たり前という人が多いかもしれませんが、当たり前の認識を合わせること、それを高く保つことは最初から徹底しておかないとすぐに腐敗していくと思います。視座が高い集団は当たり前のレベルが高いと思うので、徹底していきたいです。
ふとリリースの数日前にこんな一言がSlackに飛びました。
半年以上かけて悩みまくって作った割に、普通に触ってる限りは単純なアプリケーションに見える。
リリース直前にe2eテストも兼ねてwebをローカルでビルドし、ローカルサーバーを立てて触っていたら僕も同じことを感じました。つまり、これまで散々苦しんだモデリングや設計によって、アプリケーションをシンプルにできていたのです。僕はこのときやってきてよかった、間違ってなかったのだと思いました。ドメインモデル貧血症になっていることもなく活き活きとモデルが活躍しています。これからも気を抜かずに良いモデリングをしていきたいです。
見積もりとスケジュールとリスク管理
リリースまでの繁忙期は組織が進化する過渡期でもあると思います。この時期をチームでどう切り抜けるかによって、その後の開発の進め方、チームの見積もりやスケジュールへの考え方などが変わってくると思います。これまでの実体験でもスケジュール管理がうまくいかないのは何度も見てきたので、今回も理想がそのまま思い通りにいくことはないだろうと考えていました。ですが、結果としてはいくつか問題はあったものの、失敗というような大きなミスや大幅なリスケはなかったと思います。そのために数週間寝ずに働いたということもなかったので、反省を活かしつつこれからどんどん改善していけそうです。
個人的に見積もりとスケジューリングで重要だと思ったのは、
- 殆どの問題はコミュニケーションである と共有したこと
- リリーススケジュール確認時に リスク管理 について共有したこと
- 不安要素を潰すために各個人が「必要なものはなにか？」と考え行動できたこと
だと思います。
リリースの二ヶ月ほど前に週次の振り返りのタイミングで代表が「ほぼすべての問題はコミュニケーション不足で起こる、それを意識していこう」と伝えたことで、全員がコミュニケーションを取らないことのヤバさを認識できました。これによってオーバーコミュニケーションが生み出され、足りないものを補っていける環境へと進化しました。
また、リリース前にリリースの定義とスケジューリングしている中で、リスク図とその管理について、過去の自分達の開発効率から確率的なリリースの遅れる可能性について認識を合わせました。これにより無理なスケジューリングをしたり、共有不足や確認漏れを防ぐタスクの洗い出し、現実的なリリースの認識合わせができました。
や
- 作者: トム・デマルコ,ティモシー・リスター,伊豆原弓
- 出版社/メーカー: 日経BP
- 発売日: 2003/12/23
- メディア: 単行本
- 購入: 7人 クリック: 110回
- この商品を含むブログ (149件) を見る
といった書籍が参考になります。概念的な説明が多いかもしれないですが、そもそも遅れる可能性があるものだという前提で進めるのとそうでないのでは精神的な負担がぜんぜん違うので、パフォーマンスにも影響します。これを肌身で実感しました。この認識合わせとそのための開発効率の数値化をしていないチームは是非やってみるべきだと思います。
会社を知ってもらうことの大切さ
前回のブログではリリースをほったらかしてイベントに参加している様子をご紹介しましたが、たくさんのかたにお手伝いいただいたり、話をききたいという連絡もいただけました。が、まだまだ人が増えてほしいし、そのための活動を怠ると一瞬で忘れ去られるという不安から今後も多くの場に参加して存在感を出していきたいです。ScalaMatsuriではある程度知ってもらえたり、会社に興味を持ってもらったりしたので、SaaSを作っている会社、Scalaに力を入れている会社の皆さんはいろんなコラボができるといいなと思っています。
火曜日のランチでは、外部の方に参加してもらいつつ、会社やメンバーの話をしたりできる仕組みがあるので、参加してみたいという人はTwitterにDMでもください。
今までは知られているだろうという前提の組織だったので意識したことがなかったのですが、対外向けに活動することの大切さを改めて認識しました。大きな会社では個人としてのプレゼンス、創業期では会社としてのプレゼンスを目的としているという違いがあるのです。
今月末に迫った builderscon tokyo 2019では、弊社の @pictinyが発表するので参加する皆様は是非足を運んでいただけると嬉しいです！
これからのアルプ
クローズドβ版のリリースというマイルストーンを通過した僕らは、次なる目的地を見据えて明日から進めることになります。いくつか観点があるので言語化しておきます。
カスタマーサクセスに本腰を入れる
日経新聞でも取り上げているので、個人的にもSaaSは 盛り上がってきている といってもいいと思っています。
そして多くのSaaS企業では急成長のためには カスタマーサクセス が必須だという話もよく聞きます。β版とはいえ、リリースしたからには運用が始まり、より綿密な顧客との対話が必要になります。カスタマーサクセスについて誰かが専任で行動しているわけではない今（10月から専任が入ります！）、環境整備と言語化をしていかないといけないです。
- ミッションの言語化
- ドメインと市場の理解を深めるための環境整備
- プロダクトのヘルススコア(クオリティ)とタッチスコア(使いやすさ)分析
- カスタマーサクセスの仕組み化、再現性を上げるためのフレームワーク化
- プロダクトチームと連携しやすい組織を作る
ということを考えています。それぞれに知見のあるかたはランチにお話しにきてもらいたいので何卒。チームの解像度を上げていくことが重要だと考えています。
開発チーム
リリース直前ではスケジュール再調整、開発の殆どがリファクタリングになったことによるファンクションポイントの乱れなどが影響して、マイルストーンがなあなあになってしまいました。今後は見積もり精度を上げるためにも再開し、高速にイテレーションを回していけるように立て直す必要がありそうです。
今は全員背中を預けるスタイルの開発チームですが、これから人が増えたときのチームデザインや組織づくりへの解像度が高くないので、実験、改善していく流れを作る必要があります。
他にも技術的な話で言えば、
- 一部ドメインのマイクロサービス化
- CQRS対応
- 決済サービスへの対応
- 請求・会計関連サービスの対応強化
- CRMサービスへの対応
などなどてんこ盛りです。着実に作っていきます。
目指すべき世界の言語化
会社のミッションやバリューを言語化するというのはめちゃくちゃ難しくて、 10Xなプロダクトを創るのような解像度の高さには尊敬してしまいます。僕らはまだ顧客の問題、その後ろに隠れた市場の問題を解決できるか試している段階なので、明確に言語化はできていないです。でも、ある程度見えているとも感じていて、あとはどのように言語化するということだと思います。Scalebaseという名前に至るまでのコンセプトデザインにもヒントがありそうです。
以上でした。これからもガンガン開発していきますので。応援よろしくおねがいします！
アルプタグで開発日誌公開中
粒度は荒いですが、開発目線でのこれまでどのように歩んできたかということはアルプタグで公開している記事にまとめています。
本番リリースも無事にでき、これから加速していくアルプを一緒にやっていきたいというメンバーを募集しています。興味のある方はぜひご連絡ください。
