本文へ移動
MEDITATION / 事業と富 / 製品と提供

製品と提供 · 事業と富

事業と富 · 製品と提供

事業と富 · 短章 5 件

短章 5 件

《試作画面の前に、使い方を明確にする》 早く画面を描くほど、かえって修正が増えるのはなぜか?

案件の最初から画面を描くと、皆は仕事が始まったと感じやすい。ボタン、色、配置があり、手に取って話せる。しかし画面が完全でも、その中の人が何を完了するのかは曖昧なままかもしれない。

まず誰が、いつ使い、この段階の後どこへ進むかを明らかにしたい。機能名は目次にすぎず、機能同士のつながりが使えるかを決める。使い方への理解が異なるなら、細かく描くほど後で覆す部分も増えうる。

設計前に具体的な場面を一度たどれる。各人が何を出し、何を見られ、最後に何を得るかを明らかにする。不一致はその場で記録する。重要な問いを確定してから画面にすれば、対話に共通の根拠ができる。

もちろん描いて初めて見える考えもある。その場合は粗い案で問題を探し、完成案に急がない。準備の程度は次に解く必要による。設計を要件確認の道具にするのと、未確認の設計を開発指示にするのとでは、影響が違う。

事業と富 · 製品と提供 固定リンク
《プログラムを変える前に、問題を分ける》 使いにくいと言われたら、すぐプログラムを変えるべきか?

「使いにくい」は多くを指す。操作がわからない、不具合に遭った、流れが悪い、新機能がほしい場合がある。すべてを修正一覧に入れればチームはすぐ忙しくなるが、同種の問題を解いているとは限らない。

問題に遭ったら、まず種類を分けたい。操作に不慣れなら説明や研修、約束した機能が動かないなら修復、使用過程が不合理なら設計点検、新しい考えなら要件の再協議が必要だ。処理が違えば、参加者と完了基準も違う。

報告では何をし、何を期待し、何が実際に起きたかをできるだけ明示する。再現できる現象を残し、関係者に確認してもらう。それで使いやすいかから、具体的な問題箇所へ進み、変更が元の使い方に影響するかも判断しやすい。

分類は修復の代わりでも遅延の理由でもない。明確な問題は進め、不明な部分は早く確認する。特に全問題を利用者の不慣れにしてはいけない。それでは製品が反応を失う。分けるのは遠回りを減らし、解くべきことを処理するためだ。

事業と富 · 製品と提供 固定リンク
《業務の流れに沿ってテストする》 各ボタンは押せるのに、実際に使うと問題が出るのはなぜか?

個々の機能が正常でも、全体の仕事を終えられないことがある。資料を提出できても次の人が受け取れるとは限らず、注文を作れても後の処理が決まるとは限らない。画面だけのテストは、画面間、人間同士、状態間の問題を見逃しやすい。

私は業務全体を一度通すことを重視する。実際の利用者の立場で、現実に近いデータを用い、開始、処理中、終了まで進む。誰が操作し、待ち、問題に対処するかを同じ流れで見る。機能の存在と業務の完了は別々に確かめる必要がある。

テストも開発とともに進められる。できた部分を調べ、接続できる流れをつなぎ、問題を記録して返す。全部終わって初めて試すと、前の誤解が最後に集中し、早く調整できたことまで慌ただしくなる。

不完全な版を全員へ出してよいという意味ではない。準備不足なら明確な範囲で見本データを使い、未完了の段階を把握して試せる。段階的テストで早く問題を見つけても、最終検収は約束した完全な用途に戻る。画面での判断を少し減らし、出来事をたどることを増やそう。

事業と富 · 製品と提供 固定リンク
《機能を一つ減らすほうが、公開に近づくこともある》 要件を充実させるほど、なぜ利用可能な製品から遠ざかることがあるのか?

製品の議論では案が増えやすい。誰もが理のある機能を足せて、一覧でも余分に見えない。しかし実際には設計、開発、テスト、保守を誰かが担う。それが重なると、製品はいつまでも「あと少し」にとどまる。

今解く問題へ戻りたい。その機能なしでも主な流れを完了できるか。実際に起きた問題か、将来ありそうだと想像する問題か。なくても主用途を果たせるなら記録し、使用上の明確な反応を得てから判断できる。

削減にも理由を伝える。何を残し、何を延期し、なぜそうするかを参加者に知らせる。完成部分には修正課題を、未着手部分には本当に不足する機能を挙げる。分けてこそ、次は既存製品の修復か、範囲拡大かがわかる。

少なく作ることは基本品質を下げることではなく、進度を理由に重要な流れを未完にしてはいけない。今の段階に必要な完全性は守る。実使用に影響する点に力を注ぐほうが、豊かに見える機能を増やすより、渡せる成果に近づくこともある。

事業と富 · 製品と提供 固定リンク
《製品更新は、自分たちの業務変化から見る》 同業者が機能を増やしたら、自分たちも追うべきか?

同業の新機能は調べる必要がある。しかしなぜ作り、誰に向け、どの業務に合わせるかは、すべて知るとは限らない。新ボタンだけを見て急いで足せば、自社製品は同業機能の寄せ集めになりかねない。

更新は自分たちの使用過程から始めたい。業務は変わったか、顧客が繰り返す問題は何か、流れのどこが悪いか。その後、外の製品が似た問題をどう扱うかを見る。それで得るのは比較できる方法であり、追うべき名前ではない。

新機能は既存の流れとの接続も調べる。誰が使い、何の資料が要り、終えたら誰に影響するか。不明なまま数を増やすと難しさも増えうる。運営上の実際の必要が明確なら、技術更新に安定した方向ができる。

外の革新が未発見の需要を教えることもある。具体的な場面で理解してから採用の価値を判断できる。同業を見つつ、自分の選択も保つ。製品には継続的な変化が必要だが、毎回、利用者が何をよりよくできるのかに答えたい。

事業と富 · 製品と提供 固定リンク
SEARCH