本当に欲しかったものが、できあがった。
タスクは200個を超えた。それでも、ひとつも落ちなかった。
仕様書ではなく、動くものから始めた
AIの力で、作り直しがすぐできる。この案件では、それを前提に動かすことにしました。
最初に顧客へ渡したのは、完成品ではありませんでした。「実際に動くたたき台」です。細かい仕様を言葉で固めきる前に、触れるものを作って渡す。顧客が操作して、「ここはこうしてほしい」という感触を得てから、開発が動く。
仕様を先に固めてから作る、という順序を逆にしました。先に作って、触れた後で仕様が決まっていく。欲しいものは、最初の打ち合わせでは言葉にならない。実物を前にして、はじめて「これだ」が出てくるものです。
仕様は、触りながら見つかっていきました。
完成品ではなく「触れるたたき台」から始まる
なぜ、速い開発ほど崩れやすいのか
速さは手に入った。
合意が、追いつかなかった。
AIの力で開発が速くなりました。たたき台をすぐ作り、触って直し、また触る。この反復は、本来なら最良の開発スタイルです。
ところが、現場でよく起きることがあります。反復が速くなるほど、「誰が・何を・どこまで」が散らばっていく。フィードバックは会話に消え、確認はメールに埋まり、修正依頼はチャットに流れる。気づいたら「あの件、どうなってたっけ」が増えている。
速さは手に入った。でも、合意と記録が追いつかなかった。これが、反復型の開発が現場で崩れやすい、本当の理由です。反復の考え方自体は正しい。ただ、「速く作ること」と「正確に伝わること」は、別の課題でした。
顧客が触って、気づいたことをそのまま書く
顧客が実際に動くたたき台を触るたびに、「もっとこうしたい」が生まれました。それをどこに書くか、が次の問いでした。
メールで送る。チャットに流す。ミーティングで伝える。どれも「言った」は残りますが、「何を」「いつまでに」「どうなった」を追いかけるのが大変になります。反復が速くなるほど、この混乱も速くなります。
この案件では、顧客の気づきを、そのままPaqutにタスクとして書いてもらうことにしました。確認が必要なときは、そのタスクの中でやり取りします。会話を別の場所に持ち出さない。疑問が解消されたら、タスクを閉じる。
顧客の「もっとこうしたい」が、タスクとして残り続けました。
「言った・言わない」も、「あの返答どこだっけ」も、起きませんでした。タスクは「作業指示」ではなく、「ひとつの問いが解けていく単位」になっていました。相談し、タスク内で会話し、完了する。このサイクルが、開発を前に進めました。
触る → 気づく → タスクに書く → 解決する。このサイクルが回り続けた
200個の「もっとこうしたい」が、全部システムになった
顧客が触るたびに、タスクが増えました。操作して感じた違和感、もっとこうなればという要望、動きの細かい調整。それが積み重なって、200個を超えました。
反復を重ねるうちに、システムは本当に求められる形になっていきました。最初の打ち合わせでは言葉にならなかったものが、触りながら出てきた。その声が、ひとつも落ちなかった。
漏れゼロは、顧客の声をひとつも取りこぼさなかった、ということでした。
漏れがなかったのは、管理が上手だったからではありません。顧客が書いたことが、全部タスクとして残り続けたからです。タスクが消えない場所にあったから、誰も忘れられなかった。
200個の声が、全部システムになった
この話は、システム開発だけではない
デザイン、LP、UI。言葉で完成イメージを固めきれず、実物を前にして「ここをこうしたい」がはじめて出てくる仕事は、たくさんあります。そういう仕事ほど、反復のたびに要望が散らばりやすい。開発側・デザイン側・クライアント側が越境するほど、「誰かが言ったこと」が行方不明になりやすい。
見て・触って、はじめて要望が出る。この構造は、システム開発もWebデザインも、外注・クライアント・制作者が越境するすべての仕事に共通します。あなたの仕事でも同じことが起きているなら、Paqutが同じように機能するかもしれません。
自分たちが作るものを、
自分たちが一番使う。
オルアナはPaqutの開発元です。自社で作ったツールを、自社の案件で日常的に使っています。この案件もそのひとつでした。使いながら気づいた改善点が、Paqutのプロダクトに返っていきます。
正直に書くと、Paqutだけでシステムはできません。定期的な打ち合わせもしました。ただ、「やるべきことが常に見えていた」から、その場のキャッチボールがかつてないほどスムーズでした。打ち合わせは確認作業ではなく、次の一手を考える場になりました。
関係が、開発を通じて深まりました。
たたき台を作る。顧客が「もっとこうしたい」を伝える。すぐ直す。
このサイクルを回せる人が、
いいものを作れます。
AIの時代は、作る速さより、伝えて受け取る正確さが差になる。
タスクは、投げるものじゃない。一緒に運ぶものだ。
なぜPaqutはこう考えるのか →