クラウドサービスのつくり方

メール配信サービス『 https://ecumerun.com 』をつくる過程で学んだこと。
クラウドサービス(SaaS)事業を立ち上げるときにきっと役立つと思います。

-- 開発編: https://ecumerun.gitbooks.io/how-to-make-a-cloud-service/

Transcript

1. クラウドサービスのつくり方 〜 ecumerun.com をつくる過程で学んだこと 〜
2. 目次 • 調査 • 企画 • 設計 • 実装 • テスト • 販売開始 • プロジェクトクロージング
3. 調査 • 「3CPT」を調べる • ベンチマーク先を調べる
4. 3 「3CPT」を調べる • 「3CPT」を調べ、次工程であるサービス企画へのインプットとする • Customer、Competitor、Company、Partner、Technologyのこと • この5つを押さえれば概ねOK • Customer • ターゲットは誰か？ • その人たちは何をやっているのか？ それはなぜか？ ※jobs-to-be-doneを知る。自分でやってみたり、誰かがやってるのを観察したり。 • 何をやりたいのか？ それはなぜか？ • 何をやりたくないのか？ それはなぜか？ • Competitor • 一次情報: そのサービスを使ってみる。画面キャプチャを撮ったり、価格体系を調べたり、いいところやダメなところをメモしたり。 • 二次情報: 以下のようなサイト/レポートから情報を集める • サイト: Datanyze、G2 Crowd、TrustRadius、Product Hunt(新規参入/代替品の脅威のチェック)など • レポート: ガートナー(マジック・クアドラント)、フォレスター・リサーチ、IDC Japan、情報通信白書、その他調査報告書など • Company • 強みは何か？ ※切り口 = RPV (リソース、プロセス、価値基準) • Partner • 開発パートナー: • 社内にこだわらず、最適な人を探す • 『仕事は忙しい人に頼め』。腕の立つデザイナーやデベロッパーには早めに連絡して予定を空けておいていただく。 • 販売パートナー: 拡販のために組めそうな会社に目星をつけておく • Technology • インフラ、アプリ、フロントエンドの各分野で技術要素の選択肢をおおまかに調べておく 調査 > 企画 > 設計 > 実装 > テスト > 販売開始 > プロジェクトクロージング
5. 4 ベンチマーク先を調べる • ゼロからはじめない。これを意識するのとしないのとで生産性がだいぶ違ってくる。 • 他社のやり方で、いいものは自社にも取り入れる。MVP(実用最小限の製品)を早くつくるなら特に。 • 国内だけでなく、海外のサービス(※以下、例)も押さえておく • Slack ※Metalab Designがパートナー • MailChimp ※スタイルガイドや言葉づかいのガイドラインも公開している • Salesforce ※Lightning Design Systemとかも参考になる • Basecamp • INTERCOM ※無料小冊子も参考になる • G Suite • イケてるサービスは日頃から使うこと • 一流にふれる。審美眼を養う。 ピカソは「優れた芸術家は模倣し、偉大な芸術家は盗む」と言った。 だから僕たちは偉大なアイデアを盗むことに関して恥じることはなかった。 Picasso had a saying - 'good artists copy, great artists steal’ - and we have always been shameless about stealing great ideas. -- スティーブ・ジョブズ 調査 > 企画 > 設計 > 実装 > テスト > 販売開始 > プロジェクトクロージング
6. 企画 • クラウドサービス事業のステークホルダー • サービス企画の成果物 • チームビルディング • クラウドサービスの企画・開発・運営に関係する法務の話 • coffee break: 企画の仕事をするのに役立ったものとか
7. 6 クラウドサービス事業のステークホルダー • ステークホルダーのことを考えながら企画を練っていく。 経営者 デベロッパー ユーザー バックオフィス (経理/法務/情シス/内部統制) ビジョン/ビジネス要件 リソースなど データ/プロセス要件 セキュリティ要件など UX DX クラウドサービス 調査 > 企画 > 設計 > 実装 > テスト > 販売開始 > プロジェクトクロージング
8. 7 サービス企画の成果物 (1) • ビジネスモデル・キャンバス • サービス企画書 • ビジネス要件: 経営者から求められていることは何か？ • 制約条件: リソース、時間、プロセスなど面で制約は何か？ • 機会: 「下層市場の過剰満足者」や「非消費者」は存在するか、など • 強み: (前述) • 基本的な戦い方: どのような方針/理論にもとづいて事業を起こすか？ • 4つのPの概要: Product、Price、Place、Promotion ※ヒント = Simplicity、Affordability、Accessibility、Convenience • ロードマップ: この先1年ぐらい、いつごろ何をするか？ • 収益構造/計画: 何にいくらぐらい費用を使うか？ 誰からいくらぐらい売上を得るか？ いつ頃に単月または累計で黒字化するか？ • 体制: プロダクトマネージャー、デザイナー、デベロッパー、テクニカルディレクター、マーケター、セールス、サポート、など • リスク要因/検証すべき仮説/将来的な検討事項: 考えないといけないこと、決めないといけないことをメモ。堂々巡りにならないように。 • FAQ: 同じことを何回も説明するのは面倒ですもんね。 • ペルソナ • チームビルディングも兼ねて、主要メンバー全員でつくる。 • 共感マップ • 設計や実装フェーズで、誰かを説得するための材料としてペルソナを都合よく使わないように。 • ブランドプロポジション(顧客に対して果たすべき約束) → ロゴマークやUIなど見た目の判断基準 • 作り手の意志: 信念とか哲学を結晶化したことば • 顧客に提供する価値 ※以下、例 • Helpful: (サービス名)は、つまらないことや面倒なことをさっと片付けてくれる、いつも元気で頼りになる存在 • Comfortable: (サービス名)は、一緒にいても気を使ったり緊張することのない、気楽に付き合える存在 • Bright: (サービス名)は、いつも爽やかに笑顔で接してくれて、でもはっきりと物事を指し示してくれる存在 調査 > 企画 > 設計 > 実装 > テスト > 販売開始 > プロジェクトクロージング
9. 8 サービス企画の成果物 (2) • サービス名(ネーミング) • ヒント = 記憶可能性、意味性、選考性、移転可能性、適合可能性、防御可能性 ※出典: 『エッセンシャル戦略的ブランド・マネジメント第4版』P.119 • エクメルンでは、日本国内/日本人を対象にしたサービスであり、読みやすさも考慮して英文字ではなくカタカナにした。 エクセルにメールをハイシン • ドメイン名 • 危ない意味になっていないか？ • そのドメイン名で、TwitterとFacebookのアカウントは空いているか？ • ZendeskやStatusPage.ioなど、事業を運営する中で利用するクラウドサービスのサブドメインが空いていればBetter • 英文字の見た目はどうか。アセンダーやディセンダーが醸し出す印象、カドカド感や丸っこさはブランドイメージにそぐわっているか？ • Google検索で危ないページや不適切なページがヒットしないか？ • 「.io」か「.com」か「.jp」か、それとも？ • Domainrなどを見て、「ecume.run」や「エクメルン.com」「ecumerun.jp」など関連するドメインを取っておいた。 費用は微々たるものだし、短縮URLで使うかもしれないし、イタズラで偽サイトを立ち上げられないように防衛する意味もある。 • 製品名とドメイン名のどちらも、「なぜその名前(文字列)にしたんですか？」と後々ちょいちょい聞かれる。 そう決めた理由を書き残しておくこと。意思決定の理由を説明することは、プロダクトマネージャーの大事な仕事 • チーム憲章 ※以下、開発チーム内憲章の例 • プロフェッショナルとして、ハイクオリティなサービスをハイスピードで提供する。 • 「車輪の再発明」は行わず、クラウドベンダーとしての責務を果たす。 • 価値提供に重きをおいた、情熱あふれる職人魂の文化を醸成する。 • 関西の商人(あきんど)デベロッパー集団というブランディングを確立する。 • 衝突を恐れずもホスピタリティあふれる仲間(デベロッパー)の採用につなげる。 調査 > 企画 > 設計 > 実装 > テスト > 販売開始 > プロジェクトクロージング
10. 9 サービス企画の成果物 (3) • ビジネスプロセスマップ ※以下、イメージ ※避けないといけないこと: 複雑化・形骸化・(例外処理の)常態化・(組織の)肥大化・硬直化 ※7つのムダ: つくりすぎのムダ、手持ちのムダ、運搬のムダ、加工そのもののムダ、在庫のムダ、動作のムダ、不良をつくるムダ ※やること、やらないことはサイトでも公開していたりする。 調査 > 企画 > 設計 > 実装 > テスト > 販売開始 > プロジェクトクロージング 企画/設計 開発 広告/広報 説明 販売/契約 導入/ 設定支援 制作/ 運用支援 サポート (障害対応) 請求/ 決済/ 入金管理 やること 社外リソースの 活用 他社サービ スの活用 他社とのアラ イアンス 動画での 説明 サイトでの契約 サイトで 顧客自ら 実施(セル フサービ ス) • セルフサービス • スポット利用の 場合、一定期間 経過後にアカウ ント自動削除 • メール • FAQ • 稼働状況(障害報 告)サイト • Welcomeメールと Goodbyeメール • クレジットカー ド決済 • サイト上での領 収書 やると 危険なこと 不必要な情報保 持(漏洩時の損 失..) 多額の広告出 費(黒字化が遠 のく..) 個人向けの販売(「反 社チェック」やいたず ら防止..) コミュニティ運営 (高コスト構造 に..) 電話対応(高コスト構 造に..) 銀行振込(高コス ト構造に..) やらないこと • レギュラー組織 への統合(低コ スト構造の崩 壊..) • 多機能化(複雑 化と高コスト 化..) 自前主義(リ ソース競合 問題、ス ピード低 下..) セミナーや展 示会など(販管 費膨張..) デモアカ ウント発 行(付加価 値の小さ な仕事が 増える..) • パートナー制度 • 値引き • 稟議書 • 個別の提案書/見積 書作成 • 個別セキュリティ チェック対応 • 営業アサイン • 訪問 • 紙の契約書 • スタッフアカウント 管理 導入・設 定代行(フ ルサービ ス) • オンサイトト レーニング • ユーザー会 • 顧客カルテ • SLAの策定と運用 • 個別の障害報告 • クライアント証明 書の発行と管理 • 営業担当者の引き 継ぎ • 紙の解約届 • 社内向けリリース 予告メール • 機能アップデート カレンダー • 障害速報Twitter • 請求書の個別対 応 • 料金の個別メー ル通知 • 月単位での従量 課金制
11. 10 チームビルディング • エクメルン(2017年3月にリリースしたVersion 2.0)をつくったコアメンバー • プロダクトマネージャー/1名 • デザイナー/1名: ロゴ&ワードマーク、管理画面、ブランドサイト、サポートサイト、スタイルガイドサイト(社内限定) • テクニカルディレクター/1名 ※社外パートナー • デベロッパー/3名: アプリ&フロントエンド担当、アプリ担当、インフラ&アプリ担当 • フロントエンドデベロッパー/2名: 管理画面担当、ブランドサイト&サポートサイト担当 ※社外パートナー • 主な社内パートナー • テスター/2名 • デベロッパー/1名: メール配信系API開発 • その他の社外パートナー • インフラ設計/構築支援: クラスメソッド株式会社様 • ユーザー向け通知HTMLメール&マーケティングコンテンツ制作支援: 株式会社タンバリン様 • セキュリティ診断: 某社様 • チームビルディングで気をつけたこと • つくるものが流動的だったので、テクニカルディレクターとフロントエンドデベロッパーとの契約形態は請負ではなく準委任にした。 • そのぶん、仕事を依頼する側としても早めに決めて早めに動かないといけない。 • パートナーさんの参画度合いを強め、設計品質と製造品質を高めるため、コミュニケーション環境づくりはしっかりと。 • 発注者の責任: 背景や理由の説明も丁寧に。仕事の依頼もお金周りも早め早めで誠実な対応を。 • “十の100%は、千の10%に勝る。 ほとんどの場合、小規模なグループがイノベーションに専念したほうが良い結果が得られる。多数の人々のそれぞれに対してイノベーショ ンに少しの時間を使ってもらうように頼んでも、たいていの場合、中核事業に時間を取られて望んだ結果が得られなくなるものだ。” -- 出典: 『イノベーションへの解 実践編』P.367 • “真に恐れるべきは有能な敵ではなく無能な味方である。” -- ナポレオン・ボナパルト 調査 > 企画 > 設計 > 実装 > テスト > 販売開始 > プロジェクトクロージング
12. 11 クラウドサービスの企画・開発・運営に関係する法務の話 • 商標 • エクメルンでは、文字商標と図形商標を登録した。 • 登録料は、手数料などを含めて合計で30万円弱 • 出願から登録まで半年以上の時間がかかった。 • 契約 • 開発パートナーと業務委託基本契約書(NDA含む)と個別契約書(または注文書)を締結する。 • 請負、準委任、派遣。エクメルンでは準委任で行くことにした。 • 利用規約 • 自社の既存サービス、他社のサービスの利用規約をインプットとして作成していく。 ※ゼロからはじめない。 • プロダクトマネージャーが作成プロセスを主導し、法務部門任せにしない。 問題の発生を防ぎ、また、万一問題が起こったときに自社を守る盾になるのが利用規約。一字一句、細かく法務部門と詰めていく。 • 個人情報保護法 • 「第三者提供に当たりますか」とユーザーから問い合わせがくることがある。 • “当該クラウドサービス提供事業者が、当該個人データを取り扱わないこととなっている場合には、当該個人情報取扱事業者は個人データを 提供したことにはならないため、「本人の同意」を得る必要はありません。” -- 出典: 『「個人情報の保護に関する法律についてのガイドライン」及び 「個人データの漏えい等の事案が発生した場合等の対応について」 に関するＱ＆Ａ』P.32(A5-33) • いわゆる「反社チェック」 • チェック担当者と業務プロセス(対象、手順、頻度、NG企業への対応方法など)を詰める。 • ステージング環境を構築後、チェック担当者とリハーサルをおこない、問題なくチェック業務ができるか確認する。 • エクメルンでは、利用規約の第11条と第30条あたりでも言及している。 • 特許/実用新案/意匠権 → Invisible Edge • 知的財産権の専門家と相談し、イケそうなら出願! 調査 > 企画 > 設計 > 実装 > テスト > 販売開始 > プロジェクトクロージング
13. 12 企画の仕事をするのに役立ったものとか • ワークショップ • 模造紙: マルアイのBIG PAPER • ふせん: 強粘着ポスト・イット ※ワークショップをしているときにパラパラはがれにくい。 • ペン: プロッキー ※インクが裏移りしにくい。 • 本 • ビジネスモデル・ジェネレーション • イノベーションへの解 ※実践編も • アート・オブ・プロジェクトマネジメント • リーン・スタートアップ • HARD THINGS • 小さなチーム、大きな仕事 • How Google Works • イシューからはじめよ • ことば • “昔ながらのプロジェクト管理手法で用いる詳細な予測と計画は、その大半が時間の無駄になる。チームとしてビジョンと計画は立てねばな らないが、実際に作業に取りかかる時点まで変化がないであろうタスクについてのみ計画を立てるべきだ。” -- 『アジャイルの価値と原則』 ※出典: 『ダイヤモンドハーバードビジネスレビュー 2016 年 9 月号』P.96 • “以下の手法により、企業は、破壊的イノベーションのチームが必然的に直面する軋轢を避けられるようになる。 • 異なる成功指標を使用する。 • 指揮系統の単純化、そして、重要資源と意思決定への統制権の付与によりチームに大幅な自立性を与える。 • 軋轢を生じさせる可能性が高いプロセスを避けられるように、チームに「ファストパス」などの回避策を提供する。 • チームが社外に人的資源を求めることを許可する。社内の人的資源しか活用できないチームは、社内のルールに従わざるを得なくな るからである。” -- 出典: 『イノベーションへの解 実践編』P.299 coffee break 調査 > 企画 > 設計 > 実装 > テスト > 販売開始 > プロジェクトクロージング
14. 設計 • アーキテクチャー • セキュリティ • ユーザーインターフェース • coffee break: 「シンプルであること」に関する偉人の名言
15. 14 アーキテクチャー (1) エクメルンで参考にしたものや検討したことを挙げます。 • 参考アーキテクチャー • スケーラブル • Design for Failure • Infrastructure as Code • Immutable Infrastructure • マイクロサービス • サーバーレスアーキテクチャ • Reactive Programming • The Twelve-Factor App • 設計ポイント • HA構成 • スケールアウト • 非同期処理 • サーバーレス化 • 処理の中断・再開 • BGデプロイ • 環境差分の最小化 • ログの集中管理 調査 > 企画 > 設計 > 実装 > テスト > 販売開始 > プロジェクトクロージング GitBookで全文を読む →
16. 15 アーキテクチャー (2) • クラウドサービス選定ポイント • 特徴 • 価格 • 事例 • 運営会社 • 情報量は多いか？ • セミナー参加してみる • 利用してみる • サポート問い合わせしてみる • ビジネス優位性を検討 • 営業マンに相談してみる • 使いたいかどうか • 選定後 選定したあとは必ず理由をドキュメントに書き残しておきます。 調査 > 企画 > 設計 > 実装 > テスト > 販売開始 > プロジェクトクロージング GitBookで全文を読む →
17. 16 セキュリティ (1) 個人情報の漏えいなど事故が起きれば「一発退場」になりかねません。 Security is our first priority. エクメルンでは以下の流れでセキュリティ対策に取り組みました。 1. セキュリティリーダー選出 2. 情報収集 3. 学習 参考にした書籍やサイト • 体系的に学ぶ 安全なWebアプリケーションの作り方 • Web API: The Good Parts • 安全なウェブサイトの作り方 • SSL/TLS暗号設定ガイドライン〜安全なウェブサイトのために（暗号設定対策編）〜 • Webシステム/Webアプリケーションセキュリティ要件書 • ソフトウェア出荷判定セキュリティ基準チェックリスト • とある診断員とAWS • フリーでやろうぜ！セキュリティチェック • IPA テクニカルウォッチ「ウェブサイトにおける脆弱性検査手法(ウェブアプリケーション検査編) • Rails セキュリティガイド • Ruby on Rails Cheatsheet 調査 > 企画 > 設計 > 実装 > テスト > 販売開始 > プロジェクトクロージング GitBookで全文を読む →
18. 17 セキュリティ (2) 4. 社内診断準備 セキュリティリーダーが以下の準備をします。 • 社内診断用チェックシートを整理 • 社内診断で利用する診断ツールを選定し使い方をマスターする • AWSへの侵入テスト申請 5. 社内診断 6. 社外診断 7. 情報公開 コスト構造などの面から個別のセキュリティチェックの依頼を受けない方針とする場合、セキュリティへの取り組みをきちんと公開します。 • エクメルンでの例 • ブランドサイト: セキュリティ • サポートサイト: セキュリティ基準についてどう考えていますか？ • サイボウズ様での例 調査 > 企画 > 設計 > 実装 > テスト > 販売開始 > プロジェクトクロージング GitBookで全文を読む →
19. 18 ユーザーインターフェース (1) • サービスの価値を左右するもの。 プロダクトマネージャーもしっかり知識武装して、情報構造を考えたりワイヤーフレームを書いたりして、デザイナー任せにしない。 • エクメルンは、以下のステップでUIを具体化していった。 1. ペーパープロトタイプ: A3の方眼紙に鉛筆で。※サポートブラウザも早い段階で決めておく。 2. ワイヤーフレーム: Google スライドで作った。コメント機能が便利だった。 • モーダルウィンドウやスマホでの見た目を含め、全画面のワイヤフレームをもれなくつくった。 • UIテキストもほぼ最終化しておいた。 3. デザイン: marvelにアップ。コメント機能が便利。スタイルガイドも同時につくっていった。 4. テクニカルディレクターのレンタルサーバー: 静的モック(HTML/CSS)をアップ。 5. heroku: アプリとJSを組み込んだ動的モック。ここで見つけたバグや修正依頼はGitHub Issueに集約。 6. ステージング環境: AWS上に構築。社外パートナーによるセキュリティ診断もステージング環境で受診。 7. 本番環境 各ステップで誤字脱字や漏れ間違いを見つけたら、容赦なく指摘し、その時点で修正しておくこと。 ※後工程になればなるほど忙しくなり、修正を指摘する側もされる側も時間的/心理的余裕がなくなってくる。 • いくつかあるデザイン案からひとつを選ぶとき、ブランドプロポジションがよりどころのひとつになる。 • “デザインというのは他の分野に比べてはるかに意見の対立しやすい分野です。” -- 出典: 『デザインの伝え方』P.256 • UIテキストを書くときのポイント: • 用語集をつくる。表記のゆれが出ないように。 • "書き手は往々にして、読者が知りたいと思う以上のことを伝えなければと信じ込んでいる。" -- パトリシア・ライト • テキストの書き方を公開している企業もある。 • Microsoftの「ユーザー インターフェイスのテキスト」「エラー メッセージ」や、Salesforceの「Voice & Tone」 調査 > 企画 > 設計 > 実装 > テスト > 販売開始 > プロジェクトクロージング
20. 19 ユーザーインターフェース (2) • リリースした後にUIの良し悪しを定量的に分析できるよう、Google Tag Manager/Google Analyticsを仕込んでおく。 • ユーザー都合ではなく自社都合のUI設計は、長い目で見れば結局「コスト高」や「顧客離反」として跳ね返って来るもの。 「ありがたみをわかってもらおう」とか「解約ボタンを見つけにくくしよう」とかはやめておいたほうがいいと思います。 • エクメルンでは、UIデザインのレビュー、UIテキストの執筆をプロダクトマネージャーが担当した。 UIに関するすべての情報を押さえておくことで、後々のサポートサイトの記事執筆がかなりラクになった。 • エクメルンでは、2017年3月のサービスリリース後、少し落ち着いた翌4月にスタイルガイドサイトを社内公開した。 以下、スタイルガイドに関する参考情報: • フロントエンドスタイルガイド：定義と要件、コンポーネントチェックリスト • Airbnb, Uber and Mailchimp: Inside the Web Design Style Guides of 10 Brands We Love • 参考図書など(プロダクトマネージャーとして押さえておいたほうがいい情報): • デザイニング・インターフェース 第2版 • インタフェースデザインの実践教室 • UIデザインの心理学―わかりやすさ・使いやすさの法則 • マイクロインタラクション ―UI/UXデザインの神が宿る細部 • ノンデザイナーズ・デザインブック [第4版] • Google Material Design • iOS Human Interface Guidelines • BBC GEL • あるとよい機能はない方がよい 調査 > 企画 > 設計 > 実装 > テスト > 販売開始 > プロジェクトクロージング
21. 20 「シンプルであること」に関する偉人の名言 • "シンプリシティを実現する最もシンプルな方法は、「考え抜かれた削減」を通じて手に入る。" “The simplest way to achieve simplicity is through thoughtful reduction.” -- ジョン・マエダ • "より少なく、しかしより良く。" “Less, but better.” -- ディーター・ラムス • "シンプルなものを複雑にしてしまうのはありがちなことだ。複雑なものを至極シンプルにすること。これがクリエイティビティだ。" “Making the simple complicated is commonplace; making the complicated simple, awesomely simple, that's creativity.” -- チャールズ・ミンガス • "完璧というものは、何も追加するものがなくなったときに達成できるものではない。 何も取り去るものがなくなったときに達成できるものである。" “Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away.” -- サン＝テグジュペリ • "もっと時間があれば、もっと短い手紙を書けたのですが。" “If I had more time, I would have written you a shorter letter.” -- ブレーズ・パスカル • "ものごとはできるかぎりシンプルにすべきだ。しかし、シンプルすぎてもいけない。" “Everything should be made as simple as possible, but not simpler.” -- アルベルト・アインシュタイン • "シンプルさは究極の洗練である。" “Simplicity is the ultimate sophistication.” -- レオナルド・ダ・ヴィンチ coffee break 調査 > 企画 > 設計 > 実装 > テスト > 販売開始 > プロジェクトクロージング
22. 実装 • 開発環境 • フロントエンド • APIの設計と開発 • アプリケーション • インフラ • CI/CD • Gitの運用
23. 22 開発環境 (1) エクメルンではフロントエンド、サーバサイドが独立して開発できるように各開発環境を用意。 • フロントエンド用の開発環境 • HTML, CSS, JavaScriptだけで動作確認できる環境。 • webpack-dev-serverを使用。 • サーバサイド用の開発環境 • Rails標準の開発環境。 • フロントエンドとの結合はタスクランナーのgulpを使って実現。 • 環境構築に便利なライブラリ及びツール • fake_sqs • ローカルマシン上に開発用のAWS SQS機能を構築 • fake_s3 • ローカルマシン上に開発用のAWS S3機能を構築 • DynamoDB ローカル • ローカルマシン上に開発用のAWS DynamoDB機能を構築 • localstack • ローカルマシン上に開発用のAWS機能を構築 • foreman • プロセス一括起動 • Postman • 使いやすいAPIクライアント • webpack-dev-server • フロントエンドの開発効率を向上させる開発環境用サーバ 調査 > 企画 > 設計 > 実装 > テスト > 販売開始 > プロジェクトクロージング GitBookで全文を読む →
24. 23 開発環境 (2) 各環境を用意するメリット、デメリット • メリット • 同時並行での開発がしやすい → 仕様を決めた後は、それぞれが独立して開発をすすめることができる • デバッグしやすい → 各領域に集中して開発ができるため、エラー発生時にも原因を特定しやすい • デメリット • 構築の手間がかかる → 各環境ごとに構築 & 構築後のメンテナンスが必要 • 結合するまで潜在している問題が確認しにくい → もし各環境で異なる認識をしたまま進めてしまうと結合時の手戻りが大きくなる その他、開発環境構築のポイント • 環境の統一 • マシンを統一することで開発環境構築が楽に、エディタを統一することで共通のフォーマッタ機能が使えるように、などの恩恵がある。 • 必要なミドルウエアなどインストール手順、アプリ起動方法などの整備 • 新しいメンバーがプロジェクトにジョインした際に参考になる。 • お役立ちツール • rbenv, nodebrew • プロジェクトごとにRuby, Node.jsのバージョンを統一できる • dotenv • 開発環境用の環境変数設定が楽になる • Browsersync • 開発環境でもIEやスマホの動作確認ができる 調査 > 企画 > 設計 > 実装 > テスト > 販売開始 > プロジェクトクロージング GitBookで全文を読む →
25. 24 フロントエンド (1) エクメルンではサーバサイドデベロッパーもフロントエンド開発に参画しました。 開発を通じて感じたことなどをサーバサイドデベロッパー視点で紹介していきます。 著者背景 • 経験領域 • メインはサーバサイドのアプリデベロッパー • HTML, CSSは独学である程度習得している • 業務でJavaScriptを使ったことがある • gulpやwebpackを使ったチュートリアルレベルの環境構築をしたことがある • 未経験領域 • デザイナーと一緒に仕事したことはなかった • CSSやJavaScriptのきれいな設計までは考えたことがなかった • チームでのフロントエンド開発をしたことがなかった 調査 > 企画 > 設計 > 実装 > テスト > 販売開始 > プロジェクトクロージング GitBookで全文を読む →
26. 25 フロントエンド (2) フロントエンドデベロッパーについて考える: 必要と思うスキル • デザイナー、サーバサイドデベロッパーとのコミュニケーション • デザイナーの意図を汲み取り、実装に落とし込む能力 • サーバサイドのデベロッパーと連携してサービスを作り上げていく能力 • サービスについての理解 • 作成する画面や演出がなぜ必要なのかについて理解し、必要な場合には提案までできること • デザインの知識 • デザイナーとの意思疎通に有効(グリッドデザイン、シャドウ、Flexboxなど初めて聞く用語がたくさんあった) • サーバサイド技術の知識 • クライアントサイド、サーバサイド両方の特徴を理解しておけば幅広い視点でベストな実装を選択できる • フロントエンド開発全体の設計 • HTML, CSS, JavaScriptといったフロントエンドに関わるすべての要素をメンテナブルに設計できる能力 • UI作成 • フロントエンド技術を駆使してデザインに沿った画面作成ができること • ビジネスロジック作成 • サービス要件を満たすロジック作成ができること 参考情報 • エンジニアからデザイナーに向けて、デザインカンプを作るときにしておいて欲しいこと。 • 実装を引き受ける前に詰めておくべきWebフロントエンドの想定漏れチェックシート • Front-end Developer Handbook 2017 調査 > 企画 > 設計 > 実装 > テスト > 販売開始 > プロジェクトクロージング GitBookで全文を読む →
27. 26 フロントエンド (3) フロントエンドデベロッパーについて考える: エクメルンでのフロントエンド開発担当 すべてをカバーする人材を探すのは難しかったため、チームに不足しているスキルセットを洗い出し、全体を補える人員配置を実施。 最終的に以下の3人体制で進めることに。 1. マークアップオリエンテッドフロントエンドデベロッパー（MUO） デザイン寄りのフロントエンドデベロッパー • 主にデザイナーと連携して画面モック作成や演出の実装を担当 • 最適な画面演出実装方法が選択できるスキルがある(CSSで可能なのか、JavaScriptが必要なのかなど) 2. サーバサイドオリエンテッドフロントエンドデベロッパー（SSO） サーバサイド寄りのフロントエンドデベロッパー • 主にフロントエンドの開発環境構築やビジネスロジック作成を担当 • サーバサイドの技術にも長けているため非同期通信によるAPI連携もする 3. テクニカル・ディレクター or マネージャー • デザイン 〜 サーバサイドの領域全体を把握してサービス自体の方向性やフロントエンドの実装方針などの決定に携わる • エクメルンではフロントエンドチーム内でのコミュニケーションを円滑にするために活躍 調査 > 企画 > 設計 > 実装 > テスト > 販売開始 > プロジェクトクロージング GitBookで全文を読む →
28. 27 フロントエンド (4) エクメルンでのフロントエンド開発のポイント: 画面作成 デザイナーとフロントエンドデベロッパー間の「確認 ↔ 修正」のサイクルを速く回すことを心がけた。具体的には以下の方法で実施。 1. 開発者が画面、演出を作成 2. Browsersyncを起動してデザイナーが画面を確認 3. 確認完了したコードをリポジトリにプッシュ 4. リポジトリのプッシュを契機にHeroku環境を自動更新 (最新の状態はHeroku環境上で自動的に用意されるようにした) 参考情報 • Browsersync • 開発マシンに対し、ネットワーク内の他のマシンからアクセスができるようになるツール • デザイナーが開発者のマシンに直接アクセスして確認することで、リアルタイムでの修正が可能 • 成果物をFTPなどでアップロードする手間がなくなる • Heroku • GitHubと連携することでプッシュを契機にHeroku上で自動デプロイが走り、常に最新の確認環境が用意できる • チームメンバーが気が向いたときにいつでも最新の状態が確認できるようになる 調査 > 企画 > 設計 > 実装 > テスト > 販売開始 > プロジェクトクロージング GitBookで全文を読む →
29. 28 フロントエンド (5) エクメルンでのフロントエンド開発のポイント: フロントエンド全般の設計 HTML, CSS, JavaScriptのコーディングガイド、規約を作成してメンテナブルなコードになるように設計。 • HTML • 世の中に公開されているコーディングガイドを参考にチーム用のガイドを作成。 • CSS • クラス命名規則として「BEM」、 全体の構成案として「FLOCSS」を参考にして設計。 • JavaScript • AirbnbのJavascript Style Guideを参考にコーディング規約を作成。 • ESLintによる構文チェックを導入。 参考情報 • HTML, CSSコーディングガイド • BEM • FLOCSS • AirbnbのJavascript Style Guide • ESLint • Google HTML/CSS Style Guideを全部日本語に訳してみた【HTML編】 調査 > 企画 > 設計 > 実装 > テスト > 販売開始 > プロジェクトクロージング GitBookで全文を読む →
30. 29 フロントエンド (6) エクメルンでのフロントエンド開発のポイント: ビジネスロジック実装 React, Reduxを使う場合のポイント。 (基本的な情報はチュートリアルや書籍などで豊富に紹介されているので割愛) • コンポーネントのライフサイクルを理解する • 初期化、画面更新などのタイミングを把握することで最適な実装が可能となる • state管理は Immutable.js を使う • 意図しないデータ更新などを発生させないためにも重要 • reducer分割とreselectでコードをすっきりさせる • うまく活用することで画面とデータの設計がきれいになる 参考情報 • Immutable.jsを使ってReactで入れ子になってるstate更新をするとかそういったときに楽しよう的なお話 • immutableのメリットとImmutable.jsでのModel定義 • Understanding the React Component Lifecycle • Reduxのreselectとは Reactの勉強に役立った書籍 • Reactビギナーズガイド ――コンポーネントベースのフロントエンド開発入門 調査 > 企画 > 設計 > 実装 > テスト > 販売開始 > プロジェクトクロージング GitBookで全文を読む →
31. 30 APIの設計と開発 エクメルンのフロントエンドはReactを使ったSPAで、バックエンドのAPI部分はRailsで作られている。 非常にタイトなスケジュールだったが、フロントとバックエンドは疎な関係としてすべてAPI経由で情報を取得するよう構築したので、 開発・テストしやすかった。 以下の書籍はAPIに関する設計、開発、運用について簡潔にまとめられている。おすすめ。 • 『Web API: The Good Parts』 • 設計 • APIの定義には試行錯誤は向かない。はじめにきっちり決めておく • APIはオレオレ設計をしない。デファクトスタンダードに従うことで容易に利用方法が推測し開発を行える設計にする • APIの戻り値は画面を意識しすぎず、オブジェクトをあらわす塊を返すことで利用者側に柔軟性が生まれる • 覚えやすく、どんな機能を持つURIなのかひと目で分かるURL設計にすること • Google DocsでAPIを仕様を作ったが更新するのがつらい。また公開するのにも向いていない。 • 次回はAPI仕様を定義するのに、readme.ioやSwagger等で定義してみたい • 開発 • データ形式は特に理由がなければJSON • 大まかなエラーの種別はステータスコードで表現し、理由をレスポンスBodyで返す • ステータスコード:400, 詳細:「メールアドレスまたはパスワードが間違っています。」 • ステータスコード:429, 詳細:「ログイン回数の制限を超えました。1 時間後に再度試してください。」 • APIの動作確認にはPostmanが便利 • フロントとバックエンドの結合はいきなり行うのではなく、双方でき次第順次確認を行うことで、スムーズに結合できる • セキュリティ • 通信にはHTTPSを利用 • 悪意あるアクセスを防げる仕組みを仕込む • パラメータの改ざんでデータに不整合が発生しないよう、更新可能な値を制限する 調査 > 企画 > 設計 > 実装 > テスト > 販売開始 > プロジェクトクロージング GitBookで全文を読む →
32. 31 アプリケーション (1) “アイデアとは既存の要素の新しい組み合わせ以外の何ものでもない。” -- ジェームス・W・ヤング アプリケーションを作る上で大切なのは、アプリケーションが提供する価値にフォーカスしてものづくりを行うことだ。 自分たちが時間やコストをかけて作らなくても、既にいいものがある場合は（コスト的に見合うものならば）積極的に利用した方がよい。 そして時間を作り出し自分たちが本当に作りたいものだけに注力し生産性を向上させよう。 また、これから作ろうとしているものがどのようなものなのかある程度道筋を立ててから手を動かし始めるのがよい。 ここに掲載していることはごく一部です。以下にノウハウをまとめました。 https://ecumerun.gitbooks.io/how-to-make-a-cloud-service/content/development/application.html#rails-practice • 設計 • ER図を書いてアプリケーションのデータ構造をイメージする • DB設計に失敗すると全体的に歪んだアプリケーションになってしまう • 実装しようとしていることが既存のライブラリや、外部サービスに置き換えられないか調べる 未来のことはわからない。 あれこれ考えすぎない。 YAGNI • 実装 • 実装前に、コーディングルールやセキュアな実装方法に関してはチームで意識合わせをしておく • DRYそして、KISS • レールに乗る → オレオレ実装を始めるととたんに面倒なことになる • 運用も意識した実装をおこなう • 本番DBを直接触らないように管理画面を設ける • ボトルネックを把握できるように • 障害検知、原因究明を行いやすい仕組みづくり 調査 > 企画 > 設計 > 実装 > テスト > 販売開始 > プロジェクトクロージング GitBookで全文を読む →
33. 32 アプリケーション (2) アプリケーションフレームワーク Ruby on Railsを採用。社内のメインサービスが他の言語で作られているため異論などもあったが、以下のように調査を進めて採用にいたった。 • セミナー、書籍の活用 • 基礎知識を体系的に学ぶ。 • 社内の知見収集 • 社内の別プロジェクトや案件などでRailsに携わっている人からノウハウを吸収。 • 事前検証 • DB操作、エラーハンドリング、ログ出力、非同期処理などの主要処理を重点的に調査、検証。 エクメルンのサービス規模(大きすぎず、継続的に改善する)では最終的にRuby on Railsがマッチ。 作ろうとしているサービスに合う言語、フレームワークを選ぶことも重要。 セミナー、書籍情報 • Rails チュートリアル • Ruby on Rails 5アプリケーションプログラミング 調査 > 企画 > 設計 > 実装 > テスト > 販売開始 > プロジェクトクロージング GitBookで全文を読む →
34. 33 アプリケーション (3) 電話番号認証 電話番号認証機能にはクラウド電話APIサービスのTwilioを利用。実装のポイントについて紹介。 • APIコール制限 • Twilioには1アカウントごとに 1APIコール/1秒 という制限がある • エクメルンではTwilioAPIをコールする処理を非同期のワーカーに集約し、実行間隔を調整することで対応 • 開発環境でのコールバックアクセス • Twilioの一部APIではコールバック受付処理をサービス側で実装する必要がある • エクメルンではBrowsersyncを活用し、一時的に外部からアクセスできるURLを用意して対応 調査 > 企画 > 設計 > 実装 > テスト > 販売開始 > プロジェクトクロージング GitBookで全文を読む →
35. 34 アプリケーション (4) クレジットカード決済 クレジットカード決済にはStripeを導入。お金に関わるサービスとなるためここでは選定のポイントについて紹介。 • 料金 • 初期費用 • 月額費用 • 決済ごとの手数料(固定額) • 決済ごとの手数料(パーセンテージ) • 振込手数料 • 返金手数料 • チャージバック手数料 • 機能 • 決済機能(与信確保、決済確定) • 顧客管理機能 • 継続課金機能 • トークン決済 • 対応しているカードブランド • 信頼性 • 会社規模 • 導入事例 • PCI-DSS準拠 • 加盟店契約方式 • メンテナンス頻度 • 不正利用対策 • サポート体制 • 直接お話をしてみての印象 調査 > 企画 > 設計 > 実装 > テスト > 販売開始 > プロジェクトクロージング GitBookで全文を読む →
36. 35 インフラ (1) エクメルンで実際に参考にした書籍・サイトや設計、利用ツールや各コンポーネントで気をつけたことなどを挙げます。 • 参考書籍・サイト • Amazon Web Services クラウドデザインパターン設計ガイド • Amazon Web Services実践入門 • AWS ドキュメント (公式ドキュメント) • AWS クラウドサービス活用資料集 (公式オンラインセミナー資料) • Amazon Web Services ブログ (公式ブログ) • Developers.IO • The Twelve-Factor App 調査 > 企画 > 設計 > 実装 > テスト > 販売開始 > プロジェクトクロージング GitBookで全文を読む →
37. 36 インフラ (2) • 利用ツール • Packer • Ansible • Terraform • Apex • 利用コンポーネントポイント • VPC • EC2 • CodeDeploy • ALB • RDS • DynamoDB • SNS • S3 • CloudTrail • Route53 • CloudFront • WAF & Shield • IAM • 節約のポイント • つくっておくと便利なスクリプト 調査 > 企画 > 設計 > 実装 > テスト > 販売開始 > プロジェクトクロージング GitBookで全文を読む →
38. 37 CI/CD (1) エクメルンでのCI/CD はじめに以下の目標を掲げた。 1. 自動テスト及び静的コード解析による問題の早期発見と質のよいコードの維持 2. 自動化導入による、サービス開発、価値提供へのフォーカス 3. 素早いリリース(価値提供)を続けていくことによるサービス成長速度の向上 4. 最適かつ最速と思える手段で上記目標を達成する 構築方法 • クラウドサービスのCircleCI, AWS CodeDeployを使って構築 • 自動テスト、デプロイをするために特殊なカスタマイズが必要なほど複雑ではなかったためクラウドオンリーで実現 • 独自にJenkinsサーバを用意した場合の運用コストを考慮 CI結果通知 • CI結果はSlackで専用チャンネルに通知、自然と目につくようすることでCIに対する意識を向上 リリース用コードのバックアップ • 自動テストをクリアしたバージョンのコードをS3にバックアップ • リリース時にGitHubが不安定になるなどの事態に対処 ハマったこと • AWS CodeDeployは少々癖が強い。。 → ApplicationStopイベントはデプロイ前のコードで実行されるなど、仕組みを理解していないとハマるポイントが多かった。 • 連携用のユーザを別途用意しておくべし → GitHubの自分ユーザでサービス間の連携をしてしまうと通知メールが自分にしか届かず、重要な情報を見逃しかけることもあった。。 調査 > 企画 > 設計 > 実装 > テスト > 販売開始 > プロジェクトクロージング GitBookで全文を読む →
39. 38 CI/CD (2) CI/CD導入時に気をつけたこと • テスティングフレームワーク、静的解析ツールの選定 自動テストできる環境があってもテストコード作成やコーディング規約遵守の文化がなければ無意味となるため早い段階で検討 • 参考情報 • Rspec • minitest • Mocha • Jasmine • Jest • Rubocop • Brakeman • Eslint • 環境構築、保守にコストをかけすぎない CI/CSの本来の目的(自動化によるサービス開発へのフォーカス、コスト削減)を見失しなわないように構築するのが重要。 クラウドサービスを使うのもあり。 • 参考情報 • Jenkins • CircleCI • Wercker • TravisCI • SideCI • 暗黙知化、ボトルネック化しない CI/CDの構成をドキュメントに残して誰でも全体を把握できるようにしておくとよい。(サービスと同じくいつかは誰かがメンテするものだから) 「CIサーバが落ちているからデプロイできない！」といった問題が発生しないように、手動でのデプロイ手順も用意しておくのもおすすめ。 調査 > 企画 > 設計 > 実装 > テスト > 販売開始 > プロジェクトクロージング GitBookで全文を読む →
40. 39 Gitの運用 • GitHubは自由度が高く、そのまま利用するとカオスな状態になることが想像できた。 運用ルールを設けることでGitHub以外に分散していた開発に関する情報を、GitHubに一本化することができた。 • ブランチの運用 • ブランチの運用にはGit Flowを利用した。スタンダードな使い方を矯正ギブスで習得。 • マージはコマンドラインからでも行えるが、GitHub上でトラッキングするためにもWebインタフェースを利用するのが吉 • Issueの運用 GitHubのIssue管理はそのままでは運用するのが色々つらかった。 • つらみ • Issueが溜まってくると誰がどれを着手していて未着手がどれでがわかりにくい • 別に切り出して管理するのも煩わしくてつらかった Trello、Wrikeなどの外部サービスによる2重管理は整合性が取れなくなる • 改善策 • ラベルを駆使して一覧からチケットを把握できるようにした • 状態、種別、対象、優先順位 • マイルストーンを設けて直近に取り掛かるべきチケットにフォーカスする • 検索でアサインされていないIssueを探す（例：no:assignee, no:milestone） • コミットのコメントはIssue番号を載せてIssueと関連付けることでトラッキングできるように • 他の人に確認してほしいときは、メンションを利用 • Slack連携を行い、プロジェクトの動きを把握 調査 > 企画 > 設計 > 実装 > テスト > 販売開始 > プロジェクトクロージング GitBookで全文を読む →
41. テスト • テスト
42. 41 テスト 動くアプリで開発を円滑に • いつでも動作確認を行える環境をプロジェクト初期段階から用意したことで、プロダクトマネージャーからのフィードバックを得るまでの時間 が短縮され、開発をスピーディーに行えた。また、フロントとバックエンドを早期に疎通確認することで、仕様漏れやイージーミスを未然に防 ぐことができた。 エクメルンはAWS上に本番とステージング環境があるが、確認環境はHeroku上に構築した。アプリの動作確認をインフラが整う前から行えたの が効果的であった。Herokuには申し訳ないが、DBをHobbyBasic(月額$9)以外はすべて無料の範囲内で収まっている。 • Herokuで動かすための設定のコツ • 動作確認用にRailsのenvironment/development.rbをベースにheroku.rbの設定を用意 • 公開を望まない場合には、Basic認証をお忘れなく • Herokuの実行モードをherokuに変更する • Rails＋nodeを使ったプロジェクトでも設定を加えればnodeのビルドを行える • フィードバックを得るためのコツ • developブランチにPushされたのをフックにHerokuにデプロイされるように設定 • デプロイが完了したときには、Slackに通知が行くように設定 • HTMLのメールのプレビュー機能のURLを共有しておくと確認が捗る • 叩き台としてみんなが触るのでついでにモニタリングツールを仕込んで、ボトルネックを把握できる状態にしておく 調査 > 企画 > 設計 > 実装 > テスト > 販売開始 > プロジェクトクロージング GitBookで全文を読む →
43. 販売開始 • マーケティング • coffee break: パートナー制度のフレームワーク • サポート
44. 43 マーケティング • プロモーション • トリプルメディアと非メディア(他社とのアライアンスなど)での施策を書き出し、優先順位をつけて実行へ。 • ゼロからはじめない。ベンチマーク先のサイトとかを調べる。 • パターンがある。例えば、料金ページの例。 • サービス紹介動画についてはSANDWICH VIDEOとかWistiaで情報を集めた。 • 技術畑ではなくビジネス寄りのプロダクトマネージャーとして、プレスリリースやブランドサイトなど一字一句すべて自分で書いた。 • 人に頼りたくなるのを我慢して、自分の頭で一生懸命考える。 • 「下層市場の過剰満足者」や「非消費者」向けのサービスの場合、認知獲得とユーザー獲得が特にむずかしい。 • いわゆるレイトマジョリティーやラガードと、層がおおむね重なっているのかもしれない..。 • 低価格体系の場合、低コスト構造で行かないと利益が出ないので、広告をジャブジャブ出すわけにもいかないし..。 • “Nobody cares about your products except you. Create interesting content.” -- デイヴィッド・ミーアマン・スコット • プライシング • わかりやすさ(Simplicity)とお手頃さ(Affordability)を意識して価格を設定した。 • 経理/会計処理面でややこしい話が出てこないようにする意味でも、1円単位で端数の税額が出ない数字にした。 • コピーが多いインターネット業界なので、模倣/追従の意欲をくじくような価格にするのもあり。 • CLTVや投資回収期間がいくらくらいかを見て、キャッシュアウトがない「フリーミアム」を採用するのもあり。 • 計数管理 • 財務系指標: 経理部門からのレポート(P/L、ソフトウェアの取得価額や簿価) • 非財務系指標(先行指標を含む) • 社員向け管理画面(エクメルン・マネシスと呼んでいます)のレポート: アカウント作成数、解約数、Usage Data • Google Analyticsのレポート: ユーザー、コンバージョン、参照元など 調査 > 企画 > 設計 > 実装 > テスト > 販売開始 > プロジェクトクロージング
45. 44 パートナー制度のフレームワーク • エクメルンではやっていませんが、受注単価が高くて人的販売が成り立つ場合、紹介/販売パートナー制度を検討します。 その際、以下の7点を押さえるといいと思います。 1. プログラムマネジメント: パートナー制度の設計と改定、新制度への移行計画の作成、契約書雛形の作成/更新 2. リクルーティング(新規向け): イベントやセミナー開催などを通じたパートナーの新規開拓、パートナー制度のWebサイト等での告知 3. アカウントマネジメント(既存向け): 営業同行や提案書作成など個別案件の受注支援、提案書やソリューションテンプレートの作成と展開 4. オンボーディング&トレーニング(既存向け): 「Partner Boot Camp」の企画実行、ウェルカムキットの作成と更新、パートナー向けメルマガ配信、パートナー限定サイトの運営管理 (オンライン)、「Partner Summit」等のイベント企画実行(オフライン)、プロダクトトレーニング 5. オペレーション(既存向け): パートナー情報の管理(Partner Relationship Management)、契約書の管理、売上管理、コミッション・インセンティブ料率計算、デモ アカウント管理等のバックオフィス業務 6. リスティング&マーケットプレイス（既存向け): パートナーおよびソリューション紹介サイトの企画・運用 ※例: Salesforce.comのAppExchange 7. アラインメント: グループ会社や資本業務提携先が展開するパートナービジネスとの協調と協働 coffee break 調査 > 企画 > 設計 > 実装 > テスト > 販売開始 > プロジェクトクロージング
46. 45 サポート (1) • クラウドサービス事業者がやっている既存ユーザー向けサービス&サポートには以下のようなものがある。 • サポート: 無償のものだけでなく、設定代行や専任担当者アサインなど有償のサポートを提供しているところもある。 • トレーニング: こちらも、オンサイトやカスタムメイドなど有料のものを提供することもある。 • ベンダー認定資格(例: salesforce.com の認定資格) • 稼働状況サイト(例: Trust.salesforce.com) • オンラインコミュニティ(例: HubSpot Community) • リリース告知(例: salesforce.com のリリースノート) • βプログラム(会社によっては「アーリーアダプタープログラム」と呼んでいるところも)への参加(例: HUBSPOT BETA PROGRAM) • オフラインコミュニティ/勉強会/ユーザー会(例: kintone Café) • 年次イベント(例: Dreamforce) • 価格体系やコスト構造を見て何をやるかを決める。 エクメルンは「低価格体系を支える低コスト構造」を意識してセルフサービス型にした。 • セルフサービス型のサポートに必要なもの • わかりやすいドキュメントとFAQ → サポートサイトをZendeskでつくった。 • 稼働状況の告知と障害報告 → サービス稼働状況告知サイトをStatusPage.ioでつくった。 • Zendeskでサポートサイトをつくるときに意識したこと • ゼロからはじめない。他社の実装例をいろいろ見た。 • 画面キャプチャや図解は使わず、文字だけにした。 • 「低価格体系を支える低コスト構造」をつくるため、付加価値の小さな作業を発生させないように。 • 管理画面の右側にサポート記事が表示されるようにしたが、その小さなエリアでもコンテンツを問題なく閲覧できるように。 ※キーワード = マルチレベルのヘルプ • サポート記事をひとりで書けるよう、日頃から開発ドキュメントをつぶさに読んておいた。 ※仕様や各種パラメーター(上限/下限など)について、リリース間際で多忙なデベロッパーに質問しなくてもいいように。 調査 > 企画 > 設計 > 実装 > テスト > 販売開始 > プロジェクトクロージング
47. 46 サポート (2) • (続き)Zendeskでサポートサイトをつくるときに意識したこと • Slackと連携して、問い合わせ対応をチャネルに流すようにした。 • 問い合わせ対応に必要な情報をそのチャネルでデベロッパーにたずねる。 • デベロッパーも「どのような問い合わせが来るのか(ユーザーの反応)」を知ることができる。 • ZendeskのAPIを使って、管理画面の中にも問い合わせフォームを設置した。 • 同じくAPIを使って、サポートサイトの記事のバックアップを取得した。 • 問い合わせ対応はプロダクトマネージャーやデベロッパーがやっている。 • 「コスト構造的にサポート専任担当者を置けないから」というものあるけど、ユーザーの反応を把握することは大事ですからね。 ※参考: マーケティングを捨てよ、サポートへ出よう 事例から見るスタートアップ初期におけるユーザー獲得 • 判断基準をチームのみんなに知ってもらう。 • ユーザーから要望や依頼が来たとき、どこまでがYesでどこからがNoなのかの線引きの基準 • 「なぜそうしたのか」を含めて考え方や価値基準をシェアする。 • 問い合わせ対応のときに気をつけていること • 一回の返信でクローズできるように。問い合わせの内容や書きぶりから「本当は何に困っているのか？」を読み解く。 • 冗長にならない。尊敬語や謙譲語を使いすぎない。簡潔明瞭。ときには単刀直入(結論から申しますと..)。 • 次に同じ質問が来たときにサッと返信できるよう、Zendeskのサポート記事を作成/更新しておく。 • 改善につながるアイデアはすぐSlackで話し合ったり、やったほうがいいものはすぐGitHub Issueに登録する。 • (参考情報)Usage Dataを活用して解約件数を減らすための取り組み例 • Salesforce - Early Warning System • HubSpot - Customer Happiness Index 調査 > 企画 > 設計 > 実装 > テスト > 販売開始 > プロジェクトクロージング
48. プロジェクトクロージング • プロジェクトクロージング
49. 48 プロジェクトクロージング • 2017年3月に管理画面・ブランドサイト・サポートサイトをリリースしたあと、プロジェクトはクロージングフェーズへ。 • クロージングでやったこと • ドキュメントの整理整頓: いらないものを削除したり、1箇所にまとめたり。 • スタイルガイドの作成: リリースの翌月、スタイルガイドサイトを社内限定で公開。ロゴ画像などの「ブランドアセット」もサイトに掲載。 • 社内の人から「ロゴ画像ください」と言われたときにすぐに返せるように。 • 設計仕様書など重要ドキュメントのアップデート: リリース前のドタバタで更新できなかったものを反映。 ※キーワード = バス係数 • 各種サービスのアカウント整理: プロジェクトを離れる人のアカウント削除など。 • コスト削減: marvelなど役目を果たし終えたサービスの解約、AWSのリザーブドインスタンス契約など。 • KPT: 記憶が鮮やかなうちに。 • ナレッジの体系化と形式知化: ← 今ここ • “魚を一匹与えれば、その人は一日食える。魚の取り方を教えれば、その人は一生を通して食える。” -- 出典: ある国のことわざ • クロージングで意識したこと • 割れ窓理論。「いい加減な仕事」がチーム文化に染み着かないように。千丈の堤も蟻の一穴から。 • 桃栗3年、クラウド8年。いずれ誰かに引き継ぐ。引き継ぎ作業が楽になるように、引き継ぐ相手が理解しやすいように。 • 次のリリースまでの間隔を長めに取る。プロジェクトのスピードをスローダウンし、心身ともに休める。 調査 > 企画 > 設計 > 実装 > テスト > 販売開始 > プロジェクトクロージング
50. 最後に • 生産性 • デベロッパーとして思っていること • プロダクトマネージャーとして思っていること
51. 50 生産性 • コミュニケーションしやすく。でも仕事に集中しやすい環境をつくる。 • ツールをフル活用する。 エクメルンの開発で、生産性を高めるために役立ったと思うクラウドサービスは以下(デベロッパーではなくプロダクトマネージャーの視点)。 • Slack: フローの情報 • esa: ストックの情報 Slackは投稿をURLで指せるので、Slackでの議論を意思決定の経緯としてesaにメモすることも。 • Google ドライブ: ほぼすべてのドキュメントをここで管理。社外パートナーも招待。 • Google スライド、marvel、GitHub Issue: 前述 • Slackは特に役立った。 • ちょっとした議論をSlackで済ませる。相手の仕事を中断しない。 • 意思決定の結果だけでなく理由も書いておくことで、議論の蒸し返しが少なくなったり、自分の記憶が強固なものになる。 • 「あのとき、どんな話になったんでしたっけ？」「なんでああいう仕様にしたんでしたっけ？」とかを減らす。 • "正しく書く事によって初めて考えをより明瞭に且つ確実にすることが出来る。" -- 志賀直哉 • ときには既読を絵文字で示す。「下記、確認しました」とか「了解です」とか文字で返信すると、相手の集中力にわずかな中断が..。 • 用語集は早めにつくる。 • サービスの『概念モデル』を明確にすることでもある。 • デベロッパーが変数名を考えるときのインプットになるし、テスターに説明するときにも役立つ。 • リモートワークとかもOKに。 • “企業がスピンアウト組織に既存のプロセスを「授け」、組織全体の価値基準を強要すれば、スピンアウト組織は組織のほかの部分となんら 変わらなくなってしまう。企業が独立組織に社内のコスト構造やプロジェクトの承認プロセスを強要すれば、新しい組織は持続的なビジネ スモデルをもつようになることが多い。” ※出典: 『イノベーションの最終解』 P.117 最後に
52. 51 デベロッパーとして思っていること • 柔軟な開発手法の選択 エクメルンの開発では以下のように開発手法は柔軟に変更しました。特に大きな問題はなく開発できました。 • ローンチまではウォーターフォール型 • ローンチ後はスクラム型 • プロジェクトと自己実現の歯車をあわせる 各メンバーでプロジェクトを通じ成し遂げたいこと (◦◦をやってみたい、◦◦の技術を習得したい、◦◦を導入してみたい) を事前に話し合い、 できるだけチャレンジできるようにしました。 • 分報の導入 Slackで試験的に分報を導入してみました。各々自分専用の公開チャンネルを作り、限りなくTwitterに近い、ノルマなし、仕事・プライベート のつぶやきなんでもござれのゆるふわ運用で6ヶ月ほど経ちましたが、いい感じにワークしています。 • ドキュメント管理ルール あとあと悪い意味で枯れていくことが多いドキュメントの管理には以下のルールを設け、今のところうまくワークしています。 • ドキュメントはすべて一つの場所に集約する • 定期的にクリーニングを行う (要不要の判断がつかないドキュメントは思い切って断捨離) 最後に GitBookで全文を読む →
53. 52 プロダクトマネージャーとして思っていること • 独立と自律 • 「企業内スタートアップ」の場合、既存の組織/既存プロセスからなるべく独立したほうが早く進めるしいいものができると思います。 • 船頭多くして船山に登る → 「妥協の産物としての無難な駄作」ができやすくなる。 • "論議するだけなら議員は大勢いる。実行が問題になるとだれもいなくなる。" -- ジャン・ド・ラ・フォンテーヌ • いいチーム → いいサービス • リリース直前の「開発佳境(サバイバルモード)」の時期とか、状況によっては指揮命令型のリーダーにならないといけない。 そのような場面で影響力を即座に十分に発揮できるよう、兼務ではなくチーム専属にしておく。 • 「クラウドサービスを開発した経験があるかどうか」は、チームメンバーを選ぶ上でとても大切な基準。 ※キャンペーンサイトやコーポレートサイトのWeb制作案件とは設計の着眼点や開発のプロセスが違う。 • エッジケース < マイナーケース <<< メジャーケース • 優先順位を決めること、その理由を説明することはプロダクトマネージャーのとても大事な仕事。 • マイナーなユースケース(Nice to have)の対応よりも、メジャーなユースケース(Need to have)の磨き込みに力を注ぐ。 • "どんな天才でも、細部に没頭しすぎる悪癖からは逃れられない。" -- Levy の 8 番目の法則『新装版 達人プログラマー』P.165 • ドキュメントをつぶさに読む、日々のSlackを追いかける。 • チームメンバーとの認識の違いは、自分が思っている以上に大きいと心掛けておくのがいいと思います。 • “欠陥のある原料は価値の最も低い段階で拒否すること” ※出典: 『HIGH OUTPUT MANAGEMENT』 P.74 • 作ることよりも売ることの方がむずかしい。 • プロダクトマネージャーの最大の敵は己の飽き。情熱を燃やせなくなったら後任を探して引き継ぐ。 最後に
54. 日本からもっと多く、 いいクラウドサービスが生まれることを願って。 Developer — 秋月 秀樹 Product Manager — 岡本 亨 Green Developer — 西村 祐樹 Prototype Engineer — 増田 茂樹