works4Life

GTDメインのタスク管理と生息してますログを記載しています。

【雑記】30分の惨事

それはさながら土木工事のようだった。

German, Males, 3D Model, Isolated, 3D, Model, Full Body

 

 同居人が言うには、私が帰って来た時、私の様子はものすごく不可解なものであり、何かしらしょげている模様であると言った。それは、30分足らずの出来事だというのに、私の心を深く傷つけた。ついでに歯も傷つけた。治療のためだが。

 そう、歯医者に行ってきたのだ。

 たかだか30分の歯医者で、私はうちしがれて帰って来たのだった。

 

 

 今日は虫歯があったのでその治療だ。歯と歯の間の虫歯だったから、結構な分量を削ってかぶせものをつける。1回目はかたどり、2回目はかぶせ、という治療計画である。今回は1回目だ。

 

 1回目はかたどり。

 そう、かたどり。

 かたどりをするためには削らなくてはならない。

 

 注射を打つ。

 ずいぶん昔と比べたら歯医者もバージョンアップした。

 私の歯医者の恐ろしい記憶といえば、歯肉に直接麻酔注射を打ち、それが激しく痛かったというものである。

 今や麻酔注射を打つための麻酔というものがあって、2段階の処置になっている。技術は躍進している。みんな痛かったんや。

 そしてメインの麻酔注射も、普通の注射ではなく、電動で動く注入器である。これによって思う存分麻酔を打つことができる。技術は躍進している。

 

 そんなこんなで注射を打ち、感覚が薄れて、なんだか腫れた感じになっていく。指で触ると、触る感触はあるが触られた感触がなく不思議である。歯ですら自分の意識下にある、という認識はあるのに、麻酔のかかった部分は、自分の肉体でありながら、完全に支配下から抜けている。

 

 そんなぶよぶよした口腔をもって治療が始まる。かたどりをするために、歯を削るのだ。

 何度通っても、この歯の削られるのだけは慣れない。音が悪いのかそれとも先天的な意識下によるものか、とにもかくにもいくら技術が躍進したからといって、歯を削られるのだけはおそろしい。

 

「痛かったら左手をあげてくださいねー」

 

 はーい。

 そして、チュイーンという音とともに削られていく歯。私の気力もごっそり削られていく。そして突然の痛み。

 すぐに手をあげた。

 

「麻酔足しますねー」

 

 足してください、じっくりと。麻酔された時、ちょっと心配だったのだが、それはやはり気のせいではなかったようだ。麻酔の範囲がそこはかとなく浅い感じがしたのだ。やっぱり浅かったらしい。

 追加に追加を重ねて(明らかに最初の2倍ぐらい注入している感がある)、再度歯を削る。

 

 今の歯医者に来てから、認識を改めたことがある。

 それは、歯を治療することは、土木工事であるということだ。

 今通ってる先生は特にこの土木工事感がえげつなくて、すごい歯をがこがこされてる感が半端なかった。人として認識されているはずだが、なんとなく二の次感があるのが、また土木な工事味を感じてしまうのだろうか。

 それもそのはず、こんながこがこした内容でも、この歯医者の時間はいつも決まっている。

 

 30分。

 ここの歯医者はいつも1回30分と決まっている。

 なので、先生はとてもとても集中しているはずで、歯にばかり注力しているのだ。だから、土木工事味があるのだろうか。。

 

 さて、削った後は、ゴロゴロされる。ああ、今滑らかにされるタンクローリーが今口にいるんだなととてもよくわかる。相変わらず土木工事感はんぱない。

 

 そして有無を言わさず、ゴム状のものをかぶせられ、口の圧迫を感じつつかたどりを行う。これが割とつらい。特に、口に吐き気をもよおす部分にあたって、はきそう。。 という苦行を通りこして待つこと数分。

 

 かたどりを取って、仮のかぶせものを作って今日は終了。

 

 しめてここまでだいたい30分である。

 そして私の心は深く傷ついたのだった。

 自分で志願したとはいえ、ひどい目にあった。自分で治療を受けておきながら、ワンチャンやネコチャンが予防接種などを受けてひどい目にあったと拗ねる気持ちがとてもよくわかった。

 

 いずれにせよ、歯の治療はできれば回避したいものである。

 

 ちなみに、麻酔が残ってる口でごはんを食べても、気持ちが半減するのはなぜだろうか。

【雑記】GW1が明けた

 五日もあるーと思っていたのが五日しかなかった。

 

しずかな金色連休

 いつもだと、帰省やら旅行やらでばったばったしている時期のGWなのだが、今回は特にどこに行くというわけもなく、しずかに過ごしていた。多少のおでかけはしているものの、でっかく移動を!しているわけではない。

 

未来日記

 連休からちまちま見ていた「未来日記」を見ていたので、気になってGW最終日に一気に見た。

www.future-diary.tv

 というか、主人公は「ユキテル」くんというんだけれども、ヤンデレヒロインことユノちゃんがユッキー♡ユッキー♡(ハート重要)と呼ぶので、同居人と未来日記の話をする時の主人公呼びはユッキー呼びになる有様だった。

 未来の見える日記を持つことのできた12人が、次代の神になるためにバトルロワイヤルをして生き残る、というのがこの漫画の趣旨なんだけど、次代的には、丁度携帯とスマホの端境期なので、どっちの携帯も見ることができた。充電はいつしてんの?!とかいう地味な心配をしつつハラハラしながら見ていた。

 主人公のユッキーは弱いキャラで、ヤケに強いヒロインのユノに守られつつ生き延びていくのであった。ただ、ユッキーの声のトーンがものすごくエヴァンゲリオンのシンジくんに似てて、え、シンジくん?と勘違いすることもしばしばであった。しかも、途中からこれまたエヴァンゲリオンのカオルくんの声そのままのキャラが出てきたので、デジャヴ感が半端ないのでござる。

 ところで、未来の見える日記があることで、何がどのようにバトルができるかというと、相手の動きを推察することができる、予測ができるということで、動きを躱せる!という風になってる。んだけども、結構バトルしながら携帯を見ていて、むしろその挙動を実行する方がハイレベルなのでは、と思うとかなりシュールな画面が繰り返されるのだった。それ以外にも、真面目にやってるだけにシュールな画面があったりもして、なかなか楽しかったアニメだった。

 ラストはどうなの、というと、え、そこで切る?!みたいな感じで切っていたけど、一応最終的にはハッピーエンドを迎えたようである。しかも、ハッピーエンドの結末が、ラストのラストで展開されたため、パッと見だと、ピンとこない派とすんなり納得する派で別れた。自分は後者で、ハッピーになるための結末なら、まぁそうなるよねということで納得感があった。

 

【タスク管理】Jiraを一瞬使って一瞬のうちにMicrosoft ToDoに戻ってきた話

 年度も変わったことだし、タスク管理ツールも新調するかー、と思ってJiraを使ってみましたが、あっさり今まで使っていたMicrosoft ToDoに戻ってきました。

 

www.atlassian.com

Jiraはソフトウェア開発のインシデント管理ツール

 Jiraは上記見出しの通り、ソフトウェア開発のインシデント管理ツールだ。最近フリーでも使えるようになったと、風のうわさで聞いたので、ちょっと管理に使ってみないか試しに登録してみた。

 私が仕事で使っていたころを考えると、ずいぶん見やすくなっている。設定のアーキテクチャー自体はそんなに変わってなさそうである。

 

Jiraの七面倒くさい設定アーキテクチャ

 これは2009年ごろに作ったらしい、Jiraのスキームとかの関連図。項目を表示したりしなかったり、どこでどうやって設定すればよくわからなくなって作ったのがこの図である。ちなみに、ツールはFrieve Editorというのを使っている。

 

f:id:nomico:20210420140106p:plain

 

 作った当時からずいぶん時間が経ってしまったので、項目の誤差はあるだろう。多少は少なくなってるかな、と思ってみたけど、名前は多少変わってはいるもののあまり変更はなさそうである。

 

 この図の意図を、すっかり忘れている自分のために説明しておこう。

 まず、これらの設定は、一番上段の「プロジェクト」を設定するために定められるものだ。

 そして、プロジェクトは各スキームと呼ばれる組み合わせの設定を紐づけることで、各設定が組み合わせられる。これが二段目の「プロジェクト用スキーム」の意図である。

 三段目が、それぞれの設定を作るためのパーツであり、四段目はそのパーツの実装である。

 

 二段目の関係性について、もうちょっと触れておこう。

 課題タイプスキームは、どういう課題を取り扱うかのスキーム「ToDo」「エンハンス」「トピック」「バグ」などの課題タイプを決める。

 そしてそれぞれの課題タイプで項目の利用の有無を決めるのが「フィールド設定スキーム」で、項目の表示の有無を決めるのが「課題タイプスクリーン(画面)スキーム」だ。

 それとは別に、画面遷移を決めるのがワークフロースキームであり、項目の削除編集等の決めるのが権限スキームである。

 そしてこれらのスキームは、再利用性を加味して、組み合わせのセットとして定義し、それをプロジェクトに設定している。

 

 とまあ、私が知りうる中では、かなりコントロールが効くインシデント管理ツールというのがJiraの印象である。設定は、真面目に実装するとめちゃめんどい。

 

 なんだけど、昔の見てくれと比べると随分わかりやすくなったし、使えるかなーと思ってものは試しに項目をセットしてみた。

 が、タイトルの通り、1日ももたずに、Microsoft ToDoでいいや、ということになったのだった。

 その理由を振り返る。

 

理由その1、やっぱりこまごました項目には向いてない

 Jiraはソフトウェア開発のインシデント管理なので、項目のライフサイクル自体は割と眺めである。数週間は滞留しているものが、タスクという扱いとなる。

 その分、サブタスクを自分できって、作業をすることも可能なのであるが、残念なことに一覧性に欠ける。

 

理由その2、サイクルタスクに向いてない

 Jiraはソフトウェア開発のインシデント管理なので、同じ課題が定期的に発生するなどという概念は存在しない。従って、リピートタスクを作ろうとなると、非常に面倒くさくなるのであった。

 

理由その3、今日の計画を作りづらい

 Jiraはリピートタスクを作りにくい。だから、今日はこれとこれとこれをやるぞ!といってピックアップするのに非常に長けていない。毎回サブタスクを作るのもなんだかなーだし、かといって、今日やったタスクを次の日に出すのもなんだかなーである。

 

理由その4、項目設定めんどい!

 Jiraはインシデント管理なので、デフォルトで使える項目が割とたくさん存在する。それが面倒。画面を操作するレベルであったとしてもやっぱり面倒なものは面倒なのである。

 

 以上のような理由から、やっぱりJiraは個人のタスク管理にゃ無理だんべ、と思い、早々に撤退を決めたのであった。

 

 

というか、Jiraが合わない理由は自分で言っていたじゃないの

 いろいろ書いてきたのだが、実際Jiraが個人のタスク管理に合わない話は、既に自分で言っていたのを思い出した。

 

www.works4life.jp

 

 ……。嗚呼、凝りてない。

【雑記】仕事のオンライン会議がオフカメラが大半であるのはなぜだろうか?

 最近、仕事のオンライン会議では、カメラはオンにしていますか?

 私はすっかりオフです。

 

 Video Call, Video, Conference, Zoom, Online, Skype

 

 

仕事のオンライン会議でオフカメラにするのが通常になった

 なんやかんやとリモートワークが通常運用になってしまい、気が付けば1年近くリモートワークを行っている。

 会議はオンライン会議でするのが通常モードになり、Zoomがいいだの他の会議がいいだのあったが、うちはMicrosoftをどっぷり利用しており、オンライン会議といえばTeams会議である。

 オンライン会議といえば背景はどうしようかと騒がれていたが、ここ最近、というか早い段階で、我が会社はほとんど画面を映さず音声だけでのオンライン会議をするようになった。

 今ではよっぽどメインな会議ではない限り、部長クラスも画面を映さない。オンライン飲み会ならそこそこみんな顔を見せるけど、会社の仕事会議では、ほとんど顔を見かけなくなった。

 会社全体そうなのだろうか、とは思うが、他のあんまりかかわっていない部署とときたま実施する会議も総じてカメラはオフなので、おそらく会社全体としてそういう傾向にあるだろう。

 

 他の会社はともかく、自分の会社の仕事会議は、カメラオフでオンライン会議をするのが、通常となっている。

 なぜだろう。

 

機材がへぼいから?

 人によってカメラが行き渡ってない、搭載されてないから、使えない人に合わせたのでは? と、思うかとそうではない。

 自分の会社提供のノートPCは、既にカメラ搭載型で、最初のころはなんなく画面を映してオンライン会議をしていた。

 このカメラ機能は、わが社では標準的な仕様である。また、コロナによるリモートワークでなくとも、オリンピックによる影響もあり、リモートワークもできる環境にシフトしつつあったところである。

 だから、一部のメンバーにカメラ機能の不利益があり、それなら合わせてカメラを使わない、というわけではないのである。

 

メールやIRCといったフェイスオフのコミュニケーションに慣れているから?

 自分の会社は、昔からメールを多用している。メールはエビデンスが取れるため、言った言わないバトルを回避するためにも頻繁に使われている。

 他にもIRCやらのチャットツールを部署によっては利用している。つまり顔を見なくてもコミュニケーションをとることには、慣れている会社だと思う。

 だからオンライン会議で顔が見えていなくても、そんなに問題はないのかもしれない。

 

画面共有ばかりして顔を見ていないから?

 オンライン会議で顔が見えていなくても、と上記で言ったが、そもそも自分が参加するミーティングでは、画面共有ばかり利用していた。

 画面共有機能は、オンライン会議にとっては、むしろメインはこっちといっても差し支えないレベルだ。自分の会社ではほとんどの会議で利用しているだろうし、これが使えないとなると、オンライン会議の最大メリットが消えるのではないかと思う。

 顔は見えなくてもよい、画面が共有しさえすれば。

 

オンカメラだとそもそもネットワークに支障をきたすんですが・・・

 顔は見えなくてもよい、画面が共有しさえすれば。

 オンカメラで動画を配信するとなると、その分ネットワークはひっ迫する、そうすると、音声までもひっ迫してしまい、ロボット声になったりして、会議そのものに影響が関わってくるのであった。

 しかるに、まずは最初にカメラをオフをするようにした。

 

 そして、私たちは気づいてしまったのである。

 カメラオフでも、オンライン会議に全く問題ないことに。

 

ネットワーク回線だけはどうする術もなし

 リモートワークになって、このネットワーク回線状況というのは人によって大分差異が出てきた。自分なんかは、家で回線契約をしているので、そこからWIFIをはって使っている。一方ではネットワークなんか契約していない人もいたりして、そういった場合は、自社携帯のテザリングでPC使っているという場合もある。これはきつい。

 そしてわが社は、ネットワークを仕事にしている会社であり、回線が重いという話については、たぶん他の会社よりセンシティブだし、順応は早い方だろう。

 

 オンカメラにしていておかしくなった話になれば、すぐさま比較的不要なカメラ機能はオフにし、そしてそれを許容する。ネットワークが重いのはしょうがないもんね。

 そして、顔が見れないよりも、会議が速やかに実行されることを優先する。

 このように一人カメラオフしては、徐々にカメラオフが増えていき、そしてカメラオンは誰もいなくなってしまったのだった。

 

 これによって、ミーティング前だけは、背景と自分をとりつくろわなくてはならないという煩雑な作業から解放され、我々は、本当の意味でリモートワークを手に入れたのである。

 

結論

 自分の会社が、仕事のオンライン会議がオフカメラなのかを検討してみたのだが、その一番最初の理由は、「ネットワークが重いのカメラを切る」という考え方の優先度が高いからなんじゃないかなと思う。

 そしてその優先度が高いのは、わが社がネットワーク関連の仕事に従事している、てことが大いにある。ネットワークが重いのはどうしようもない。ネットワークが改善するにはお金がかかるので、自分達でできることがあるならそっちに倒した方が解決するのだ。

 だから、自分の会社では、ネットワークが重いのでカメラをオフをすること、ひいては、誰でもカメラをオフすることに寛容になったのではないだろうか。

 

 それにである。会社以外のミーティングでは、オフカメラにしているのは、私ですらなんだか失礼にあたる、という感じがどうしてもするのだ。だから、特にカメラをオフにする理由がなければ、初期状態ではオンカメラである。

 だが、会社のオンライン会議では、「え、なぜそこでカメラをオンにする理由が?」というぐらいに、カメラをオンにする理由があまり見当たらない。

 

【GTD】GTDの「いつか」リストと「プロジェクト」リストの境とは?

 GTDで議論されることの一つにある「いつか」のリストと「プロジェクト」のリスト。この判断基準がいつも不明瞭でわかりにくいことだと思う。

 私が、こういう意味なんだ、と感じたエピソードがあるのでそれを紹介したい。

 

とあるプロジェクトのガントチャートと課題リスト

 会社の仕事プロジェクトで、進捗管理をしていたときの話だ。数年単位のスケジュールのため、プロジェクトはMicrosoft Projectでガントチャートを作成し、作業を進めていた。

 そんな中、作業を進めているうちに自然と課題が出てくる。それらの課題はガントチャートではなく、課題リストに記載し、管理する。

 この課題リストの内容は様々だ。すぐに消化できるものもあるし、そういったものは数日で課題リストから完了する。しかし、調査した結果、プロジェクトの計画に影響が生じるものもある。

 とある課題は、プログラムソース上の問題で、開発とは別途調査を行い対応する必要がでてきた。リーダーは、課題を、課題リストからMicrosoft Projectにぴょこっと移し替えた。Microsoft Projectにはその課題のための線表がひかれ、そして課題は課題リストからは消えた。

 またとある課題が出てきた。お客様から新しい要望が出てきたのだ。これこれこういう機能が付けたい、という新たな要件定義。プロジェクトも後半に差し掛かろうとしてんのにそんな余裕ないだろすっとこどっこい、と思いながら課題リストに入れる人は多いだろう。プロジェクトはそんな余裕は全くなく、次回の開発の要望リストに転記され、課題リストの課題としてはクローズした。

 

課題リストはInbox、ガントチャートは「プロジェクト」リスト、要望リストはSomeday

 上記の場合、以下のリストが出てきている。

  • 課題リスト
  • Microsoft Projectのガントチャート
  • 要望リスト

 これは、GTDで言うなら以下に相当する。

  • 課題リスト=Inbox
  • Microsoft Projectのガントチャート=「プロジェクト」リスト
  • 要望リスト=「いつか」リスト

 

 課題がプロジェクトの計画表に組み込まれるときとそうでないときがある。これはどういう違いがあるだろう? 

 それは、課題が実際に達成しなくてはならないものであるかそうでないかである。とある課題はスケジュールが厳しくても組み込まざるを得なかったものもある。組み込まれなかったお客さまの要望は、スケジュールを厳しくしてまで許容できるものではなかったりする。それらは、プロジェクトとして実施するかしないか判断される。

 実施すると判断されたものは、Microsoft Projectのガントチャートの「プロジェクト」リストに。

 実施しないと判断されたものは、要望リストの「いつか」リストに。

 

「いつか」は決めの問題 

 私は、いつも「いつか」は決めの問題だと思っていて、そのように話している。いずれにせよ、実行しなければならないものがあるならばそれは「プロジェクト」リストだし、今は達成させる必要がないものならばそれは「いつか」リストだ。

 課題がプロジェクトの線表に含まれた時のことを思い出してほしい。それは、限られた時間、リソースや状況などを加味した上で、実行しなくてはならないと結論に至った。至ったがゆえに、完了しなければならないプロジェクト計画表に組み込まれたものである。このキワを分つものこそが、仕事では「要望リスト」と「Microsoft Projectのガントチャート」であり、GTDでは「いつか」リストと「プロジェクト」リストなのである。

 仕事のプロジェクトならうまくいくのに、なぜ自分ごとならうまくいかないのか、そう考える諸氏も多かろう。

 仕事のプロジェクトの場合、範囲をどこからどこまでするか、最初に決める。いわゆるスコープだ。だから、これはプロジェクトの対象になるならないの判断ができる。

 一方、自分ごとの場合、どこまで自分ごととして捉えるかが曖昧だ。やるべきことの範囲のみならず、時間についてもである。そして時間が経つだけでしたいことしなければならないことは増える、仕事で言うなら時間が過ぎるだけで課題リストが山積みだ。

 現場の人間からしたら溜まったものではない。これが、私たちという人間内で起こっている仕事の現状だ。だからまぁ、毎度自分炎上案件になるのも致し方ないのだよな、うん。

 

GTDだとおおよそ1年以内に決着をつけたいものが「プロジェクト」リスト行き

 とはいっても目安をくれと言われるらしく、GTDの公式では、「プロジェクト」リストにはだいたい一年以内に決着がつくものを入れましょうと、推奨している。これは人はおおよそ年間計画を立てて考えることも多いため、運用に適っている。

 そして、「プロジェクト」リストには、10から100個ぐらいまで常時存在しているものだとしている。100個…!とびっくりする数だが、ウェブサービスのサブスクリプションチェックを毎年見直すことを組み込んでいても、そこそこの数になるのだ。

 

 プロジェクトの目安となる1年は、あくまで目安だ。だから、何かの大会が2年後に控えていて、それで何が何でも勝ちたいと思っていたら、2年後の大会に向けてのプロジェクトが当然あっておかしくない。それぐらい、ブレのある1年だ。

 

プロジェクトは現状稼働中の絞り込み

 いろいろ言ってきたけど、とにかく現状稼働中のものを絞り込んでみておきたいもの、それが「プロジェクト」である。今いらんやろ、そう思ったらひとまず「いつか」にひっこめるのも手であろう。

【お知らせ】CHANGES公開しました&毎週木曜日21:00にClubhouseで部屋を開いてます

CHANGESの連載を更新しました

changes.jp

 

 CHANGESでタスクツールの連載をしていますが公開しました。今回はTodoistについて。以前使っていたころと、無料で使える範囲がだいぶ変わっているようです。ユーザインタフェースも微妙に変わっていたりしてました。

 記事を書く際に、サービスを見直すのですが、情報の持ち方で、どういうサービスを作りたいかがだいぶ変わってくるようです。

 有料ですがよければご覧ください! 第1回は無料で見れます。

 

毎週木曜日21:00からClubhouseで部屋を開いてます

 タスク管理関係で悩める子羊たちの部屋として開いています。悩み事やら、オススメのツールがないかなどありましたらお気軽におはいりください。特に何もない時は、その時のトピックでゆるくお話している部屋です。

 優先順位としては悩み事相談室なので、お気軽にご参加ください。

 

 昨日はちょうど新エヴァンゲリオンの映画を見た後だったので、その話を中心にしておりました。

 エヴァについてはそのうち記事でかこうと思います。

【GTD】GTD公式がOmnifocus3のセットアップガイドがあったので履修中

 実は公式で出てた。

 

f:id:nomico:20210324172540p:plain

 

GTD公式からOmnifocus3セットアップガイドを出していた

 OmnifocusでのGTDのやり方を探している。情報収集はオリジンから、というのを思い出して、というわけではなく検索で引っかかって見つけたのであった。

 

store.gettingthingsdone.com

 

 他にもThingsとかAsanaとかTodoistとかMicrosoft To Doなんかもガイドを出していたので、気になる方は参照あれ。

 

store.gettingthingsdone.com

 

 Google翻訳にお願いしながら履修したところでは、ネクストアクション見るならTagパースペクティブがいいよ!て言われている。

 

 プロジェクトとアクションの紐づけがいいので、Omnifocusにしたのだけれども、iPhoneとiPadの見てくれで大分使うシチュエーションが違うよなぁと最近思っている。というか、iPhoneで管理はやはり無理すぎる。

 

そういえば、なんかよくわからんがOmnifocus配下のGTDファイルも見つかった

 OmnifocusからGTDとOmnifocusに関連した資料も出しているらしい。らしいが検索した経緯でひっかかった資料で、いつの資料かわからない。多分Omnifocusの資料だけど、うーんかなり古いことは確かだろう。

 

 こちらは日本語版。

http://files.omnigroup.com/software/macosx/Extras/OmniFocus/GTDandOmniFocus_ja.pdf

 

 そしてこちらは英語版。5th Editionと書いてある。日本版は1st Editionでとまった感じかな。

https://downloads.omnigroup.com/software/MacOSX/Extras/OmniFocus/GTDandOmniFocus.pdf