ボイスファーストのワークフロー: 私たちのボイスファースト勤務日

私は Loqua.ai 創業者の Shuran です。これは私たちのボイスファーストワークフローの正直なバージョンです。どこで時間を節約し、どこで失敗し、代わりに何をするか。生産性を演じるのが目的ではありません。思考と仕事を前進させる成果物の距離を縮めるのが目的です。このような 1 日の終わりには、タイピング対話の問いはほとんど見えなくなっています。私が気づくのは仕事そのものです。

8 時の受信箱

Spark Mail と Slack から始めます。返信はほとんど意図とトーンなので、音声がよく機能します。乱雑な答えをディクテーションし、Loqua がフィラーを取り除き、アプリ認識レイヤーが Slack の出力をメールよりも短く保ちます。

受信箱ブロックは通常 15〜20 分かかります。返信の約 2/3 はディクテーション、残りは厳密な言葉遣い、リンクのリスト、繊細な説明が必要なのでタイプ。割合はルールではありません。あるツールに別のツールの仕事をさせるのをやめると、朝はそうなるというだけです。

音声が失敗する場面: 公共空間での機密スレッド。カフェにいてメッセージに機密コンテキストが含まれていれば、タイプします。ボイスファーストはプライバシーセカンドという意味ではありません。

スタンドアップ

スタンドアップでは三つのスロットを話します。出荷、今日、ブロッカー。これは構造が繰り返され内容が変わるので、日々の音声入力ワークフローパターンで最もリターンの高いものの一つです。

コツはまとまりなく話さないこと。スロット名を声に出して言います。Loqua がそれを構造として使います。スタンドアップ自体は書くのに 30 秒くらい、チームの残りが投稿したものを読むのにもう 1 分。音声は個別のスタンドアップでは多くの時間を節約しません。それを後回しにするコストを節約します。それが以前は 1 日の大きな足かせでした。

コードレビュー

コードレビューは混合です。音声は懸念の説明に優れており、キーボードは行単位の精度に優れています。レビューサマリーと高レベルコメントをディクテーションし、正確なファイルナビゲーションにはマウスとキーボードを使います。

良い音声レビューコメントは、どの行が間違っているかだけでなく、なぜその問題が重要かを言います。例: 「このキャッシュキーはロケールを無視しているので、中国語と英語の結果が衝突する可能性があります。ロケールをキーに含めて、リグレッションテストを追加できますか?」コードを読みながらタイプするより、話す方がはるかに簡単です。

仕様ドラフト

仕様ドラフトはボイスファーストワークフローが思考に最も近く感じる場面です。ゴール、ノンゴール、ユーザーフロー、エッジケース、受け入れ基準をディクテーションします。次にキーボードで見出しを編集します。大きな仕様には Obsidian で始めます。実装タスクには、クリーンアップ後のバージョンを Claude Code または Cursor に移動します。

最初のディクテーションされたドラフトが出荷する仕様であることはまれです。それはキーボード編集を明確にする足場です。私が学び直し続けるコツは、ディクテーションしたバージョンの方が欠けているセクションをタイプした outline よりも速く表面化させることです。なぜなら「受け入れ基準」と声に出して言うと、少なくとも一つの基準を続けさせられるからです。

Slack スレッド

Slack はトーンが重要な場所です。クリーンアップモデルが書き起こしのみだと、音声は素っ気なく聞こえることがあります。Loqua の宛先フォーマットは返信を短く保ちつつ冷たくしません。送信前にはまだ読みます。音声は判断を加速すべきで、置き換えるべきではありません。

学ぶのに時間がかかったパターン: 効率的なバージョンではなく、暖かいバージョンをディクテーションする。Slack は最初の文が相手を認め、二つ目の文が要点に達すると読みやすいです。タイプした返信は最初の文をスキップしがちです。ディクテーションしたものは通常それを保持し、スレッドはそれによってより健康的になります。

音声が失敗する場面: スレッドが慎重な引用や複数のリンクを必要とするとき。それらはタイプします。ハイブリッドルールはシンプル。議論には音声、参照にはキーボード。

1 日の終わりのジャーナル

1 日の終わりに、驚いたことをディクテーションします。これはステータスアップデートではありません。記憶捕捉です。考えを変えたこと、思っていたよりも難しかったこと、明日忘れてはいけないこと。Obsidian が宛先です。検索可能でリンク可能だからです。

典型的なジャーナルエントリは短い 3 段落で、約 5 分かかります。興味深いパターンは、最も価値のあるエントリが大きな決定ではなく小さな驚きについてのものだということです。大きな決定はとにかく書き留められます、しばしば複数回。小さな驚き — API がドキュメントが示唆したものと異なる形を返したこと、私のモデルと矛盾するユーザーコメント — は朝までに、捕まえていなければ消えるものです。

今日音声が機能しなかった場面

同じ日からの二つの例。一つ目、忙しいファイルでの密なコードリファクタ。エディタに名前変更計画をディクテーションしようとしましたが、可視コンテキストがリスナーの追従より速くスクロールしていて、モデルが一つの識別子を間違え続けました。タイピングに切り替えました。カーソルがコンテキスト安定化より速く動いていたので、音声は間違った道具でした。

二つ目、正しい返信が三文でゼロ形容詞の張り詰めた Slack スレッド。ディクテーションしましたが、クリーンアップが一つ礼儀的なヘッジを追加し、メッセージが私が望んだよりも柔らかく読まれてしまいました。手で書き直しました。教訓は、音声は暖かさには良くて意図的な冷たさには悪い、ということです。フラットなメッセージが必要なときは、タイプしてください。

スタック全体の詳細については、私たちの音声プロダクティビティスタックを参照してください。習慣の背後にある議論については、AI と一緒に考えるためにキーボードがなぜ間違った道具なのかを参照してください。私たちの Mac ワークフローを形作った外部リファレンスには Apple Dictation と Linear docs が含まれます。