HEISO · 進め方
Heisoのプロジェクト管理
すべてが
見えて、変えられる。
業務フローを分析し、モックアップで確認してから、小さなバッチで開発します。要件を最初から全部決める必要はありません。
ヒアリング
プロセス分析
モックアップ
段階的開発
リリース・改善
なぜアプローチを変えるのか
多くのソフトウェアプロジェクトは、
完成してから「求めていたものと違う」と気づく
要件を最初に固めてしまい、完成まで何も見えないことが原因です。
従来の方法
最初にすべて確定
何十ページもの要件仕様書を先に作成
し、画面を見ずに承認を求められる
数ヶ月間の開発期間中
、顧客は進捗を確認できない
最終的な検収で初めて完成品を確認
し、変更には追加予算と納期が必要となる
結果：
仕様書どおりにはできても、現場で毎日使えるとは限りません。
Heisoの方法
確認しながら調整
既存のプロセスを明確に可視化
し、真のボトルネックを見つけ出す
最初にモックアップを作成
し、画面が確定してからコーディングを開始する
要件を分けて提示し、分けて開発
し、各バッチが完成次第すぐ試せる
結果：
各ステップが見えるので、方向違いを早めに直せます。
プロジェクト管理プロセス
5つのステップ、すべてに具体的な成果物
各フェーズの終わりに、見て議論できる成果物が残ります。
成果物
要件ヒアリング
ビジネス目標・ユーザー・今のツールを把握します。
ヒアリング記録と初期スコープ
プロセス分析
現状のフローを描き、ボトルネックを見つけます。
現状／改善後フロー図
例を見る ↓
モックアップ
クリックできる画面で議論・修正します。
操作可能なインタラクティブプロトタイプ
例を見る ↓
段階的開発
小さなバッチに分け、毎回使える機能を納品します。
各バッチごとの利用可能なバージョン
進め方を見る ↓
リリースと最適化
実際の利用状況をもとに改善を続けます。
リリース済みシステムと継続的なイテレーション
ステップ 02 · プロセス分析
まず業務を理解し、
それからどんなシステムを作るかを考える
今の業務の流れを図にし、本当に直すべき点を一緒に見つけます。
誰が担当するか
各ステップの担当と引き継ぎ先
何を使って行うか
Excel、メール、LINE、紙など、データのありか
どこで滞っているか
時間がかかり、ミスが多い工程
購入申請プロセス
現状 AS-IS
社員が紙の申請書に記入
紙の申請書を回して上司が承認
平均1～2日待ち
購買担当者が手動でExcelに整理
時間がかかる・ミスが起きやすい
申請者にメールで通知
改善後 TO-BE
オンラインで申請を記入
上司がスマホで承認
リアルタイム通知
データ自動集計
手動入力不要
申請者に進捗をリアルタイム通知
例示であり、実際の内容は各プロジェクトのヒアリング結果に基づきます。
ステップ 03 · モックアップ
まず画面を見て、
作るかどうかはそれから決める
コードを書く前にクリックできる試作品を作り、納得いくまで一緒に修正します。
想像しなくていい
仕様書を読むより、触ればすぐわかる
問題を早期に発見
画面の修正はコードの修正よりずっと安い
内部での認識合わせが容易
全員が同じ画面を見て話せる
お客様からのコメント
ここに「営業担当で絞り込み」機能を追加できますか？
ステータス欄に「書類不備待ち」を追加したい
ステップ 04 · 段階的開発
要件は少しずつ出せばいい。
最初から全部決める必要はありません
必要なことは使ってみて初めて見えてきます。だから小さなバッチで作り、途中で調整や一時停止もできます。
要件を提示
思いついたことを何でも提示してください。一言でも構いません。
評価と優先順位付け
各項目に時間と費用を見積もり、このバッチで何から行うかを決定
開発と納品
小規模な実装を行い、完了後すぐに使用可能にする
試用とフィードバック
使用後、次のバッチの要件が自然と見えてくる
一つのバッチが完了したら、Aに戻る
システムがバッチごとに育っていく流れ
例
第1バッチ
コアプロセス
をまずリリースし、チームで使用を開始
第2バッチ
フィードバックに基づき強化
：レポート、通知、権限
第3バッチ
範囲の拡大
：既存システムとの連携、他部門への展開
要件は最初から全部決めなくていい。
見て、使ってから、次を決める。
HEISOのプロジェクト管理原則
分業
各フェーズでお客様にお願いすることは多くありません
お客様は業務の流れを教えてください。設計・開発・テストはHeisoが担当します。
フェーズ
お客様にやっていただくこと
Heisoが担当すること
要件ヒアリング
ビジネス目標、現状、課題を共有（約1〜2時間）
ヒアリング内容を整理し、初期スコープを提案
プロセス分析
フロー図が実際の状況と一致しているか確認
現状および改善後のフロー図を作成し、ボトルネックを特定
モックアップ
プロトタイプを操作し、画面上に意見を残す
画面をデザインし、フィードバックに基づいて確定するまで修正
段階的開発
各バッチで要件を提示し、一緒に優先順位を決定
開発、テスト、定期的な進捗デモンストレーション
リリースと最適化
実際に使用し、問題点や新しいアイデアを報告
デプロイ、運用、継続的な改善
費用
要件はバッチごとに先にお見積もり、
ご承認後に着手します
各バッチは着手前にお見積もり。完了後、次に進むかを決められます。
承認後
リリース後
フェーズ1
初期企画
要件ヒアリング＋プロセス分析＋モックアッププロトタイプ
[NT$__]
固定価格
フロー図と操作可能なプロトタイプを成果物として提供
開発に進む場合、最初のバッチ費用から相殺可能
終了時に全体の分割提案と予算範囲を提供
フェーズ2
段階的開発
要件に応じて分割し、各バッチを個別に見積もり
バッチごとに見積もり
要件の範囲による
要件提示後、[1～2]営業日以内に見積もり回答
作業開始前に、このバッチの範囲、金額、納期を確認
開発中に発生した新しい要件は、次バッチとして別途リストアップ
一つのバッチが完了すれば検収・利用開始可能
フェーズ3
運用・保守
ホスティング、監視、日常的な微調整
[NT$__]
／月
毎月[__]時間の調整枠を含む
大きな新機能は新しいバッチとして別途お見積もり
例：
コア機能を3バッチで約[NT$__]～[NT$__]。まず1バッチ目から始められます。
要件がずっと増え続けたら、費用が制御不能になりませんか？
なりません。各バッチは着手前に金額を確定し、新しい要件は次のバッチとして別途お見積もりします。
途中で一時停止したい場合は可能ですか？
はい。各バッチの完了後に停止でき、納品済みの機能はそのまま使えます。
事前に総予算を知ることはできますか？
はい。初期企画の最後に、分割案と予算の目安をお出しします。
リリース後にバグが見つかった場合はどうなりますか？
納品した機能には[30]日間の保証があり、期間内の修正は無料です。
この進め方のメリット
小さく進めるほうが、一度に大きく作るより安全です
リスクの低減
小さく作るので、方向のずれを早く直せます。
進捗の可視化
毎回使える成果物があり、進捗が一目でわかります。
予算の有効活用
価値の高い機能から作るので、無駄な開発がありません。
始める準備はできましたか？
AI時代のデジタル変革パートナーとして、Heisoがお手伝いします
お問い合わせ
https://www.heiso.io/contact