Handbook

Missionは、事業やプロダクトの根本的な「存在意義」を示します。現在形で表現されることが多く、顧客・社会・社員に対して、今何を提供しようとしているのか、意思決定や価値観の拠り所になるものです。 Our Mission 今、私たちは何のために存在するのか？ 私たちのミッションは 「開発者とユーザがひとつのチームとなる、共創型のCommunity-drivenな開発アプローチを普及させること」 です。 開発チームが製品を提供し、ユーザが製品を受容するという関係を、開発チームとユーザが一体となって製品を共創する関係に変化させます。多くの開発チームを、ユーザとのズレが起きにくいチームに変化させ、ユーザが本当に便利でクールと感じる、そんな製品を生み出すことを支援します。

Visionとは、ミッションを突き詰めた先にある実現したい世界や社会の姿のことです。未来形・理想形で表現され、社員や顧客が共感し、「この未来を一緒に目指したい」と思えるものであり、中長期の事業成長や戦略の軸になるものです。 Our Vision 将来、どんな世界を実現したいのか？ 私たちが実現したいビジョンは 「価値あるプロダクトが社会にあふれ、便利でクールなソフトウェアで満たされている世界」 です。

人間は、不完全で怠惰な生き物です。 一度決めたことに対し、徹底的に一貫した行動を取り続けるのはとてつもなく大変なことです。 この組織での活動は 「レンガを積み上げること」 に似ています。丁寧な仕事でレンガを積み続ければ、遥か空高くレンガの塔を築くことができます。しかし、もしレンガを雑に積んでしまうと、崩壊するか、これ以上積めない状況に陥るでしょう。 このページは、この組織で重視している仕事に対する姿勢や思想、哲学を記し、組織文化を定義します。この組織では、ここで定義された文化を徹底的に遵守します。 もし、文化を守れていない方を見つけたとき、この組織に所属する全ての方は、たとえ相手が組織の重鎮であろうとも、次のメッセージを送ることができます。 それは文化に反している。受け入れられない。 この組織では、「それは文化に反している」のメッセージを送ることを大変奨励します。組織文化の維持に努めた方、組織文化の衰退を止めた方を褒め称えていきます。 “変えないこと"と"変えてよいこと” 文化を言語化する手段として、この組織における “変えないこと"と"変えてよいこと” を定義していきます。 あなたの創造力と自主性をもって、存分に"変えてもよいこと"。組織が絶対に譲らない、あなたに守ってもらいたい"変えないこと"。 これら2つを明確に定義します。 変えないこと 1. 顧客への価値提供と体験の質に影響があるものは、徹底的に検討し、丁寧な仕事と戦略に基づいて行動する。誰もが納得でき、間違いなく良いと断言できなければ、受け入れられない。 全ての仕事に徹底や完璧さを求めるわけではありません。 顧客への価値提供と体験の質に影響があるものに限り、頭をフル回転させ、丁寧な仕事をしようということです。そして、この領域に関する意思決定や行動は、誰の目から見ても、間違いなく良いと断言できるものでなければなりません。 具体例 組織文化づくりの協力依頼 Aさん: Bさんにぜひ組織文化の土台をつくってほしい。協力してもらえないだろうか？ Bさん: いいですよ。GitLabの文化が非常に良いから、それを真似すれば良いと思います。 以前やったことやGitLabのHandbookで書かれていることを、そのままコピペすることになりそうだけど、それでいい？ Aさん: それは文化に反している。受け入れられない。 我々には我々の適したやり方があるはず。他人のプラクティスをそのまま流用して、最高の組織が作れると思えない。 組織文化の土台を築く仕事は、組織において最も重要な仕事の1つである。それをコピペで済ませようとしている姿勢が受け入れられない。 あなたのそのやり方で、本当に間違いなく最高の組織をつくれると断言できるのか？ 例えば、私が考えているのは、このCultureページのようなものだ。Bさんはどう思う？ 変えてよいこと 記載予定

このページでは、我々が取り組む課題の領域を定義します。最終的につくられるプロダクトがどんな課題を解決するのか、その課題は本当に市場に明確に存在し、痛みを伴うものなのか。Problem Discoveryとは、課題を発見し、検証するフェーズです。 課題の発見と仮説の立案 ペルソナの定義 課題仮説の検証 課題の仮説 ソフトウェアサービスを提供する開発チームの多くが、次の課題を抱えていると仮説を立てた。 開発チームの多くが、ユーザーのニーズや声をプロダクトに反映できておらず、お金が払われる、払われ続けるプロダクトに成長することができず、困っている。 開発チームとユーザーの繋がりや関係性、エンゲージメントが薄く、対話と分析が不足している。 この課題は、開発チームに次の問題を引き起こしている。 どの機能を実装するべきかを判断することができない 実装した機能がどのように使われているかを知ることができず、機能の改善案を考えることができない ユーザーが喜んで課金し、価格よりも価値を感じるプロダクトになれず、PMFを達成できない この課題を、以降の取り組みでの最上位の課題としていく。この課題の範囲を超えたものは、解決策やプロダクトに含まれることはない。 課題の仮説はここでは深堀りせず、Problem-Solution Fitのフェーズで深堀りしていく。 課題発見の過程 1. 大まかな市場性・課題の調査 はじめに、知人・友人の開発者に対し、どんな課題を抱えているかについて、市場性と課題のインタビューを行った。次の質問を行い、どんなことに普段困っているかを聞いた。 開発チームの仕事に満足しているか？ 開発チームでの仕事で、直近で強くストレスに感じた出来事を教えてくれますか？ 3名に確認し、どの方も仕事自体に満足していると回答した。 ストレスに感じた出来事についても回答を得たが、一貫性や共通点はなかった。この聞き方では、回答が発散してしまい、課題の分析につなげるのは難しいと感じた。 2. 自身の経験から課題の手がかりを考える 自分自身に対しても上記の質問を問いかけ、自己分析をしてみた。結果は次のとおり。 チームでの仕事に満足していない 自分が真剣に取り組み、時間と労力をかけて生み出した製品が全く使われないことにストレスを感じた（このとき、私は製品に対する大きな方針を決定できる立場ではなかった。エンジニアとして、自分ができる最大限のことをやっていたということ。） 原因を分析し、次の事項によって「時間と労力をかけて生み出した製品が全く使われない」状態になったと考えた。 構想初期や開発途中で、ユーザーに市場性の確認を徹底していない 3. 市場性・課題の再調査 特に日本において、ユーザーと会話する文化はあまり馴染みがない。ほとんどの開発チームは、ユーザーと深く会話していないのではないか？と、ここで考え始めた。 これを検証するため、市場性と課題のインタビューの設問内容を次に変更し、再度確認を行った。 最近、開発チームで「手間がかかる」「面倒だな」と感じた作業やプロセスはありますか？ 「本当にユーザーが求めているものを作れているか」という点について、あなたの感覚に近いものを選んでください。 プロダクトの方向性や意思決定について、チームで感じていることがあれば教えてください。 2名に確認し、次の情報を得ることができた。 スタートアップに所属する方は、ユーザーが求めるものを作れていることに自信を感じていると答えた。大企業に所属する方は、合っていると思うが確証はないと答えた。 スタートアップに所属する方であっても、機能が実際にどう使われているのかまでは把握しきれていない 2人とも「作る機能が明確に決まっており、迷うことがあまりない」と答えなかった この結果と自身の過去の経験から、開発チームとユーザーの間に何らかの課題があると考え、この課題を分析することにした。 4. ターゲットユーザーに到達することが難しい 課題分析をするため、先の2名以外の他の開発者からインタビューを伺うことにした。特に、友人・知人にいないスタートアップ・ベンチャー企業に所属する開発者にコンタクトをとろう考えた。 しかし、次の施策を試したが、ターゲットの開発者とつながることが全くできなかった。 XやLinkedinのソーシャルアカウントに対し、DMでFormの回答依頼を行う ほとんどの人がDM機能を無効にしている 直近に資金調達を行ったスタートアップ企業に、コーポレートサイトの問い合わせ経由でFormの回答依頼を行う 問い合わせページの本来の使い方ではない。倫理的にアウトか、目的外利用禁止の文言がある。 スタートアップが好きそうなテックイベントに参加し、懇親会で知り合いになり、インタビューを行う 自然な参加をすると、普通は連絡先交換まで至らない。 2-3回の参加が必要になる場合もある。コアユーザーになる確度が低く、時間のコストと見合っていない。 ここで、次の情報を得ることができた。 ユーザーとつながることに時間と労力がかかりすぎる 5. 開発チームとユーザーのつながりが薄い ターゲットユーザーに到達する他の施策として、次があると考えた。 QiitaとZennに投稿を行い、開発チームとユーザーの間に課題を感じる人とつながる。投稿の内容に、Slackコミュニティへの案内を記載し、密につながる環境をつくる。 ターゲットユーザーが集まりそうなイベントを主催する。集まったユーザーにコンタクトをとり、コミュニティメンバーに誘い込む。 Slackコミュニティづくりを試していると、次に気づくことができた。 呼び込むまでは可能かもしれないが、持続的に密で熱意のあるつながりを維持するには、多くの工夫が必要 協力してくれる人に「自分事感」を与え、ともに製品をつくるように感じさせる運用が必要 協力してくれる人にインセンティブを与える仕組みが必要 Slackを普段使わない人であれば、LINEで別途通知するなどの工夫が必要 みんなが活発に意見を出せるように、場を回すような運用が必要 参加者が増えても、誰でも気軽に発言できるように、心理的安全性の確保が必要 ユーザーとつながることに時間と労力がかかるが、つながったあとも大変な労力がかかることを理解し始めた。開発チームがユーザーに便利でクールな製品を生み出すには、ユーザーの声が必須である。しかし、ユーザーとつながることも、その後のつながりを維持することも実際はとても大変である。 ...

このページでは、我々が取り組む課題の解決策を定義します。課題の原因とはなにか、プロダクトにはどんな成果が必要か、課題に対する解決策とは何か、MVPで何から取り組むか。Problem-Solution Fitとは、課題の原因を分析し、解決策を定義するフェーズです。 課題の明確化 課題の構造分析 / 原因分析 成果の定義 解決策の条件定義 解決策案 MVP設計 課題と解決策の検証 課題の明確化 Problem Discoveryより、解決すべき課題は次と定義している。 開発チームの多くが、ユーザーのニーズや声をプロダクトに反映できておらず、お金が払われる、払われ続けるプロダクトに成長することができず、困っている。 開発チームとユーザーの繋がりや関係性が薄く、エンゲージメントが低い。ユーザーとの対話と分析が不足している。 課題の構造分析 / 原因分析 課題について、5-Why分析を行い、課題の構造と原因を明らかにする。次の課題に対し、なぜそれが起きているかを再帰的に言語化する。 開発チームの多くが、ユーザーのニーズや声をプロダクトに反映できておらず、お金が払われる、払われ続けるプロダクトに成長することができず、困っている。 🤔 なぜ、開発チームのプロダクトの多くが、お金が払われる、払われ続けるプロダクトに成長することができないのか？ 開発チームとユーザーの繋がりや関係性が薄く、エンゲージメントが低い。ユーザーについて得られる情報が乏しく、ユーザーのニーズや声をプロダクトに反映できていないから。 🤔 開発チームとユーザーとの関係性やエンゲージメントという観点において、なぜ、Problem Discovery, Problem-Solution fit~MVP検証, Solution-Product fit, Product-Market fit, SecondPMF以降がうまくいかないのか？ 分析方法の詳細を次に示す。 5-Why分析方法の詳細 概要 課題に対し、なぜその課題が発生したのか、その原因とは何かを問い続け、5回繰り返すことで分析する手法である。 ここでは5回にこだわらず、課題が起きる原因が抽象的になるか、自分が対処可能な範囲を超え始めたら、深堀りを終了することにしている。 5-Why分析の流れ 「なぜ、開発チームとユーザーの繋がりや関係性が薄く、エンゲージメントが低いのか」をプロダクトをつくるための課題発見から解決策案の定義、開発、リリース、改善、グロースまで、各開発フェーズごとに分析を行う。 Problem Discovery Problem-Solution fit ~ MVP Solution-Product fit Product-Market fit Second PMF以降 まずはある程度自身で課題を分析し、その後の解決策案と課題の検証にて、実際に市場で確認できた課題を色分けする。 市場で確認ができたと判断したソースを、その課題のリーフに記載する。 課題カテゴリの定義 課題カテゴリの定義 次の検討に活用するため、各課題をカテゴリで分けることにした。 解決策の成果定義、解決策の提案 最初期で取り組む課題、MVPでフォーカスする課題 解決すべき課題の重要度や優先順位の決定 心理的要因 感情・信頼・安心感・不安など、人の“気持ち”に起因する障壁。属人性が高く、再現性・定量化が難しい。 影響は非常に大きいが、言語化・認識されにくく、可視化されづらい。 初期フェーズでは「気まずさ・自信のなさ・恥ずかしさ」などがユーザー接点を妨げる。 だからこそ、心理的ハードルを下げる体験設計（ex. フォーム、Slack、アバター、非同期など）がSaaSの価値になりやすい。 MVPとの相性は中〜高である。 ...

このページでは、課題に対する解決策を具現化したプロダクトを定義します。 Solution-Product fitは、解決策が実際の製品として効果的に具体化され、その課題を確実に解決できる状態に到達するフェーズです。 目指すプロダクトの状態 課題に対する解決策を具現化したプロダクトにおいて、どの観点がSolution-Product fitに繋がるかを次のように定めた。 我々は、下記の観点を満たすプロダクトを開発していく。 これらの観点は、開発でのレビューや確認、検証で利用される。 ユーザー体験（UX） ユーザー体験（UX）の観点 直感的な操作: UIが分かりやすく、学習コストが低い シームレスなフロー: ユーザーが迷うことなく目的を達成できる エラー回避とリカバリー: ユーザーが間違えたときに簡単に修正できる設計 レスポンスの速さ: 即時のフィードバックがあり、待ち時間がストレスにならない デザインの一貫性: UIが統一され、ブランドの信頼感を与える モバイル・PC間のシームレスな移行: デバイスに依存しない使い心地 問題解決能力 問題解決能力の観点 強力な課題解決: Problem-Solution Fitで定義した解決策の条件を完全に満たしている 結果の即時性: 効果がすぐに実感できる（例：パフォーマンス改善や作業時間短縮） 持続的な価値: 一時的な効果にとどまらず、長期的な価値を提供できる 理想を達成する自己実現: ユーザーが期待した以上の成果を提供し、「これが欲しかった！」と思わせる 成果と効果測定 成果と効果測定の観点 KPIの達成: 具体的な成果が定義されており、それが実際に測定可能 成功体験: ユーザーがプロダクトを使うことで成功を感じられる ROIの向上: ユーザーが製品に対する投資のリターンを明確に感じる 定量的な改善: DAU/MAU、LTV（ライフタイムバリュー）、コンバージョン率などの向上 継続性とエンゲージメント 継続性とエンゲージメントの観点 習慣化のしやすさ: 定期的に使用されるよう設計されている エンゲージメント: ユーザーが定期的に戻ってくる要素がある（通知、定期レポート） ネットワーク効果: 他のユーザーが増えるほど価値が高まる構造 リテンション: 長期的にユーザーが離れにくい製品設計 コスト・効率 コスト・効率の観点 時間効率: 手間がかからず、迅速に結果を得られる 運用コスト: メンテナンスやサポートが最小限で済む 開発コスト: 無駄な機能がなく、最小限のリソースで運営可能 スケーラビリティ: 成長に伴う負荷に耐えられる設計 技術とセキュリティ 技術とセキュリティの観点 信頼性: バグが少なく、安定して動作する スケーラビリティ: 高トラフィックにも耐えられる設計 セキュリティ: データ漏洩や不正アクセスに対する防御が十分である パフォーマンス: 処理速度が速く、応答性が高い ...