「ismで実現できてることをもっと社会に広めたらよくない？ism村構想！」

そんな社長の一言からスタートした、コミュニティコワーキング『ism campus』事業。

全社的に見ても、自社事業としての大プロジェクトであり、サービス開発という側面でも１つの節目になるリリースでした。

この事業の構想は本当に何度も何度も試行錯誤を重ね、形を変えながら、この「コミュニティコワーキング」に落ち着きました。

初めて役員4人(代表鈴木、COO山本、CFO平出、そして私)で経営戦略合宿をしたのが7月の初め。

この頃から、私たちの目指す先は変わっていないものの、「その手段として何をするか？」はあらゆる変遷を遂げています。

そんな背景があり(きっと、この事業立ち上げの経緯は鈴木がnoteにでも書いてくれると期待して割愛しますが)、今こうしてism campusとして皆様にお披露目するカタチとなりました。

※様々なメディアに取り上げていただいたので最後にいくつか抜粋してご紹介します。

なお、このブログは TECH PLAY女子部 AdventCalendar 2018 の12/24投稿として登録します！

Contents

メンバー専用の会員システム
既存事業との並行と各自の自走
- 私が最初にしなければならなかったこと
工数ばかりが膨らんでいく開発フェーズ
リリース前夜、ぎりっぎりの戦い
- ちなみに今回1番つらかった部分
今後の開発スケジュール
おまけの話
さいごに
- リリースについて

メンバー専用の会員システム

今回は、ism campusリリースにあたって新規開発した、会員システムにフォーカスして振り返ります。

✅ism campusのメンバーである世界観を表現したい
✅マーケティング視点で情報の受発信の場が必要
✅この後に控えている新規サービスの前段としてコミュニティ化したい

これらが主な理由で、ism campus会員システムを構築する話が浮上してきました。

この話、実は7月の合宿でも話は出ていたものの、いったん立ち消えになっていたタスク。
そんなタスクが「事業リリース日が確定した後」にまさかのプロジェクト再復活。
色々な経緯があり、システム要件0の状態から開発をスタートすることになりました。

この時点でリリース日(12/10)まで残り3週間です。

既存事業との並行と各自の自走

この日から怒涛の要件整理が始まったわけですが、なんせ皆もちろん既存事業は通常通り進めている中でのこの新規サービスです。

MTGしようにも全員のスケジュールが合わず中々ゆっくり話せない、事業自体も走りながら練っている状況で日々ゴールの要件は変わっていく。

要件が決まらないからと開発を待っている状況ではないし、リリース日は刻一刻と迫っていました。

ここからは、離れていても各自が自走していかなければなりません。

私が最初にしなければならなかったこと

1. 提供すべき最低限の機能確認
2. それを実現可能とする技術選定
3. 要件・DB定義、ユースケース洗い出し
4. 非エンジニアがイメージをすり合わせられる場づくり

1. 提供すべき最低限の機能確認

まずは自分の頭を整理するためにも、「ism campusに何が必要なのか？」を書き出していきました。

✅事業の方向性にあっていること
✅ユーザーが使ってワクワクすること
✅スタッフの運用がラクになること
✅後にコミュニティ化できる仕組みであること

この4点に重点を置いて、無駄を削ぎ落としかつ次フェーズで柔軟に方向転換できるよう、シンプルver.機能を整理します。

ちなみに、こういう作業の時は紙に書くほうが名案が出ることが多いので、PCで市場調査しつつスケッチブックにメモを殴り書きしています。

2. それを実現可能とする技術選定

最低限の必要機能が出てきたら、それを実現するための技術を選定する必要があります。

✅既存のsaasサービスで世界観そのままに叶えられる部分はないか
✅現時点で手運用に切り出せるものはないか

工数やコストと天秤にかけて改めてシステムにすべきかどうかを切り分け、その後、今回の方針を以下に決めました。

『調査工数を削減し、スピードを落とさずに開発できること』

(要するに、リリース優先駆動開発！ww)

今回は資金面でも期間的にも、エンジニアを外注している余裕はなく、私が全て開発する必要があったので、調査工数がかかる新しい技術は採用しないと割り切りました。

また決済周りに関しては、日本語ドキュメントや開発事例、ユーザーコミュニティが充実しているAPIを利用することを重視します。（結果、12/10のリリースでは決済は入れてないのですが）

【使用した技術】

✅開発言語：Ruby on Rails
正直、業務での経験は一度もないのですが（笑）業務経験の長いJavaのSpringフレームワークとMVC構成が似ていることや、日本人のTipsがインターネット上にたくさんあることで、ググった時の安心感もあり採用しました。

✅開発環境：Docker
こちらも時流に合わせて事例が増えていることと、環境を作ったり壊したり、共有したりするのがラクだったためです。

✅本番サーバー：AWS
これまでにも開発で使っていて慣れてること、ランディングページ側はS3で運用しているので一元管理したかったことが主な理由です。

✅決済用API：Stripe
色々な比較記事を確認した結果、コストが低くほぼ審査待ち期間なしで本番利用開始できること、前述の通りドキュメントが多くユーザーコミュニティが充実していることで安心して選定しました。

3. 要件・DB定義、ユースケース洗い出し

ここからいよいよ、上流工程エンジニアの腕の見せどころ。（ていうか上流も下流も私がやるんだけどねw）

当然ながら、要件とそれに見合うDBがなければ開発も始められないので、粛々と要件定義、DB設計をしていきます。
DBは作っては壊し、を繰り返して開発中もなお、「うわ、ここにきてデータ構造これじゃあかんことが判明…」みたいな辛い発覚が何度か訪れましたが（笑）、適宜直すなり後回しにするなりで対処。
(代表の鈴木がDB定義に関してはよく知ってる人なのでとても頼りになりました。)

DB設計もユースケースも、一人で考えていると思わぬ考慮漏れがあるので時間さえ合えばなるべくみんなに共有することを意識しています。

とはいえ、がっつりシステム開発経験のあるメンバーはいないので、用語の定義からハチャメチャで若干苦労。

例えば、利用者のことを「ユーザー」と定義するのか「会員」と定義するのか、そういう細かいことでもお互いの認識がどんどん乖離していくもの。

本来であれば、共通用語を先に決めてお互いに認識齟齬が発生しないようにするフェーズ（からのドメイン駆動開発！）が欲しかったところですが、今回ばかりはそうもいかないので、各々が空気読んで進めている感じでした。
（これってもしかすると女性同士だからできたのでは？と思ってたりします。女性特有の空気でなんとなく伝わるアレ・・・あるよね？w）

4. 非エンジニアがイメージをすり合わせられる場づくり

そして、役員の中で私以外に技術がわかるメンバーはいないので、イメージをどうすり合わせるかは気を遣うようにしました。
（とはいえ、ここは今回あまりテコ入れしてる時間はなかったので最低限ですが・・・。）

【意識していたこと】

✅専門用語はなるべく使わない
注意はしているけど、どの言葉が通じてどれならわかるのか、反応を探りながら見極めていきました。
最近は少し余裕ができて来たので、どうやってわかりやすく言い換えられるか改めてメモを貯めていますw

✅面倒だけどドキュメント化して共有する
ER図とか画面遷移とか、本当は便利なエンジニア向けツールが色々あるけど、使い方を説明している時間はないので、とにかくレガシーな方法でGoogleスライドとか使いつつ見せていました。
元SIerだから無駄にレガシーなことさせられるのは慣れっこです。笑

✅biz側に不要な情報はあえて見せない
ログ設計とか例外処理とか、保守系作業とか、Trelloの細かいタスクとかは共有せず、事業と直接結びつく機能に関することだけを役員には展開していました。
本当はもっと裏で工数かかってんだよー！！ってことも追い追いみんなわかるようにしたいなとは思ってますがw

こんな感じで、私個人としては1〜3を裏で進めつつ、他役員への展開は基本4を軸にし、課題が発生すると時々一緒に考えてもらう、というように進めていきました。

工数ばかりが膨らんでいく開発フェーズ

時間がないので、いつまでも要件整理しているわけにもいかず、ある程度の枠が決まってきたらどんどんプロトタイプを作ることにしました。

実際に動くものを見ながら話したほうが新しいインスピレーションも湧くし、検討漏れが浮かび上がったりするからです。

これを巷ではアジャイルと呼ぶのでしょうが、私はただ時間がなくてこうしていただけなので正式にアジャイルだ！！と思ってやっていたわけではありません笑

また、今回どんな工数ピンチに陥ってもエンジニアを追加できなかったもう１つの理由が、とにかく時間がないから、設計という概念が存在しないこと。

私が頭の中で設計しながらそのまま手を動かし、デザインも私の頭の中にしかない状況で、他のエンジニアが入ってしまうとかえって情報共有コストがかかると感じました。

増え続けるTODOコメント、まともに吐かれていないログ、例外発生時の不穏な挙動、追いつかないテストコード、、、機能の実装とは別の保守課題が山積みでした。

進め方としては以下の通り。

1. bootstrapテンプレで最低限の整形だけ保ったViewを用意
2. DB定義通りにmodel生成
3. 正常系で遷移するよう実装
4. この辺りで役員に共有、Biz視点でのフィードバック反映
5. 異常系の実装
6. テスト（条件網羅、データ網羅あたりを手動で）
7. 1〜6で全体機能ができてから、最後2日間くらいでPC、SPのCSS調整

ちなみに、今回デザイナーもいないのでデザインは私というド素人の独断と偏見で超適当につけてます。笑
でも皆カワイイって言って使ってくれてなんか申し訳なさと嬉しみが混ざって恥ずかしい・・・

リリース前夜、ぎりっぎりの戦い

そんな中、もう半年も前から決まっていたタイ旅行があったので、リリース前日まで私は海外へ。（呑気か）
もちろん旅先でもひたすら開発を進めていたのですが、ネットワークは不安定なのでリリース作業までは手つかず。

前日の朝に帰国してからリリース用の写真撮影などがあり、その後そのままインフラのお手伝いを依頼したエンジニアと合流して最終チェックとリリース実行です！

（と、この会員システムだけならまだよかったのですが、外注で依頼していたサービスサイトのほうにも不備が発覚し、私はもうこれ以上本当にリソースないし、なんか大変なことになってたのですが、これはまた別の時に・・・ww）

リリース前日になっても完成していない環境設定ファイル、本番RDSの接続不良、焦っても進まない不具合調査・・・。
もう本当に無理かと思いましたが、たくさんの方の助けがあって、なんとか終電間際にリリース完了！
（暫定箇所もあったりしたけど、決してユーザーに悪いことが起こってしまうようなセキュリティ不備は残してないです！）

私は残作業があったので結局帰宅が朝方になりましたが、リリースが間に合った安心感と、翌日アクセスされてシステムが落ちやしないかという不安で押しつぶされそうになり、眠れなかったのを覚えています。

ちなみに今回1番つらかった部分

インフラ、ネットワーク周辺の知識がちんぷんかんぷんだったこと、今まできちんと触れてこなかったことを史上最強に後悔しました。

エンジニア一年目の頃から、ロジックを組むことや設計すること、とにかく動くものにしていく開発力には長けていたほうでしたが、大規模プロジェクトばかりだったため「インフラ構成は完全に専門部署にお任せ」というような状況でしか開発したことがありませんでした。

もちろんその後、自社サービスの担当もしていたのである程度の構成検討はできるのですが、なんせその程度の知識では、トラブルシューティングができない。

今回は仲の良いインフラエンジニアがお手伝いしてくれたので良かったですが、今後の運用で障害発生時に私が対処できないのはリスクが高いです。

ここは未だ課題なので、誰か常に対応できる人材を置くなり私が猛勉強するなりの対策が必要そう。（誰か助けて！！！）

今後の開発スケジュール

今のところ無事に安定稼働しているので、今後も事業の改善と合わせて機能拡張や方向転換を図っていく予定です。

まずは、1月から検討中の本格運用に向けて決済周辺の機能を追加、来月以降でユーザビリティを改善するような細かい改善をしつつ、会員限定の利用機能を増やしていきます。

■ 12月：決済周り機能追加(年末年始に疎通テストかな？)
■ 1月：プロフィール充実の他、まだ言えませんが今よりもっとお得になる新機能も！
■ 2月：各種SNS連携、会員限定サービスの予約機能

また、春先には次のフェーズを見据えて裏で色々と進めてまいります！

おまけの話

私は前職で直近の1年半マーケティング部門の管理職をしていたので、（自社サービスをオフショアメンバーでまわしたり、キャンペーン用のLPを作ったりはしていましたが）自分が手を動かすようなシステム開発からは完全に離れていました。

なので、このブランクをどう埋めようかという焦りが心の何処かにずっとあったのですが、今回久しぶりに開発してみて、「全然イケるやん楽しいし最高！」と思えたので、技術にブランクなんて関係ないんだと思いました。

もちろん常に触ってきた人とは見てる視点が違うし、移りゆく技術やバージョンの変遷も追えていない自覚はあるけど、「プログラミング」だけを見れば自転車と同じように？基礎がわかっていればまたすぐに乗り回せるようになるんじゃないかと思います。

エンジニアがなんたるか、って話がTwitterではよく盛り上がっていますが、ITにおけるエンジニアでいえば、私は「ITの視点で総合的に社会課題を解決する」のがエンジニアだと思っています。
それがプログラミングする側面もあれば、サーバーを選定したり既存サービスの採用判断をしたり、カスタマーサポートとして不具合解決したり、いろんな色で見えているだけなのかな、と。

エンジニアの本当の大変さって、技術仕様を覚えることでもロジックを組み立てることでもなくて、幅広いユースケースを考慮して設計したり、漏れがないか精査したりする時間の多さだと思う。そしてそれはユーザー側には見えない部分だったりするので、あまり報われないというか…🤔

— まいどる🌵ismの役員エンジニア (@maidol_28) November 27, 2018

さいごに

今回のサービス開発にあたって、たくさんの方たちのアドバイスやお手伝いに助けられました。

感謝してもしきれませんが、この場を借りてお礼申し上げます。

■ ism全役員、社員、お世話になっているフリーランスの皆様
■ いつも、いざという時に助けてくれるチームゆるふわ（みふるん、はぐ、あっきー）
■ インフラ相談にのってくれたTech Funの源次郎、おいちゃん、AWSのよだれいぬさん
■ 技術アドバイスをくれたCA杉山さん
■ 突然コードレビューを申し出てくれた、平成元年の会はるきさん
■ サービスサイト制作を進めてくれたパートナーの稲田さん、デザイナー様
■ 直接開発とは関わらずとも、話を聞いてくれた友達の皆さん！

こうして無事にism campusをリリースし、この2週間で多くの方にご利用いただきました。
少しずつではありますが、運用もシステムも改善アップデートを進めています。

じわじわ増えていく会員登録を見るたび、胸がジーンとするし心が踊るし、「もっと頑張るぞ！」と思います。

今回の弾丸リリースは、私自身にサービス開発の苦労や楽しさを思い出させてくれる開発でもありました。

だから本当に、みんなみんなありがとう！
ism campusに限らず、これからもIT技術を使ってたくさんの人の役に立てるエンジニアでいたいです。