works4Life

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

【観劇】鶴屋南北の歌舞伎狂言「盟三五大切」は、えげつない構成だった

spice.eplus.jp

 この前、友人に誘われて歌舞伎に行って来た。夏の納涼祭といって、今回の演目は鶴屋南北の歌舞伎狂言「盟三五大切(かみかけてさんごたいせつ)」が公演された。見たけどさすがの鶴屋先生、人間のクズっぷりとヴァイオレンスな血みどろだったわ的な内容でござんした。つーか、怪談的な涼しさは全くなく、にんげんこわい~の涼しさ的な納涼であった。

 

 歌舞伎や狂言は、前回見たときのことを思い出し、あらすじをある程度勉強してから見るようにした。というのも、狂言とかの設定って、人が多い、話が込み入っているという内容柄、一見で内容を理解するのがキツいからだ。

 「盟三五大切」も同様で、正直見る前にある程度あらすじを入れておかないと、誰がどれやらでといった感じになった。だいたい主要人物が、こいつはAなんだけど実はB、という設定ばっかりで、その時点で初見殺しである。特にこの「盟三五大切」は、後から調べるだに、「書替狂言」と「綯交ぜ」とを組み合わせた内容で、見る側の知識量を試す内容でもあった。

 

 今回は、「盟三五大切」の話の構成って、いい意味でえげつないっていう話を紹介したい。まず最初に、構成として欠かせない「書替狂言」と「綯交ぜ」について説明しよう。

  

「書替狂言」としての「盟三五大切」

 狂言には「書替狂言」という評判となった先行作の大枠を残しながら、人物の役名やストーリー展開の一部を書き換えるという手法がある。

 「盟三五大切」は、その「書替狂言」の手法も取りいれており、並木五瓶の「五大力恋緘(ごだいりき こいのふうじめ)」の書替狂言であった。

「綯交ぜ」としての「盟三五大切」

 鶴屋南北のえげつない所は、更にここにかぶせてくる点だ。

 狂言は、源義経といった馴染みある伝説だったり文学作品だったりから成り立つ。この土台となるものを「世界」と呼んでいる。例えば、今回見た「盟三五大切」は「五大力恋緘」の「五大力の世界」を土台としている。

 ところが、その「世界」を複数取りいれる手法もあって、鶴屋南北の得意技だったらしい。「盟三五大切」には、「五大力恋緘」の「五大力の世界」に「仮名手本忠臣蔵」の「忠臣蔵の世界」を入れ込んでいる。

 また、「盟三五大切」は南北が書いた「東海道四谷怪談」の続編としての意味合いもある。「東海道四谷怪談」自体、「仮名手本忠臣蔵」の外伝として書かれており、「東海道四谷怪談」は「忠臣蔵の世界」がベースとなっている。

 

 そんなわけで、「盟三五大切」の立ち位置は、「五大力恋緘」の「書替狂言」であり、「東海道四谷怪談」の続編で後日譚であり、「仮名手本忠臣蔵」の外伝であるという、3作品を題材に含んだ、入り組んだ世界なのである。

 

 この3つの世界をよどみなく組み込ませた点は本当にうまいというしかない。

 

ざっくりとしてないあらすじ

 ざっくりとしたあらすじを書こうと試みはしたんだけど、前提条件多いし、Aだけど実はBとか多すぎるし、登場人物3人のあらましだけでもwikipediaからひっぱってきてこうも長くなるのだ。

 

薩摩源五兵衛、実は不破数右衛門塩冶浪人

不破数右衛門は御用金百両を盗賊に盗まれるという落度で主家を追われたが、そのさなか塩冶判官の刃傷沙汰による主家お取潰しが起こり、何とか百両を調達して仇討ちの一味に加わろうと、薩摩源五兵衛と名を変えて金策している。

芸者妲妃の小万、実は神谷召使お六

神谷の家人の娘であるお六は、父に勘当された三五郎と夫婦となり、三五郎の勘当を解いてもらうため、百両の金子を調達するために、芸者をしている。自分に惚れている源五兵衛から金を貢がせようとしている。

船頭笹野屋三五郎、実は徳右衛門倅千太郎、小万の旦那

徳右衛門倅千太郎は、身持ちが悪く、徳右衛門から勘当を受け船頭笹野屋三五郎となっていたが、父から旧主のために百両の金子の用立てを頼まれた。これによって勘当を解いてもらおうと、女房お六を小万と名乗る深川芸者をさせて、百両の調達しようとしている。父の旧主の不破数右衛門が源五兵衛とは知らずに、小万を惚れさせて金を巻き上げようとしている。

 とりあえず覚えてほしいのは、主人公が以下二人にお金をだまし取られて怒って、小万を殺して、三五郎は切腹死させた、という結果だ。

 

いかにお約束を含ませるか

 世界を組み込ませた部分では、構成の中でどれぐらいお約束を含ませるかが、面白みのポイントだ。水戸黄門だったら「この印籠が目に入らぬか!」という台詞がなかったら締まりがないのと同様に、必ず組み込んでほしいような項目だ。

 「五大力恋緘」からは、例えば以下のようなお約束があって作中に含まれた。

  • 「五大力」から「三五大切」に書き換え
  • 主人公が、五人を皆殺し
  • 主人公が、殺した小万の頭を持っていって一緒にご飯を食べる

 「東海道四谷怪談」からは以下のようなお約束を含んだ。

  • 幽霊が出る

 そんでもって、「仮名手本忠臣蔵」からは次のような項目がお約束として組み込まれているかなーと思う。

  • 勘平の、間違って味方を殺めて、そこからくすねた金が味方の首をしめる要因からの切腹
  • 打倒吉良の、隠れていた所を頃して首のお供え

 特に忠臣蔵というと、切腹シーンがないと忠臣蔵じゃないよね!というぐらい、切腹シーンはお約束の一つだろう。

 

主人公が不破数右衛門が薩摩源五兵衛に身をやつして浪人だという設定

 この主人公の設定自体が本当にうまいと思う。

 不破数右衛門というのは、忠臣蔵の世界だと、赤穂浪士の一人にあたる。その一方で、身をやつした方の薩摩源五兵衛は、五大力恋緘の主人公の名前でもあり、二つの世界がちゃんと綯交ぜになっている。

 じゃあ、忠臣蔵では47人のうち不破数右衛門なんだ?と思ったんだけど、どうもwikipediaによれば、不破数右衛門は、47人の中で唯一浪人から義士の仲間入りができたという。だから、今回の浪人という設定には、不破数右衛門しかありえない。

 しかも、不破数右衛門は、義士の中でも最も活躍した、つまりもっとも人を切りとめたともいう。作中にあった五人切りは、「五大力恋緘」のお約束ではあるのだが、皮肉にも史実ともかぶってくるあたり、絶妙である。

小万の首

 小万は、主人公数右衛門をだました芸者なんだけど、数右衛門は小万を殺すと、その首を家に持って帰って一緒に飯を食うというなかなかなエピソードがある。この首持ち帰り自体もやはり「五大力恋緘」にあったエピソード。面白いことに、忠臣蔵だと、最後に仇である高武蔵守師直を首を掻き切り、位牌にその首を手向けるというシーンがある。なんとなく似てるんだよね。

 ところで、本来の劇内容では、数右衛門が飯を一緒に食べている間にかっとなって、首に飯をぶちまける。このエピソードは、「五大力恋緘」にはなくて、「盟三五大切」で追加されている。

 この飯ぶっかけ、どうして入れたんだろうかと思った。

 私が思うに、忠臣蔵では仇に当たるのに、一緒に飯を食うのは合ってない、それに敵討としてはこの時点ではまだ小万の夫三五郎はまだ生きているから、その点からみても、完全な敵討ちとしては不完全。だから、「これで終わっていいわけないだろ!」という意味合いも含めて、飯をぶちまけたんじゃないのかなぁと思った。

 それというのも、この後の三五郎の終わりがうさんくさいからだ。

 

よもやしそうにない三五郎がまさかの切腹死

 三五郎の最期は、本人が切腹死する。これが、三五郎の性格から考えると切腹するタイプには到底見えない。三五郎が金策していた理由だった家からの絶縁は、もともと身持ちが悪かったからだ。しかも金策についても、結局自分の女に金を作らせるという、身持ちの悪さを体現したような輩である。

 なのに、最後の最後になって、責任を感じて切腹するなんて、そんな忠義、どこに隠し持ってたの?!という有様だ。実際、ベースとなる「五大力恋緘」では三五郎切腹はしていないし、格闘の末討伐されるわけだし。となると、三五郎の切腹は、性格に目をつぶってもやるしかない、ということになる。

 そこで、切腹自体は、忠臣蔵の世界から必要になったんだろうなと想像できるだろう。

 

 というか、忠臣蔵=切腹、というイメージが私にもあって、やっぱ忠臣蔵だというには、切腹をどこかで入れないと締まりないよねー、と思う。

 

組み込まれた「仮名手本忠臣蔵」

 じゃあ、切腹があれば忠臣蔵なのか、というと、そこはさすが南北、ちゃんと忠臣蔵の話の構成を組み込んできている。

 三五郎の、工面したお金が本来助けるべき人間の首を絞める行為だった、というのは忠臣蔵に出てくる早の勘平の話の構造でもある。「盟三五大切」のここらへんの話の作りは、最後に切腹シーンを入れたことからも、忠臣蔵の話を取り入れているのは明白だ(早の勘平は切腹死するので)。

 また、「五大力恋緘」では夫婦ではなかったのに「盟三五大切」では最初から夫婦仲の三五郎/小万と数右衛門の関係は、「仮名手本忠臣蔵」での、塩冶判官高定の妻に横恋慕する高武蔵守師直との関係にも似ていて、そうするとこちらの関係から言えば、三五郎は、塩冶判官高定とも見てとれるわけである。

 さらに言えば、「仮名手本忠臣蔵」のラスボス高武蔵守師直は、隠れていた所をひっぱりだして殺された。一応三五郎が全体の話の立ち居としてはラスボスになるのだけれども、一応樽に隠れているんだよね。切腹したとはいえ、最終的には死んだわけで、三五郎=高武蔵守師直というのは、それっぽく見えるっちゃあ見える。

 

 見ようによっては、三五郎の死は、「仮名手本忠臣蔵」の三つの死のいずれにも似た部分を感じることができる。ま、見ようによってはね。

 

南北のそれっぽく見せるうまさ

 とまあ、これらが本当に相関関係にあるかどうかは、すべて憶測である。んだけど、まぁとにかくこういう混ぜたというか重ね合わせた構成を作るの、本当にうまいなと感心した。

 どこまで類似性を見出すかは、見る側にゆだねられているとはいえ、まさかね、二つの話の構成を重ね合わせてちゃんとした話にできてるのって、えげつないよね。

 

参考URL 

 

【雑記】定点観測 2018/08/10

定点観測は、自分のタスク実装を定点的にみていくための記録です。金曜記載。
だったんだけど、忙しさにかまけてサボってました。

 

仕事の状況

  • プロジェクト数:小(変化なし)
  • プロジェクト期間:1週間~1か月程度がメイン(変化なし)
  • コミュニケーションチャネル数:小(変化なし)
  • 場所数:小(変化なし)
  • mtg数:小(変化なし)

果たして、変化したタイミングで私が変わってきたな、と気づくことができるのかが心配になってきました。

正しいポモドーロテクニックをKanbanFlowでやり始めた

kanbanflow.com

 

 ポモドーロ導入については、他の記事に記載したので、ここではトピックログとして記載のみです。運用に大切なのはどちらかといえば、真摯に現実を計測するまことの力ではないでしょうか。22分ごろに声かけられても、もう1ポモでいいよね。。。

 

Todoistは崩壊している

 管理系の本拠地ツールを探して流浪の民ですが、Todoistもやはり私の運用には合わなかったようです。タスクの概要を追加できないのがやっぱり痛いし、コメント毎回開くのも面倒なんだよね。。

 

管理系の本拠地ツールとしてTrelloを使い始めた

 ええ、今まさに初めて使い初めてます。というぐらい、ブームからかけ離れてからようやく利用し始めましたがいい感じです。最初の使い始めはいつだって「いい感じ」なんですが、なんですが。。

 Trelloがいんじゃね?と思ったのは、各カードに概要を記載する部分があるところ

 GTDの2ステップ目の見極めステップで、「それは何か?」と答える部分があるんですよね。これを、この概要を記載するようにしてます。寧ろここに書かなかったら、Inboxから別のリストには移動させないようにしています。

 うまくいかない原因をつきつめると、2の見極めステップを疎かにしがち、という問題があったんですね。それが、気になってぺろっとInboxにいれるけど、その後のステップでちゃんと見極めようとしなかった。特にデジタルのリストで取り扱っていると、それに対してこまごまどういう風に考えているのか、といったものをどこにもはりつけずに、移動させるだけで満足してしまったというのが否めません。

 今回ポモドーロテクニックをやって、正しいやり方をするのが一番だ、というのを実感したわけで、GTDもみ直して、ちゃんと見極められるように「それは何か」を記録に残しておく必要があるわな、と思っていたのでした。

 それが、なんとなしに使ってみたTrelloがよかったというわけ。こうやってみると、チェックリストもコメントもあるわで、使い勝手はよさそうです。このまま使ってよさげかどうか見ていきたいと思います。

 Trelloをなんで使わなかったと言えば、画像の添付がいまいちだったから

 そんなTrelloを今まで敬遠していたのには、画像の添付がいまいちしにくいなーと思っていたから。

 Todoistならやってくれるリンクから自動的に画像取得してサムネしてくれるわけではなかったので、どうもなぁと思っていたのでした。

 が、この度、クリップボードから直接添付できることが判明したので、割と気軽に画像つっこめることがわかったんで使うようになりました。

 

 スマホ向けのアプリがあったり、連携しやすいツールがあったりといった所もありがたいです。

 今はそんな感じかな。

 

【雑記】家事をタスク管理化することはそんなにイヤなのか?

note.mu

 

 GTDの親分ツールにTrelloを導入し始めたので、Trelloの事例を漁っては読んでいる。その中で上記の夫妻で家事タスクをTrelloで回すっていう記事があったので、楽しく読んだ。個人的には、大賛成なやり方でいいな、と思ったんだが、はてブのコメントを見る限りだと、賛否両論で、「面倒くさい」「管理されすぎ!」とかのマイナス意見も多い。その中のコメントで全く同意なのが、「人はいかにプロジェクト管理しないのかがわかった」というコメントで、私も全く同意見だった。

 

家事をタスク管理するのはどこがイヤなのか?

 賛成意見については同意しかないのでスルーして、気になるのは、「面倒くさい」など管理を取り組むのに消極的な人々のことだ。

 それにしても、どういうことが、家事をタスク管理することがイヤなんだろうか?

 

 

その1:家事をタスク管理するのはどこがイヤなのか?→サボってるのがばれる

 この管理してまで家事をしたくない、というのは、寧ろ、こうすることによって、いかに自分が家事をサボっているのかを目の当たりにしたくない、というのが大いなる理由の一つとしてはあるんじゃないかと思っている。

 GTDを全く初めて収集するときに、同様に抵抗を覚える人がいる。その抵抗の一つには、「私が思い出すこの全部が私の全てだといいたいのか」とかいったような暴露に対する抵抗勢力を感じることがある。

 別に項目が多かろうが少なかろうが、未完了のタスクが多かろうが少なかろうが、それを自分自身の尊厳を傷つけるものではない。たとえどんなに部屋をキレイにしたところで、シンデレラの継母だったら重箱の隅をつついて文句を言うものだ。それと同様、気になることをやめない限り、気になることは永久に出続ける。

 家事も然り。寧ろ、洗い出すことで、通常の自分はどこまで実施することでよしとするかが明確になっていいのでは、と思うのだが、そういうわけにもいかないようだ。

 

その2:家事をタスク管理するのはどこがイヤなのか?→今までのロクでもない経験を思い出して、イヤだ

 管理を共有することでありがち、というかタスク管理で今までにあったイヤなことを思い出して、そもそもしたくない、という気になってしまうのはありそうだ。

 だから、こういう仕組みを見るだけで、上司の顔を思い出すような、そんな気分になって「うえええ~やだよぉ」という気になってしまってもおかしくないだろう。

 これはもう仕組みの内容がTrelloが云々というのではなくて、タスク管理、という概念そのものに嫌気が出しているんだろう。

 

ポイントは合意形成と運用方法

 この手の管理手法の場合、何が一番ポイントかというと、記事にも書かれていた通り、合意形成が大切だ。

 この仕組みをいやいやというわけではなく、受け入れて使っていくことに同意します、というのを説得して使う段までもっていくこと、これが大切だ。

 他にも、1週間で終わらせるつもりでも終わらなかったタスクをどうさばくか…怒らずに次週からのタスクを減らして対応しようとするか、はたまたどうしてできなかったのかねちねちなじるのか、では今後続けられるかは変わっていくだろう。

 

 

家事のタスク管理は導入したい(一人で)

 私は同居人と2人ぐらしだ。同居人がメインで飯を作るので、私はそれ以外の家事を率先してやるようにしている。

 明確なタスク管理は行っていないものの、そこそこ回ってはいるので、今回のようなタスク管理は二人では行わない。合意形成がとれないので。。のだが、私個人としては必要だと思って、一人で利用したいと思っている。

 理由は、家事タスクを毎回思い出すのが面倒&プロセスを忘れがちだからだ。家事は結構いろいろ細々あったりするので、漏れがないように覚えておきつつリサイクルしたいと思っていたのだけれども、なかなかいいのがなかったんだけど、これはいい事例だなと思って、早速家事用のボードを作ろうと思う。

 

複数人で回す家事は理想系を共有することから始まる

 複数人で家事に関して問題が生じるのは、それぞれによって、これが理想系、が全く異なることだ。その理想系に至らしめる家事に人によって誤差が生じるのも不思議ではない。

 人はどれぐらい相容れないものなのかは、我が家の事例を紹介しよう。

 

同居人「家がきたなくて、気が狂いそう。のみちゃんはこんなお家で大丈夫なの?!」

私「(周りを振り返って見直しつつ)……どこらへんがきたないの?」

同居人「(こいつ……汚いとすら思っていなかった……っ!)」

 

とまあ同居して15年以上経つというのに、理想系の状態が全く共有されていないことがこの前判明したことである。家事に関するイライラというのはそんなに簡単に解消することはないだろう。

 

【タスク管理】正しいポモドーロテクニックを開始して3週間目の感想と実装

 正しいポモドーロテクニックをするようになって、3週間目に突入した。調子がすこぶるよいので現状の感想や実装などをまとめておく。

 

正しいポモドーロテクニックの感想

 非常にちゃんと仕事してる感があるのでとてもよい。この時期、〆切りまで時間あるからダルダル進めてしまいがちなのだが、一日3ポモドーロだけでも進めようとかで、ちみちみ進められている。

 GTDの悪い所は、非常にタスク量が多い時が最適に動くので、暇になってくると、途端にうまくいかなくなる点だ。で、暇に開かせてプロジェクトなり項目なりをぶっこむと、今度は精査が甘くなって、自分で首を締めることになるという悪い循環が出る。

 忙しくない時には、ポモドーロテクニックはよいと思う。だんだん忙しくなってくる時は、ポモドーロが適用できるかどうか言い切れないが、今の所調子が良い。

 

  トラッキングには、KanbanFlowを利用している。

kanbanflow.com

 

 以下は、KanbanFlowでの設定やら運用の仕方をまとめておく。

実装1:KanbanFlowでのカラム設定と1日の運用の仕方

 カラム設定は左から順に以下の通りに設定している。用途は右に書かれている感じ。

  • Maybe - 1~2週間以上放っておいてもよいもの
  • 特定プロジェクト名 - 実質稼働中のプロジェクトでそこそこタスクがあるのでここに列挙している。プロジェクトが完了すればなくなる/別のプロジェクトになる予定
  • 近々実施 - 1~2週間以内には実施しないとやばそうなもの。上記の特定プロジェクト名からも直近で実施したいものはこちらに移動させていく。
  • Repeat - リピート系タスク。Doneに行くと、自動的にここに入ってくるように設定しておく。
  • Do today - 今日予定しているタスク
  • In progress - 今日予定しているタスクから動かしてきた実施中/実施予定のタスク
  • Done - 完了したもの

 前日もしくは当日の最初の計画時に、Do todayに今日やる予定のものを、他のカラム移動させてくる。ここで、各タスクを実施するポモドーロ数を見積もる。1日に8~9ポモを目標として、数の増減を調整して計画は終了。私はノートに別途記載して、見積もりは書くようにしている。

 作業開始前には、Do todayからAM中に実施予定のものを In progressに移動させておく。上から順番にスタートして消化していく。

 その日の最後に、収穫できたポモドーロを数えてノートに追記。「今日もよく収穫できた」と満足感を得る。で、明日するタスクを Do todayに移動させて、今日の作業は終了。

 

 といった流れが、会社での一連の運用の仕方である。

 

実装2:KanbanFlowでの色の設定

 色の設定は、プロジェクトではなく、タスクの重い軽いを表している。 

  • 赤 作業(頭使うorたるい)
  • 緑 作業(頭使わない)
  • 橙 作業(好きなやつ)

 これのよい点は、見た目で重い軽いが分かる点だ。こうすることで、「朝一番に一番重要or重いタスクを実施する」ということができるようになった。これはかなり重要で、いろんな所で言われているし、実際エネルギー量が満タンな朝に手をつけるのが一番よいこともわかってるんだけど、なかなかできなかったんだよね。でも、それができるようになったので、かなり満足している。

 

例えば、本日残っているタスクが以下のように表示されてると、赤いやつってできれば早くどっかいってほしい。そしたら好きなタスクばっかり残るから気が楽だ。だから、まずは赤いタスクからしようという気になる。

f:id:nomico:20180807125709p:plain

 

 とりあえずわかったことは、これぐらい明確化しないと、「朝一番に重要なものから手をつけよう」という気にはならないということだ。

 

【タスク管理】ポモドーロテクニックは25分ごとに休憩すればいいというわけではない

 ポモドーロテクニックって25分ごとに休憩入れればうまくいくやつでしょ? いやはやそうじゃなかったというのを、下のブログで知って、やり直している。

 

誤解していたポモドーロテクニックと本当の威力 | RickyNews

 

私の理解していたポモドーロテクニック

 ポモドーロテクニックの記憶といえば、25分集中して、5分休憩する。それを繰り返せば生産性がほらこの通り!というものだと巷の情報で見知って覚えていた。

 

  • 25分集中、5分休憩入れる

 これで十分動いているものだと思ってたんだけど、そうではない。

 

本当のポモドーロテクニック

 ところが、ポモドーロテクニックは、25分だけでは全然集中力というのは生成できない。

  • 25分集中、5分休憩入れる

 更にここに、ルールとして以下のようなものを入れる。

  • 1日でできるポモドーロを見積もる
  • 集中できなかったら、カウントしない

特に、ポモドーロを見積もるところがポイントで、ポモドーロをちゃんと収穫するためには、割と仕事を明確にしておかないと見積もれないということがわかってくるのだ。というわけで、自動的に、以下の項目も作業として含まれる。

  • ポモドーロできる作業を洗い出す

とりあえず何かやって集中する、というわけではなく、具体的にこれこれをやって集中することを明示的に本人が行う、というのが、集中ポイントとなるのではないか。

ポモドーロ収穫ゲーム

 私は、ポモドーロテクニックのやり方を、「ポモドーロ収穫ゲーム」、といったような感じに捉えている。25分集中すると、ポモドーロが1個収穫できる。1日に8個収穫できると今日はいっぱい収穫したねー、という感じ。

 ちなみに「収穫」というのがポイントで、この言葉だけで一気にタスクをやる感じからイメージが拡張されて、一気にやりやすくなった。

 私はポモドーロを収穫するためにタスクをしなければならない。そして、1日8個の収穫を目指そうとすると、午前中に3個は収穫を目指したい。そうすると、途中でブラウザ見てる暇がないというか、ブラウザ見たらポモドーロ収穫できないから! これによって、その日の最後に収穫できたポモドーロの個数を見ると満足する。

 25分マジに集中するのは難しいので、今のところ余所見をしないという条件で25分完走することをゴールとしている。これによって、途中ブラウザを見たり、といったような余所見運転はしなくなる。

 

ポモドーロの時間とそうでない時間の区別

 で、これの何がいいかというと、ポモドーロを収穫したということは、真面目に仕事していた時間がある!というのが明確にわかるということだ。

 長時間だったり、成果の見えない作業だと、どうしても時間をついやしても進んだ感がでない。途中ブラウザを見たりちょっと長い休憩を挟んだりすると、なおさらやったかなぁと心配になってくる。んだけど、ポモドーロを収穫した、とみなすようにしただけで、なんと自分はがんばったかの生成度合いが半端ない、ような気がする。

 仕事の時間では、他の人と話したり、メールを見たり、PCのセキュリティソフトのバージョンアップをしたり、仕事に直結しないようなこともたくさんあったりする。そういった作業もありつつ、ちゃんと仕事をしました、といえる時間が明確に区別できる、ってのがいいんじゃないかなと思う。

 

初心に戻ってポモドーロ・テクニックの技術を読んでいるが

 今回かなり誤解があったので、ここはちゃんと原本に戻ろうと思って読んでみた。読んでみたんだが、いまいちピンときていない。

 導入部分がきゅうりくんとアーティチョークくんの話から始まる、エマジェネティックスで言うなら黄色全開的な導入部分や、特徴的なイラストに集中が分散されてしまっているような。

 それはさておき、本書の目的が、集中できるためにはどうしたらいいのか、というところにフォーカスがあるせいなのか、アプローチが集中していない原因を探ろうとしているのが、ピンときていない理由かもしれない。 

アジャイルな時間管理術 ポモドーロテクニック入門

アジャイルな時間管理術 ポモドーロテクニック入門

  • 作者: Staffan Noeteberg,渋川よしき,渋川あき
  • 出版社/メーカー: アスキー・メディアワークス
  • 発売日: 2010/12/16
  • メディア: 単行本(ソフトカバー)
  • 購入: 13人 クリック: 330回
  • この商品を含むブログ (56件) を見る
 

 

 参考にしたブログにも記載してあった、SOFT SKILLSの本を見たほうが、やり方的について洗練されているかもしれない。 

 

SOFT SKILLS ソフトウェア開発者の人生マニュアル

SOFT SKILLS ソフトウェア開発者の人生マニュアル

 

 

【雑記】どうして書かなくなってしまうかの分析

久しぶりにブログを書く。

 

日記の悪いところは、ちょっと呆けてしまうとすっかり書き方を忘れてしまうところだ。もうちょっと頻繁に書きたいなーと思っても、うっかりもうちょっとわかりやすく、と思っているうちにだんだんと後回しになってしまう。

 

そういうわけで、自分がどうして書かなくなってしまうのかを何度目かの分析を行った。結果、考えられる理由は以下の通り。

 

  • キャッチーな画像
  • 説明用の画像
  • 画像はgoogleから取得
  • 話のオチ
  • カスタムURL
  • 寝かす

 

キャッチーな画像

 これな。これの画像を探しているうちに時間がたってしまって、だんだんと公開しなくてもいっかーと思ってしまう。はてなのプラグインから利用できるようになって便利にはなったけど、これといった画像がないとやはり探してきたりしてやっぱり時間がかかる。なるたけない方向性で行こう。

 

説明用の画像

 これを準備し始めると、ブログの公開は、1光年ぐらい遅くなる。むちゃくちゃ準備面倒。というわけで、これもなるたけ画像使わない方向性で考えよう。

 

画像はgoogleから取得

 ちなみに、いつかするかもしれない移行のことも考えて、画像はgoogleから取得するようにしているのだが、これもいただけない。googleにおく、そのデータをはてなから設定する、などという二度手間に面倒をかける。これも一旦やめよう。結構な画像が移行で落ちてしまった今となっては今さらである。

 

話のオチ

 話がまとまれればいいのだが、実際そんな毎回うまくいかない。即興落語しているわけでもないんだから、ちょっとそこまでは自分を求めるのはやめておこう。

 

カスタムURL

 実はがんばってつけてたけどもういい。面倒。つけない。

 

寝かす

 そのまま書いた内容を公開するのはなんとなくちょっと引けて寝かすことが多い。そうすると、今度は公開タイミングを失ってしまい、そのまま出すに出せなくなってしまう、ということがよくある。

 特に、ツール系の話は、寝かしている間に興味がなくなって使わなくなってしまったという日にはまさに日の目にあたらない状態となる。

 

 というわけで、日記というかブログを書かなくなるための原因を以下のようにつぶして書いていこうと思う。

  • キャッチーな画像→いれない
  • 説明用の画像→極力使わない方向性。
  • 画像はgoogleから取得→なければはてなに直接はりつける方向性。
  • 話のオチ→オチがなくてもOKとする
  • カスタムURL→つけない
  • 寝かす→書いたら当日もしくは1日後に公開登録する

 

それでも日記と言う名のブログを書く理由

 何度もこれを見直しては見るんだけども、長らく続けていくための最終としては、やはり未来の自分に対して、あなた昔こんなこと考えていらしたのよ、というのを書きとめておくことに他ならない。

 数年レベルであいていても、その時期はこんなことがあったから書いていなかったのだなーというような情報源にもなるので、私は書いて損はないとは思うんだけれども、正直なかなか続けるのって大変である。

 このブログ以外にもいくつかやろうとしてみるんだけれども、枠が育っていないので、すぐにやめてしまうこと多数である。

 

「枠」

 このブログだけは、枠が育っているので、なかなか取り除こうと思ってもそこまで行かない。

 枠、というのはこのブログのこと自体で、私をいくらか説明するのに役立つものとして成り立っている。だから多分このブログはそのまま使い続けるんであろうけれども、今となってはなんとわかりにくいタイトルだと思っていても使い続けるんだけれども。その不可解さやわかりにくさも含めて、結局自分を示すものとなる。

 

とまあいろいろ考えたんだけど、日課になってないってゆーのが一番書かない理由なんじゃないかしら。

【GTD】Microsoft Outlookのタスクツールを試用中

 会社のタスク管理はTodoit+FitzNOTEというちょっと変形的なやり方を行ってきていた。が、FitzNOTEを見返す率がやっぱり低いのでどうにかしようと思って、この度MS Outlookに付属しているタスクツールで運用してみた。

 

きっかけは、会社がO365を使い始めるようになったため

 きっかけは、なんてことはなく、会社がO365が採用されたので。Outlookのソフトウェア導入すると、Todoツールも一緒についてくるもんだから、せっかくだからと思って一元化できないかと思って試しに使っている。

 

アドオンは入れない

 Outlook向けのGTD用のアドオンもいくつかあったけど、入れない。というか、入れたけど使い方がよくわからんかった。ので、プレーンなままで最適化に臨む。

 

分類項目でAction/Calendar/WaitFor/Projectを分類、重要度「高」でNextAction扱い

f:id:nomico:20180516122819p:plain

 タスクの種別は分類項目で区別する。

 ルーチンとか日付が決まっているものは全部Calendarタスク扱いに。waitForあたりも作ったけどまだ活躍はない。

 それ以外はActionという扱いになる。そのActionの中でも、やろうと決めたもの=NextActionについては、重要度「高」をつけて区別する。NextActionは今まさにすべき項目という取り扱い。

 プロジェクト用のタスクも作る。以下にも説明するが、フォルダ=プロジェクトというように取り決めている。そうすると、プロジェクトリストが作れない&進捗を書く場所がない、てことでプロジェクト用のタスクを作ることにしている。

 

 フォルダ=プロジェクト、各種リスト=ビューで対応

 フォルダ=プロジェクトという扱いで、関係するアクションはプロジェクトに突っ込む。カレンダー項目も同じく属するフォルダ配下に入れる。

 上記でも説明した通り、プロジェクト用のタスクも一つは作る。

 実際のフォルダの中はこんな感じになる。

f:id:nomico:20180516123604p:plain

 

 じゃあ、NextActionリストはどこで出すの? 今日のタスクリストは?? というのは、全部ビューで賄う。

 

今日のタスクは、To Do バーのタスクリストで専用ビューで表示

f:id:nomico:20180515181559p:plain

 既存の「To Doバーのタスクリスト」という項目があるんだけれども、これが「タスク」用のフォルダにあるタスクの全項目を横断して表示できるようなので、これを利用し、ビューで出し分けをする。

 

 既存の用意されたビューでは目的のリストは表示、カスタマイズして導入。フィルター項目により出し分けをできるのだが、結局SQLを修正する羽目に。。

 

今日のタスクは、(タスクが未完了 AND (分類項目がAction AND 重要度「高」)OR( 分類項目が WaitFor) OR (分類項目がCalendar AND 期日が今日))

 今日のタスクはNextActionとwaitFor、そんでもって期日が今日のCalendarが出てきさえすればいいので、そのようにSQLを修正する。

f:id:nomico:20180516125512p:plain

 各項目はSQLで候補が出てくるんだけど、条件がどうしても並列でしかできないのでそこを上記の条件になるように構文を変更する。

 構文サンプルとしてはこんな感じ。

(
// タスクが未完了 
	("http://schemas.microsoft.com/mapi/id/{【ユーザ用ID】000XXXXX-0000-0000-C000-000000000XXX}/81010003" = 0 
		OR 
	 "http://schemas.microsoft.com/mapi/id/{【ユーザ用ID】000XXXXX-0000-0000-C000-000000000XXX}/81010003" = 1 
		OR
	 "http://schemas.microsoft.com/mapi/id/{【ユーザ用ID】000XXXXX-0000-0000-C000-000000000XXX}/81010003" = 3
	) AND
	(
	// 分類項目がCalendar AND 期日が今日
		 ("urn:schemas-microsoft-com:office:office#Keywords" LIKE '%Calendar%' 
			AND
		  %today("http://schemas.microsoft.com/mapi/id/{【ユーザ用ID】000XXXXX-0000-0000-C000-000000000XXX}/81050040")%
		)OR (
		// 分類項目がAction AND 重要度「高」
		  "urn:schemas-microsoft-com:office:office#Keywords" LIKE '%Action%' 
			AND
		  "urn:schemas:httpmail:importance" = 2
		)OR (
		// 分類項目が WaitFor
		  "urn:schemas-microsoft-com:office:office#Keywords" LIKE '%waitFor%'
		)
	)
)

 

 ユーザ用IDの後に続く数字が、各項目を番号になるけど、そこも違うかもしれないので、あくまで参考で。実際は私も、他のタブで設定したのがそのままSQL構文になるので、その構文を入れ替えただけである。

 

詳細項目は、「閲覧ウィンドウ」を「右」にセットしてデフォルトで表示

f:id:nomico:20180516125551p:plain

 詳細項目を表示できるのは私にとって必須要件のため、これができるので大幅にToDoこのまま使ってもいいかな、という気にはなってきた。

 割といい。というか、ActionとCalendar項目がある程度統一できるのはほんといい!

 

 

 だからといっていいことづくめでもない!

 

デメリット1:タスクの順序がない

 Outlookのタスクは順列の概念がないので、いくらでもソートが可能である。なので、好き放題ソートしているうちに、最初の順列はどこかに行ってしまうので、自分で項番をふるなど何等かの工夫が必要そう。

デメリット2:階層がない

 タスクの階層がないため、フォルダ配下は1階層のみで記載される。

 厳密にはフォルダの階層構造はあるはずなんだが、その階層構造は表示には反映されない。

 あとは、グループという概念があって、これで区別も可能であるにはあるけど、とりあえず今回は使用していない。

 

デメリットの理由は、タスクの想定がプロジェクトレベル

 これらのデメリットの理由は、明らかにわかっていることで、タスクの想定が、GTDでいうところのプロジェクトレベルだということだ。

 だから、このレベルで進捗を他の人に連絡するとかになってて丁度具合がいいし、そのレベルだと、項目にそこまで順列が関与することはそうそうない。

 

  とはいえ、そのデメリットはりつつも、詳細はOneNoteに飛ばせるリンクはあるしで、なかなか便利な仕組みにはなっていると思う。