「タスク管理」について ー会社員もそうじゃない人もー（６）
こんにちは。日常のタスク管理について考えるシリーズの六回目です。
■前回はこんなことを書きました
自分で作るWebシステムの動作環境について、WebサーバーとDBサーバーを自分のノートパソコンにインストールすることで、Webだけどオフラインで使えるというお話をしました。
そしてツールを作り始めるに当たって、自分で自分にヒアリングをして、簡単な「要求定義」をしてみました。
🍀前回の記事はこちらです。
■今回は・・・
ツールの概要はイメージできたので、実際の生活を分析しながらツールの設計をして行きます。
■活動を分類して「カテゴリー」に分ける
最初に、家計簿でも「食費」「光熱費」みたいなカテゴリー分けをするのが常套手段なので、ここでも生活をカテゴリー分けしてツールに反映したいと思います。
まず、自分の生活サイクルを確認してみます。
常に時間ぴったりに活動しているわけではありませんが、大体こんな感じでした。
・7:00～9:00： 起床・朝食・家事
・9:00～12:00： 仕事
・12:00～14:00： 昼食・家事
・14:00～18:00： 仕事
・18:00～24:00： 家事・夕食・その他
この時点で「仕事」「家事」「その他」に分類できましたので、それぞれをもう少し詳しく分析します。
「仕事」
何といっても生活のメインは仕事（の筈）なので、ひとまとめにしちゃうのは、ちょっと大雑把すぎるなと思いました。
ここで私が注意したことは「分類のための分類」ではなく「使うための分類」にすることです。
チケットのカテゴリーを見て「これは文章を書く仕事だから、頭がスッキリしている午前中にやろう」とか「これは短時間で終わるタスクだから夕方にやろう」とか、何某かの判断の助けになりそうな分類にしたいと思います。
よくよく考えてみて、「仕事」の中には大きく分けて「制作」「販売」「広報」の３つのアクティビティがあるのに気が付きました。
これをもう少し細かく分けてもいいかな？・・・とも思ったのですが、分類の粒度というものは匙加減が意外と難しいもので、細かすぎると、これがまた（軟弱な）私の脳の負担になるような気がします。最初から粒度を小さくし過ぎるのも良くないので、この３つくらいで良しとします。
「家事」
私の場合の家事は毎日決まりきったものがほとんどなので、ツールで管理するものはそれほど多くありません。
例えば「リフォーム」とか「大掃除」のように、やることが多いとか、期間が長いとか、内容が複雑な家事が発生したときはチケット化してもいいかも知れません。あと、「月に一度のごみ置き場掃除」のようなイベントは、忘れないようにリマインダーとして登録するのもアリかと思います。
それ以外の日常の家事については、やればすぐに終わるものは手書きのメモで処理し、逆に手書きメモで対応しきれないようなものが出てきたら、その時はツールでコントロールしようと思います。
あまり細かい家事をいちいち登録していると、チケットに埋もれてしまって余計に物事が進まなくなってしまいますからね。
なので、分類としては「家事」でひとくくりでOK。
「その他」
この「その他」の中身はいろいろあるのですが、ツールでコントロールしたいものとしては「ブログの記事を書く」とか「小説を書く」などの（ちょっと大袈裟な言い方をすると）「創作」と、将棋や読書のような「趣味」に分けようと思います。
ということで、この辺をツールに「カテゴリー」として反映できそうです。
カテゴリー
・制作
・販売
・広報
・創作
・趣味
・家事
■期間を分類して「サブカテゴリー」を考える
活動の〈種類〉は分類できたので、次は〈期間〉を意識した分類を考えてみたいと思います。
タスクと一概に言っても、極端な話、一日で終わるものもあれば、年単位で取り組むプロジェクト的なもの、規則的に繰り返すタスクもあります。ツールを使う時には、この〈期間〉もひとつの大事な視点になりそうなので、サブカテゴリーとして分類したいと思います。
サブカテゴリー
・当日（１日で終わる）
・短期（一か月以内で終わる）
・ロードマップ（長期）
・繰り返し（定期的に繰り返す）
こんな感じに分けてみることにします。
「当日」や「繰り返し」はTODO的なものなので、親チケットのない〈単独チケット〉になります。
「短期」や「ロードマップ」では〈親チケット〉の配下に複数の〈子チケット〉が並ぶことになると思います。
■「ステータス」を考える
次にチケットの「ステータス」を考えます。「ステータス」とは〈タスクの状態〉を示すものです。
ステータス
・登録
・進行中
・一時保留
・完了
・削除（非表示）
「登録」：
これからやる予定だけど、具体的な開始日が未定のタスク。
「進行中」：
開始日が決まっていて、スケジュールに載るタスク。
「一時保留」：
一度スタートしたけど再開を前提にストップし、一時的にスケジュールから外したタスク。
「完了」：
実施済みのタスク。
「削除」：
必要なくなってやめたタスク。
この「ステータス」は、ツール上で以下のように運用する予定です。
開始日が決まっている「進行中」のチケットがスケジュールに表示されるので、日々それを実施して行く
実施し終わったチケットは、ステータスを「完了」にする
「進行中」のチケットが無くなったら「登録」または「一時保留」のチケットの中から次にやることを選んで「進行中」にする
分類作業はこれでおわり。
＊ ＊ ＊ ＊ ＊
前の記事で、今回作るツールは〈Webシステム〉だというお話をしました。
ここでちょっと簡単な用語解説をさせていただきたいと思います。
一般的に、Webシステムの表示画面側を「クライアント・サイド」と呼びます。「これこれをやってほしい」とシステムに要求する側です。HTML と CSS と JavaScript などで書かれた複数のテキストファイルで構成され、Chrome や Safari などのブラウザを使って表示します。
システム側（プログラムの方）を「サーバー・サイド」と呼びます。PHP や Ruby、Java など、お好みのプログラミング言語で書かれた実行プログラム（これもテキストファイル）がWebサーバー側に設置され、そこで動くようになっています。
ちなみに、何故か「システム制作」とはあまり言わず「システム開発」と言うことが多いです。元の英語が「System Development」だからかな？
＊ ＊ ＊ ＊ ＊
■画面設計
次に、クライアント・サイドの表示画面をイメージしてみたいと思います。
最終的にツールを使うときに目にするのはクライアント・サイドなので、裏で動くサーバー・サイド側を作り始める前に「表示画面」（UI：ユーザーインターフェース）を検討して、使い勝手を想像してみたいと思います。
これを巷では「画面設計」と言います。
この「画面設計」ですが、普通はクライアントやチームと打合せするために、まずは紙に書いた図表で検討します。
いきなりHTMLとかで作り始めない理由の一つは、クライアントを含め大勢の人間が関わっているので何度も変更が入り、その度にHTMLファイルを細かく修正していたら大変だからです。
余談ですが、通常のシステム開発というのは、とにかく図表が多いです。
「ER図」や「画面遷移図」のような基本的なものから「ユースケース図」だの「アクティビティ図」だの「マシンステート図」だの・・・システム・エンジニアというのは図の書き方を覚えるだけでも一苦労な職業です。
なんでそんなに図が必要かというと、一人で開発はできないからですね。最低でも発注元とコミュニケーションをとらなければならないし、開発側も大抵はチームでやりますから、全員でコンセンサスがとれる共通言語としての〈定番の図表〉というのが必須になります。
図の種類も沢山あって、「ユーザー側目線」「裏で動いているプログラム目線」「物理的な機器や接続の状態」など、色々な角度から見たものを作って、皆でそれを見て「うんうん、この時はこうなるのね」と納得するワケです。
また、そうした設計図をまとめて、最終的に「成果物」として納品することを発注側から求められます。つまり、開発側からしたら山のような図や表も、提供する『商品』の重要な一部というわけです。
大事な『商品』であるハズのドキュメントですが、その量も質も、業者によってこれが本当にピンキリです。最低限のドキュメントすら作ってこない所もあれば、六法全書みたいな量を納品してくる所もあります。何事も必要十分かつ適量でお願いしたいものですね。
システムを発注する人々が忘れがちなのは、将来のメンテナンス時にも設計図は必要だということです。
作った会社とは別の業者にシステムの修正を依頼する場合、ドキュメント類がちゃんと揃っていないと「ナニガドウナッテルノ？」と言われてしまいます。
ちなみに、システム屋がまともなドキュメントの無いシステムのメンテナンス仕事を頼まれた場合、追加料金をもらって自分たちで図表や資料を作ることになります。でもそれは下手をすると、最初にそのシステムを作った人たちよりも能力の高い技術者でないと難しかったりするのです。そんなときの一番安易な解決策は「これはもう手が付けられませんね～。作り直したほうが安上がりだし、もっといいモノが出来ますけど～？」です。
何においてもそうでしょうが、規模の大小に関わらず、発注する際の「持続可能性」にはお気をつけて。
あれ・・・なんだかいろいろ思い出して、愚痴っぽくなってしまった。スミマセン💦
画面設計の話に戻ります😊
今回はいたってシンプルなツールなので、設計という程のものも必要ないでしょう。HTMLとCSSで直接作ってしまいます。
裏で動くWebシステムはまだ何もないので、表示テキストはダミーで適当なものを想像して入れておきます。
「今日のタスクリスト」画面
日々、その日にやることはこの一覧を見て実行します。
TODOリストのようなものですが、親＆子チケットで管理するところがポイントですね。
一番上のチケット『水彩画「金魚 #1」』の親チケットをクリックしたときは、こんな画面が表示されることになります。
「親チケット」画面
親チケットの基本情報の下に子チケットが並んでいて、そのリストの中の〈進行中〉のチケットが「今日のチケット一覧」に表示されるわけです。
この例では〈進行中〉の「下絵」が終わったら、次の「彩色」のステータスを〈登録〉から〈進行中〉に変更して〈開始予定日〉と〈完了予定日〉を設定します。
そうすると、設定した開始予定日の「今日のチケット一覧」に表示されるようになります。
これでツールの基本画面のイメージができました。
ほかにも「年間スケジュール」「チケット一覧」「ガントチャート」などがありますが、基本画面のバリエーションなので、ここでは省略します。
次回は「スケジューリング」と「切り替え」をどうするかについて考えます。
お楽しみに～😊
よろしければサポートお願いします！次の作品の励みになります！