記事

記事 · 3

プロダクト、ソフトウェア開発、その間にある判断についての実践的な記事。

古いシステムが実際に対応する入出力と、変更してよい担当者を調べます。新APIは古い仕組みを隠せますが、不安定な情報源や不明な業務ルールを消すことはできません。移行中も既存の運用を理解できる状態を保ちます。

表が大きいだけでは、専用アプリを作る理由になりません。どの記録が最新か、誰が変更してよいか、次に何をするかが分からなくなったときが見直しの出発点です。複雑な計算と複雑な業務の流れは別の問題です。日々の処理を移しても、分析には表を使い続けられます。

承認の目的は、通知を速く送ることだけではなく、判断をたどれるようにすることです。対象、承認者が見た版、承認後の処理を決めます。後から内容が変われば再承認が必要かもしれません。そうしないと、誰も認めていない内容に承認履歴が付いてしまいます。

自動化の準備が整うのは、作成が面倒になった時点ではなく、定義を再現できる時点です。誰が何を判断する資料か、各指標の意味、データがそろう時刻を決めます。部門ごとに数字の意味が違うままでは、グラフが早く出ても役に立ちません。

予約は時刻だけでなく、資源、所要時間、条件を約束するものです。画面を選ぶ前に約束の中身を書きます。カレンダー表示よりも、準備、清掃、担当者の資格、確定後の変更が難所になりがちです。

ポータルが反復作業を減らすのは、顧客が結果の説明を求めずに用事を終えられる場合です。意味や更新状況が分からない状態表示だけでは足りません。繰り返される質問や書類請求から始め、信頼できる記録で何を答えられるか整理します。

ストアにアイコンを置きたいという希望ではなく、必ず成立させたい作業から配信方式を選びます。誰が、どの端末を、どんな通信環境で使うのでしょうか。見積をたまに開く顧客と地下で働く技術者では、同じスマートフォン向けでも条件が違います。

まず公開情報と非公開の作業を分けます。製品説明、公開一覧、記事は検索で見つけてもらう対象になり得ますが、顧客画面や個人記録にはアクセス制御が必要です。すべてをサーバーで描画しても、公開するURLや最初の応答内容は別途決めなければなりません。

多言語製品では、内容、言語、利用者の希望を安定して結び付ける必要があります。タイトルが変わっても残るコンテンツIDから始めます。URLの言葉が違っても翻訳記事は同じ記事です。この区別があれば、ナビゲーション、言語切替、検索用情報で同じページを示せます。

見積フォームは仕様書を書かせる場所ではなく、役に立つ返事に必要な背景を集める場所です。依頼が対応範囲に合うか、誰が確認するか、何を相談するかという次の判断から考えます。必須項目には、その判断を助ける理由が必要です。

業務画面の役割は、仕事に気づき、理解し、処理できるようにすることです。グラフを集める前に、その役割で繰り返し行う判断を定めます。配車担当には会社全体の集計より、優先順の作業列と例外表示が必要かもしれません。

パフォーマンス予算は見栄えのよい点数ではなく、特定の利用体験に対する境界です。比較的低性能なスマートフォンで説明ページを開く、業務一覧を絞り込む、相談を送信するなど、重要な作業と端末から始めます。上限を決める前に現状を測り、測定条件も記録します。

役立つものを、一緒に。

最初のプロダクト、複雑な業務、見直したいソフトウェア。現在の状況をお聞かせください。