How we build
Hydruptは、お客様のサービスをつくる受託開発と、
自分たちのサービスを育てる自社サービス開発の、二つに取り組んでいます。
立場は違っても、良いソフトウェアをつくるための考え方は同じです。
このページは、私たちが大切にしている原則と、日々の進め方をまとめたものです。
受託開発
成果の主語はお客様です。お客様の事業目標を自分たちの目標として捉え、限られた予算と期間の中で、最も大きな価値を届けることを目指します。
自社サービス
成果の主語は自分たちです。何をつくるかから自分たちで決め、市場とユーザーの反応に責任を持ちながら、長く育てていきます。
同じチーム、同じ進め方、同じ品質基準。違うのは「誰のためにつくるか」だけです。
原則
- 01
まず速く、それから強く
最初から完璧を目指すより、小さく形にして早く手に取ってもらうことを優先します。実際に使われた反応から学び、その学びをもとに堅牢に育てていきます。速さは手を抜くことではなく、学ぶまでの距離を縮めることです。
- 受託開発では
- 要件をすべて固めてから作り始めるのではなく、早い段階で動く画面をお見せし、触りながら一緒に仕様を詰めていきます。
- 自社サービスでは
- 仮説を最小限の機能で世に出し、利用状況とユーザーの声をもとに、伸ばす機能と手放す機能を判断します。
- 02
機能ではなく、課題から始める
「何を作るか」の前に「誰の、どんな課題を解くのか」を言葉にします。課題と目指す成果がはっきりしていれば、作るものは自然と絞られ、判断に迷ったときの拠り所になります。
- 受託開発では
- 依頼された機能の背景にある事業上の目的を確認し、より小さく効果的な解決策があれば率直にご提案します。
- 自社サービスでは
- 自分たちが欲しいものではなく、ユーザーが本当に困っていることを起点に、解く価値のある課題を選びます。
- 03
作り手が、使い手のそばにいる
要望が何人もの手を経て伝わるほど、本来の意図は薄れていきます。実際に手を動かすエンジニアやデザイナーが、使う人の声を直接聞き、現場を知ったうえでつくることを大切にしています。
- 受託開発では
- 担当者の方やその先のエンドユーザーと、開発メンバーが直接やり取りできる体制を基本にしています。
- 自社サービスでは
- 自分たち自身がプロダクトのユーザーになり、問い合わせやフィードバックにも開発メンバーが目を通します。
- 04
シンプルを先に
複雑さは、必要になってから足せば十分です。最初は最も素直な構成と最小限の機能で始め、本当に必要だと分かったものだけを加えていきます。シンプルなものは、速く作れて、長く保てます。
- 受託開発では
- 将来の「念のため」の機能より、今いちばん効く機能に予算と時間を集中させることをご提案します。
- 自社サービスでは
- 機能を増やすことより、迷わず使えることを優先し、足す前に削れないかを考えます。
- 05
リリースは、スタートライン
ソフトウェアは公開してからが本番です。運用しながら改善を続けられるよう、読みやすいコード、自動化されたテスト、分かりやすいドキュメントを、最初から開発の一部として扱います。
- 受託開発では
- 納品して終わりではなく、運用や保守、将来の担当者への引き継ぎまで見据えた形でお渡しします。
- 自社サービスでは
- 長く運営するサービスだからこそ、目先の速さのために将来の変更を難しくする近道は選びません。
- 06
二つの現場で、互いに学ぶ
受託開発と自社サービス開発は、同じチームが同じ方法で取り組んでいます。片方で得た経験は、もう片方を強くします。この往復こそが、Hydruptの開発力の源泉です。
- 受託開発では
- 自社サービスで実際に試し、運用してきたAI技術や開発手法を、確かな知見としてお客様のプロジェクトに活かします。
- 自社サービスでは
- 受託開発を通じて触れるさまざまな業界の業務や課題が、新しいサービスの着想と、現実に根ざした設計につながります。
実践
原則を日々の仕事に落とし込むための、具体的な進め方です。
短いサイクルで回す
1〜2週間を一つの区切りとして、計画・開発・振り返りを繰り返します。サイクルごとに動くものを確認し、次に取り組むことを決め直します。
書いてから作る
大きな開発に入る前に、課題・目指す成果・やらないことを短い文書にまとめます。長い仕様書ではなく、関わる全員が同じ方向を向くための一枚です。
動くもので確認する
資料や口頭の説明よりも、実際に触れるプレビュー環境で確認していただきます。画面を見ながら話すことで、認識のずれを早く小さく解消できます。
品質を工程に組み込む
コードレビューと自動テストを日々の開発に組み込み、最後にまとめて確認するのではなく、作りながら品質を確かめます。
やらないことを決める
優先順位は「何をやるか」と同じくらい「何をやらないか」で決まります。範囲を明確にし、変更が生じたときは影響と引き換えに何を後回しにするかを一緒に決めます。
数字と声の両方で判断する
アクセスや利用状況などの数字と、ユーザーやお客様から直接聞いた声の両方を見て判断します。どちらか一方だけでは、見誤ることがあるからです。
AIを道具として使いこなす
設計、実装、テスト、ドキュメント作成まで、AIを積極的に取り入れて開発の速度と質を高めています。ただし最終的な判断と責任は、常に人が持ちます。
引き継げる形で残す
判断の理由や仕組みを記録に残し、特定の誰かがいなくても開発を続けられる状態を保ちます。それは、お客様にとっても私たち自身にとっても安心につながります。
Speed first, then powerful
すばやく生み出し、着実に育てる。
この進め方で、一緒につくりませんか。