おはようございます。まさきんです。
家のタスク管理で、ちょっとショックな数字を見ました。規約に書いてあったルールが、実際には半分しか守られていなかったんです。今回は、その数え方と直し方を残しておきます。
※記事公開時点の情報です。最新の条件は公式サイトでご確認ください。
- 「タスクには絵文字アイコンを付ける」と約1ヶ月前から規約に書いていた
- 未完了タスクを全部数えたら、164件中83件がアイコンなしだった
- 抜けていたのは、AIの自動起票の経路だった
- 対策は「入口で必須にする」と「毎朝少しずつ拾う安全網」の二重にした
- チェックしにくい属性ほど、守られているかどうか分からないまま残る
家のタスクはNotionとAIで回している
我が家のタスク管理は、Notionのデータベースでやっています。4人の子どもがいると、細かい用事が次々に出てきます。なので、1か所に集めておかないと回りません。
特徴的なのは、タスクの多くを僕が手で作っていないことです。AIの定期処理が、毎朝や毎晩に自動で起票しています。棚卸しも、定期処理がやってくれます。
朝の情報整理の仕組みは、朝のブリーフィングの記事に書きました。夜の家計チェックは、カード利用の自動チェックの記事で紹介しています。今回の話は、その裏側で動くタスクの起票の話です。
「アイコンを付ける」という規約
約1ヶ月前、運用ルールの文書に一行を足しました。「タスクには内容に合った絵文字アイコンを付ける」というものです。
理由は単純で、一覧で見たときに分かりやすいからです。買い物なのか学校なのか、お金なのか。アイコンがあると、文字を読む前に目に入ります。
AIの定期処理も、この文書を読んで動く前提でした。なので、書いた時点で守られるものだと思い込んでいました。
数えてみたら半分がアイコンなし
ある日、ふと気になって数えてみました。未完了のタスクを全件です。
結果は、164件のうち83件がアイコン未設定でした。ほぼ半分です。規約を書いてから1ヶ月ほどで、この状態でした。
正直、もう少し守られていると思っていました。一覧を眺めていても、半分が欠けているとは感じていなかったんです。見慣れた画面ほど、欠けに気づきにくいのかもしれません。
落ちていたのは自動起票の経路
中身を見ていくと、傾向ははっきりしていました。アイコンが無いのは、自動起票されたタスクに偏っていたんです。
つまり、規約は文書としては存在していました。ただ、タスクを作る処理の中には入っていなかったわけです。AIが毎回その一行を思い出してくれる保証は、どこにもありませんでした。
人でも同じことが起きると思います。マニュアルに書いてあっても、忙しい日は抜けます。書いたことと、実際に手が動くことは別物なんですね。
数えること自体が大変だった
今回いちばん手間取ったのは、実は数える作業でした。
Notionのデータベースは、いろいろな方法で中身を照会できます。ビューで一覧を見たり、SQL風の照会をかけたりです。行をまとめて取得する方法もあります。ところが、僕が試したどの方法でもアイコンの有無は返ってきませんでした。
結局、164件を1件ずつページとして取得して確かめました。手間もかかりました。AIの利用量も、かなり食いました。
| 確かめ方 | アイコンの有無 | 今回の印象 |
|---|---|---|
| ビュー経由の照会 | 返ってこなかった | 画面の目視は見落とす |
| SQL風の照会 | 返ってこなかった | 条件にも使えない |
| 行の一括取得 | 返ってこなかった | 件数は分かる |
| 1件ずつページ取得 | 分かる | 確実だが重い |
これは、僕の使っている照会の経路での話です。環境やツールによっては違うかもしれません。
とはいえ、教訓としては大きかったと感じています。「簡単に数えられない属性は、守られているか誰も知らない」ということです。
83件にはその場でアイコンを付けた
数えたついでに、83件すべてにその場でアイコンを付けました。タスクの内容を見て、それに沿った絵文字を選ぶ形です。
ただ、これは今あるものを直しただけです。明日また自動起票が走れば、同じ抜けが増えていきます。本当に直すべきなのは、抜けが生まれる入口のほうでした。
対策は「入口」と「安全網」の二重
考えた末に、対策を二重にしました。
| 対策 | どこで効くか | 中身 |
|---|---|---|
| 入口で必須にする | タスクを作る瞬間 | 作成と同じ呼び出しでアイコンを渡す |
| 安全網で拾う | 毎朝の棚卸し | アイコンなしを1回最大25件まで直す |
どちらか一つでは足りないと思いました。入口だけだと、新しい処理を足したときにまた漏れます。安全網だけだと、毎日直すものが溜まり続けます。
工場の品質管理では、ミスを注意ではなく仕組みで防ぐ考え方がよく語られます。いわゆるポカヨケですね。今回の二重の対策も、その発想に近いのかもしれません。
入口で必須にするルール
一つ目は、起票する側のルールです。文言はこう決めました。
「タスクを作るすべての処理は、作成と同じ呼び出しでアイコンを渡す。」
ポイントは「同じ呼び出しで」という部分です。作ったあとで付けに行く形だと、その二手目が抜けます。一手で済ませれば、抜ける隙間がありません。
NotionのAPIでは、ページを作成するときにアイコンも指定できます。公式のリファレンスで、作成の時点でiconを渡せることを確認しました。なので、技術的には一手で済むわけです。
迷ったら既定の絵文字でよい
もう一つ足したのが、迷ったときの逃げ道です。分野ごとに既定の絵文字を決め、迷ったらそれでよいことにしました。
完璧な絵文字を選ぶより、空で出さないことを優先します。ぴったりの一つを探すと、AIも迷って結局付けないかもしれません。基準を下げてでも、必ず埋まる形にしたほうがよいと思いました。
毎朝の安全網の設計
二つ目は、すり抜けたものを拾う安全網です。毎朝の自動棚卸しに、点検項目を一つ足しました。
- 「今日やる」「今日できること」の2つのビューを見る
- その中からアイコン未設定のタスクを探す
- 1回につき最大25件まで、内容に沿ったアイコンを付ける
- 残りは翌朝以降に任せる
全件は見ません。164件を1件ずつ取得する重さは、もう経験しました。あれを毎朝やるのは、現実的ではないと思います。
「どこまでやったか」を覚えさせない
ここで少し迷ったのが、進み具合の管理です。前回どこまで直したかを保存しておく仕掛けも、作ろうと思えば作れます。
ただ、作らないことにしました。「今日やる」と「今日できること」は、毎日中身が入れ替わるビューです。この2つを毎日見ていれば、いずれ全件に行き渡るはずです。
状態を持つ仕組みは、その状態自体が壊れることがあります。保存先が消えたり、途中で止まったりです。状態を持たない安全網のほうが、長く放っておけるのではないでしょうか。
上限を付けておく理由
1回25件の上限にも意味があります。何かの拍子で大量に抜けても、朝の処理が膨らまないようにするためです。
自動で動く処理は、歯止めがないと暴走しがちです。上限があれば、最悪でも25件分の手間で済みます。拾いきれない分は、翌朝に回せばよいと割り切りました。
反映先は定期処理3本
このルールを入れたのは、タスクを起票する定期処理の3本です。
| 定期処理 | 時間帯 | 入れた内容 |
|---|---|---|
| タスクの棚卸し | 深夜から早朝 | 起票時の必須化と朝の安全網 |
| リマインダーの取り込み | 朝 | 起票時の必須化 |
| メールの整理 | 夜 | 起票時の必須化 |
本当は、それぞれの本体の手順書を直すのが筋です。ただ、その場で手順書を直せない事情がありました。なので、各処理の指示文の側に「例外規定」として書き足しています。
残った課題はルールの二重管理
この書き方には、はっきりした弱点があります。同じルールが2か所にある状態になったことです。
手順書と指示文のどちらかだけを直すと、食い違いが生まれます。どちらが正しいのか、あとから分からなくなるかもしれません。
実は以前にも、似たことで痛い目を見ています。仕様には書いたのに、実装に入っていなかったことがありました。そのときは2日間、抜けたまま気づきませんでした。
記録と実態がずれる話は、解約完了と書いたサブスクの記事でも書きました。書いた場所が2つあると、ずれは静かに起きるのだと思います。手順書を直せるタイミングで、一本化するつもりです。
まだ穴が残っている場所
もう一つ、正直に書いておきます。自宅のMacで動いている起票スクリプトには、まだ必須の一行を入れていません。
当面は、朝の安全網が24時間以内に拾う想定です。ただ、安全網が見るのは2つのビューだけです。そこに載らないタスクは、少し時間がかかるかもしれません。
入口と安全網の二重にしたとはいえ、入口の一部はまだ開いています。安全網は、あくまで最後の受け皿という位置づけです。
規約とAIについて考えたこと
今回のことで、AIや自動化にルールを持たせるときの注意点が見えてきました。
- 文書に書いたルールは、処理の中に入って初めて守られる
- チェックできない属性は、守られているか分からない
- 「あとで付ける」より「作るときに付ける」ほうが漏れない
- 完璧を求める基準より、必ず埋まる基準のほうが強い
- 状態を持たない点検は、壊れにくく続けやすい
どれも、仕事では当たり前に言われることかもしれません。ただ、家の仕組みになると急に甘くなります。自分しか見ていないので、確かめる機会が無いんですね。
以前、学校の連絡を拾えなかった話も書きました。あのときも、仕組みを作った側の思い込みが原因でした。作ったら終わりではなく、一度は数えてみることが大事だと感じています。
「書いたから守られる」ではなく「仕組みにしたから守られる」。この発想は、家計の固定費にもそのまま効くと思います。例えばスマホ代は、一度仕組みを見直せば毎月の支払いに効き続けます。
押すと楽天のログインページが開きます。ログイン後にキャンペーン内容が表示されます。
よくある失敗と落とし穴
今回の経験と一般論を合わせると、こんな落とし穴がありそうです。
- 規約を書いた時点で、守られたつもりになる
- 人が作る分とAIが作る分で、同じルールが効いているか確かめない
- 数えにくい属性を、数えないまま放っておく
- 直した件数だけ見て、入口を直さない
- 安全網に全件点検をさせて、処理が重くなりすぎる
- ルールを2か所に書いて、片方だけ更新する
僕に当てはまったのは、少なくとも最初の一つと最後の一つです。心当たりがあれば、一度数えてみる価値はあるかもしれません。
始める前に確認すること
- 守らせたいルールを1つに絞った
- そのルールを守っているかを数える方法を確かめた
- タスクを自動で作っている処理をすべて書き出した
- 作成と同じ一手でその属性を渡せるか確認した
- 迷ったときの既定値を決めた
- ルールを書く場所を1か所にできるか考えた
よくある質問
Q. なぜアイコンにそこまでこだわるのですか?
アイコンそのものより、「規約が守られているか」を測る目印として分かりやすかったからです。見た目で有無がはっきりします。ほかのルールでも、同じことが起きているかもしれないと思いました。
Q. NotionのAPIで、作成時にアイコンを付けられますか?
公式のリファレンスでは、ページ作成の時点でiconを指定できると案内されています。絵文字のほか、外部の画像なども選べるようです。作成後にページを更新して付けることもできます。
Q. アイコンなしのタスクを一括で数える方法はありますか?
僕が試したビューやSQL風の照会では、アイコンの有無が返ってきませんでした。行の一括取得でも同じでした。結局、1件ずつページを取得して確かめています。ほかの方法があるかどうかは、使っている環境で確かめてみてください。
Q. 安全網を毎日全件でやらないのはなぜですか?
全件を1件ずつ確かめるのは、手間もAIの利用量も大きいからです。毎日見る2つのビューから上限つきで拾えば、いずれ全体に行き渡る想定です。重い点検は、続かなくなりがちだと思います。
Q. 「前回どこまでやったか」を保存しないと不安では?
保存する仕掛けは、それ自体が壊れる場所にもなります。毎日中身が入れ替わるビューを見ていれば、覚えておく必要はないと考えました。いずれ全件に行き渡れば十分だと割り切っています。
Q. ルールの二重管理はどう解消する予定ですか?
本体の手順書を直せるタイミングで、そちらに一本化するつもりです。それまでは、指示文側の例外規定と食い違わないように気をつけます。以前に仕様と実装がずれて2日漏れたことがあるので、慎重に進めたいと思います。
Q. 人がタスクを作る場合にも同じ考え方は使えますか?
使えると思います。テンプレートにアイコンを最初から入れておくのは、入口で必須にする発想そのものです。人の場合も、あとで付けるより作るときに付くほうが漏れにくいのではないでしょうか。
参考にした公式情報
まとめ
規約に書いたルールは、1ヶ月で半分しか守られていませんでした。164件を数えて、ようやく分かったことです。
直し方は二重にしました。入口で必須にすることと、毎朝少しずつ拾う安全網です。安全網は状態を持たず、上限つきで毎日見るビューから拾います。ルールの二重管理と、自宅Mac側の穴はまだ残っています。
完璧な仕組みではありません。ただ、「書いたら終わり」から一歩は進めたかな。自動化しているものがあれば、一度だけ数えてみてはいかがでしょうか。
押すと楽天のログインページが開きます。ログイン後にキャンペーン内容が表示されます。
本記事にはアフィリエイト広告を含みます。当サイトのリンクを経由して商品・サービスへお申し込みいただいた場合、提携先企業から成果報酬を受け取ることがあります。 また、運営者は楽天グループに所属する社員であり、紹介プログラムを通じた報酬を受け取る場合があります。記事内容・評価は広告の有無にかかわらず、運営者の実体験と調査に基づき作成していますが、 上記の関係性をご理解のうえお読みください。詳しくは免責事項・アフィリエイト表記をご覧ください。
楽天モバイルの通信エリア・電波状況について気になることがある方は、公式の電波改善・調査依頼フォームからご相談いただけます。
