ToDo管理の日付項目の考え方について

Nozbeは日付を一つしか持たないが、これは、機能不足なのではなく、最大効率のための仕様だ。日付を2つ以上に持ったところで、効率性は高まらないのであれば、不要という潔さを理解したい。

Nozbeは日付を一つしか持たない。このことが意味することを考えてみよう。Nozbeが持つ日付は期日だ。他のツールでは、日付を複数持つものが多い。(1)開始日と期日を持つケース、(2)開始予定日、期日、完了日を持つケース、(3)開始予定日、期日、開始実績日、完了実績日を持つケース、(4)開始予定日、完了予定日、期日、開始実績日、完了実績日を持つケース、など。日付は多いほうが管理精度が高いというのは言えるだろう。

まず、共通するものに着目して、期日について考えよう。

期日を管理するのは、当然だが、仕事を終わらせることをコミットした日付を管理するためである。 コミットした日付がない場合には、その仕事はする必要がないわけではない。単に効率を考えて仕事をすればいい、ということを意味する。 コミットした日付がある場合、その仕事は多少効率が悪かろうが仕事を果たす必要がある。つまり、優先順位は、効率<コミットメントということになる。

(重要)コミットメントは、効率よりも優先順位が高いがゆえに、効率性を損なう。

例えば、締め切りが消印で本日の郵便物があったとしたら、家から5分かかる郵便ポストまで出しに行かなければならない。その場合10分かかる。一方で、他の用事のついでにポストに投函するなら、その時間は不要で0分。効率で考えたら他の用事があるついでに出すのがいい。

効率性を高めるためには、コンテキスト(上記の例では、近所に出かける)基準で、今行うことで一番効率的なものを実施するのがいい。コミットメントとなる期日を書くことは効率性を損なうが、常識的な優先順位に従えば、期日を管理することはやむをえない。

次に、開始予定日について考える。

開始予定日を管理するのは、期日よりも目的があいまいだ。通常は作業に要する日数を考えて、期日に間に合うように開始日を設定することになるのだが、要する日数は正味の作業時間というわけではない。途中で別のタスクを行う必要もあるのだから、正味の作業時間を見積もり、その日数を開始日にしたら、作業は期日に対して遅延する。また、開始日に遅れたからと言って、誰かにコミットしている日付ではない。また、その日付まで着手してはいけないということもなかったりする。

つまり、開始予定日はあいまいな日付が設定される恐れが大きい日付という事実を踏まえよう。

一方で、効率性の面で、開始予定日は意味がある。開始予定日その日まではそのタスクは忘れていていいということだから。人間、短期記憶のエリアは限られているので、忘れていいものは忘れておくことは頭の能率を高めるので、効率の面で効果がある。

Nozbeではどうやってこの開始日を管理しているのかというと、スターをつかって管理する。毎朝15分、タスクリストを眺めて、スターをつけ、そのスターのみを管理することになる。 効率の面では、毎朝15分、タスクリストを眺めなければならないということで、開始予定日を管理する場合よりも効率が悪いと見えるかもしれない。しかし、その実際は、開始日の設定があいまいにしかできないのだから、あいまいなものを見直しながら進めるのと大して効率は変わらない。スターのほうが日付より入力が簡単な分、効率的なのだ。

そもそもの話として、作業時間が複数日にわたるようなものは、本来、分解して実際に体を動かす内容にまで分解できていないのだから、その対策を打つべきで、開始日付を管理することで改善できるものではないともいえる。

(重要)開始予定日はあいまいにしか設定できない。タスクを分解して、その日の仕事をクリアにしたほうがよい。

あとは、完了日だが、大きな声では言えないが、完了日は実際には持っていて、みようと思えばみられる。完了フラグを入れた日だ。でも、完了日を見ることってあるだろうか。完了日が欲しいような作業は、作業記録をとるべきじゃないだろうか。僕は、これはTogglをつかって実現しており、Nozbeで完了日を見ることはまずない。いや、作業記録とToDoリストを一体化したいんだということなんでしょう。言いたいことはわかります。Nozbeでもできるのです。完了日付を変えられないけど。

ということで、Nozbeは、期日と実際の完了日を持つということでした。あれ、なんか最初と言っていることが違う・・・。

割り込みが入ると元の作業に復帰できない問題について

資料のPathを聞かれるのをなんとかやめたくて、また、人にPathを聞くのもしたくないと思ってます。なぜなら、作業を中断する時間の割に集中力をもとの作業に復帰するのが大変だからです。

そこで、検索に頼るのがいいと思って、最近はredminewikiに書くようにしています。効果として、聞かれることが少なくなったのかがわからないんですよね。

 

Excel方眼紙と折り合いをつけた件について

現在やっているプロジェクトで、なんとか、Excel方眼紙ではない別のツールで、設計書がかけないか検討してみたが、結局、Excel方眼紙となった。

この経緯について少しまとめておいたほうがいいかな、と思ったので、ここに記録しておくことにする。

ここにはアンチExcel方眼紙の人もいると思う。その意見は尊重するし、僕も元々アンチExcel方眼紙派なのだけれど、 現実的な世界で結論を出そうとすると、個人の思いだけでは結論だせず、感覚とは異なるところに結論が落ち着くこともある。

論点1 図解をするためのソフトにいいものがない。PCにソフトウェアがインストールできない、SaaS型のツールはライセンス面でペイしない。

MS Office製品以外で、図解、例えば画面遷移図を描こうとすると、別のソフトをインストールする必要が生じるが、結局社内のセキュリティポリシーから、PCにソフトをインストールするのは大きなハードルだ。 また、SaaS型のツールでも、いいものは結構見つかるのだけど、その図を描くだけで、そのお値段ですか? という専用ツールならではのコストパフォーマンスの悪さがネックとなる。 Microsoft製品は、社員のPCには最初からインストールされているし、社内の情報システム部のそれ以外使ってくれるなという言い分もわからないではない。

論点2 Markdownや、reStructuredTextや、Wikiは表がしんどい

ブロック図をblockdiagを駆使して描くなど図はなんとかなったとして、設計書の大きな要素は表であることはまぎれなく、表がサクサク作れないと、メンバーにこれを使ってくれとは言えない。 MECEに要件を記載するには、表形式が一番だから、表の生産性が劣る手法は取りずらい。Excelは表を作るのには最高に効率がいい。

Markdown派の人も、Excelで表を書いてから、Markdown化してるだろう。 設計書のメインが表なのだったら、表を一番書きやすいExcelで設計書書くのが一番だろうということで、折り合いをつけるべきだろう。

論点3 セル結合と、縦罫線、参照リンクさえなければ、Excel方眼紙でも意外といい

Excel方眼紙の何がいやって、セル結合と縦罫線、参照リンクであることに気付いた。 これらをなくせば、それほどストレスは生じない。

セル結合があると、Copy&Pasteできない。 逆に言うと、セル結合さえなければ、Copy&Pasteは非常にスムーズ。

そこで、片っ端から設計書フォーマットのセル結合を外して、Excel方眼紙のテンプレートを配ることにした。

また、ついでに縦罫線も全部消した。つまり、縦罫線があることで、表が長くなった時に、行挿入して、罫線をつぎ足しするという面倒な行為が発生していたから、それをやめたいとおもったので。 かわりに、罫線は表の上下とヘッダ行、行罫線をそれぞれ太線、実線、点線にしておいた。Excel方眼紙なので、必要に応じて、適当な列に書いてくれれば、十分な表として通じる。

さらに、本当は計算式もなくして、参照リンクが発生しないようにしたらもっとよかったが、計算式をなくして、書き忘れのチェックをするのも馬鹿らしいと思ったので、 少しは残すことにした。

RedmineでPlantUML(+Graphviz)を使おうとしてはまった話

RedmineでPlantUMLを使いたいと思い立ち、自分のBitnami Redmine環境にインストールした話です。 なかなかPlantUML(というよりGraphviz)が思い通りに動かずはまりました。 結論を言うと、PlantUMLのPluginを修正してやっと解決しました。

事象

シーケンス図は正常に表示される
Alice -> Bob: Authentication Request
Bob --> Alice: Authentication Response

Alice -> Bob: Another authentication Request
Alice <-- Bob: another authentication Response

f:id:bawbr:20190106094334p:plain

f:id:bawbr:20190106094429p:plain

クラス図はエラーとなる。
Class01 <|-- Class02
Class03 *-- Class04
Class05 o-- Class06
Class07 .. Class08
Class09 -- Class10

f:id:bawbr:20190106104534p:plain

f:id:bawbr:20190106105620p:plain

原因追求1

表面上の原因は、Graphvizが正常に動作していない。 エラーメッセージの

Warning: Could not load "/usr/lib/graphviz/libgvplugin_pango_so.6" - file not found dot

がヒントだろうと思われた。

原因追求2

シェルから、Graphvizが正常に動作しているかどうかを確かめてみる。

$ plantuml -testdot
The environment variable GRAPHVIZ_DOT has been set to /usr/bin/dot
Dot executable is /usr/bin/dot
Dot version: dot - graphviz version 2.38.0 (20140413.2041)
Installation seems OK. File generation OK

正常にインストールができていることが確認できた。シェルから実行すると、エラーが再現しない。 なお、plantumlの中身は、以下のようになっている。

$ cat /usr/bin/plantuml
#!/bin/bash

/usr/bin/java -Djava.io.tmpdir=/var/tmp -Djava.awt.headless=true -DGRAPHVIZ_DOT=/usr/bin/dot -jar /usr/share/plantuml/plantuml.jar ${@}

原因追求3(原因箇所特定の巻)

Rubyの外部コマンド起動の方法により、Graphvizが正常に起動できるかを確認してみる。

$ ruby -e 'system("/usr/bin/plantuml -testdot")'
The environment variable GRAPHVIZ_DOT has been set to /usr/bin/dot
Dot executable is /usr/bin/dot
Dot version: Warning: Could not load "/usr/lib/graphviz/libgvplugin_pango.so.6" - file not found dot - graphviz version 2.38.0 (20140413.2041)
Error: dot generates empty file. Check you dot installation.

ということで、Rubyから起動したときに、エラーが再現することがわかった。また、redmine の pluginに使われていいるplantumlのスクリプトも確認してみる。

plantuml/plantuml_helper.rb at master · dkd/plantuml · GitHub

      `"#{settings_binary}" -charset UTF-8 -t"#{frmt[:type]}" "#{plantuml_file(name, '.pu')}"`

ここで、

#{settings_binary}

は、plantumlが代入されたもの。つまり、バッククオート形式で、plantumlを呼び出している。シェルから、ruby -eでバッククオート形式で試してみる。

$ ruby -e 'p `/usr/bin/plantuml -testdot`'
"The environment variable GRAPHVIZ_DOT has been set to /usr/bin/dot\nDot executable is /usr/bin/dot\nDot version: Warning: Could not load \"/usr/lib/graphviz/libgvplugin_pango.so.6\" - file not found dot - graphviz version 2.38.0 (20140413.2041)\nError: dot generates empty file. Check you dot installation.\n"

ということで、やはり同じようなエラーとなる。

原因追及4(試行錯誤の巻)

インターネットで調べてみると、環境変数LD_LIBRARY_PATHが外部コマンドplantumlに引き渡されていないことが原因のようなので、plantumlのシェルスクリプトをいろいろといじってみるがうまくいかない。rubyの呼び出し側で何かできないか、ruby側で調べてみる。

原因追及5(解決の巻)

ここでrubyの文法を調査して、環境変数を与えられる外部コマンド起動の方式を確認すると、下記の記法を確認した。

system(env, command, options={}) -> bool | nil

module function Kernel.#system (Ruby 2.6.0)

そこで、バッククオートされている部分を下記に置換した。

system({"LANG"=>"ja_JP.UTF-8","LD_LIBRARY_PATH"=>"/usr/lib/graphviz"},"#{settings_binary} -charset UTF-8 -t#{frmt[:type]} #{plantuml_file(name, '.pu')}")

すると、クラス図が、正常に表示されるようになった。

f:id:bawbr:20190106184333p:plain

自分の環境

Redmine

Environment: Redmine version 3.4.5.stable Ruby version 2.3.7-p456 (2018-03-28) [x86_64-linux] Rails version 4.2.8 Environment production Database adapter Mysql2 SCM: Subversion 1.10.0 Cvs 1.12.13 Git 2.17.1 Filesystem
Redmine plugins: graphviz 0.2.3 mega_calendar 1.7.0 pdf_export_redmine 0.0.2 plantuml 0.5.1

Java

openjdk version "1.8.0_191" OpenJDK Runtime Environment (build 1.8.0_191-8u191-b12-0ubuntu0.16.04.1-b12) OpenJDK 64-Bit Server VM (build 25.191-b12, mixed mode)

Dot

dot - graphviz version 2.38.0 (20140413.2041)

わかりやすいということの定義

Kindleで以下の本を読みながら、「わかりやすい」というのは何なのかを定義されている箇所を抜き書きしてみた。

整理するとわかる

「わかる、というのは心のありようです。自分の分類原理をすべてに適用することです。客観的な分類原理がどこかに存在していて、それが自分に入ってくるのではありません。」

まとまることで「わかる」 「自己を運びて万法を修証するを迷とす。万法すすみて自己を修証するは悟」

小さな意味と大きな意味 「わかるとはただ細部がわかることではありません。わかることの大きな意味も分かる必要があるのです」

浅い理解と深い理解

「意味の違いの比較~使われた単語は結構たくさん思い出せます」

重ね合わせ的理解と発見的理解

「日はよいお天気ですね、と話しかけられたときは実は自分の頭の中でも「今日は良いお天気ですね」と、同じ言葉を繰り返しているのです。そして相手の言葉と自分の言葉とがうまく重なったとき、わかったと感じます。」

・・・山鳥重「「わかる」とはどういうことか。---- 認識の脳科学 ----」筑摩書房(2014)

今後書きたいブログのネタ

時間と集中力の限界で、なかなかブログがかけないでいるけれど、以下のようなネタを書きたいと思ってます。

  1. PomoDoneについて
  2. RedmineAWS+Bitnamiでのインストールについて
  3. RedmineのPluginの紹介

    • Mega Calendar plugin
    • PlantUML plugin for Redmine
  4. Sphinx+Subversion on AWSについて

  5. Atomについて
  6. Excel方眼紙と折り合いをつけた件について

Redmineを用いたプロジェクト管理(1)

Redmineを使ったプロジェクト管理を行っている。Redmineを使ったプロジェクト管理の方法については、いろいろなサイトに情報が載っているけれど、 プロジェクト管理の方法としては、かなり便利になってきたので、便利にしてきた工夫について、少し共有してみたい。

(1) とにかく全員が使えるようにする 当たり前だが、非常に重要。顧客にも使わせる。プロジェクトの責任者にもRedmineガントチャートをそのまま見せて進捗報告をする。進捗報告で変な小細工が入るような資料は作らない。Redmineがすべて。という状態にする。サブコンには見せないとか、秘匿性が高い情報が、とか、あるが、その場合は後述。

(2) 面倒なワークフローは作らない。 ステータスはシンプルに。ステータスはいろいろ変わる。ワークフローによる制限はできるだけ作らない。ステータスの変え方がわからないと、放置される。放置されると、最新化されない。最新化されなくてもよいとされると、ますますされなくなる。

(3) 生の情報は、Redmineに集約する。成果物はSubversionに。極力他のものは使わない。 RedmineSubversionは一体で運用。プロジェクトアドミ的なもの、ノウハウも、すべてRedmine化していく。 Excelは追放し、Redmineで管理すると決める。プロジェクトルール的なものは、RedmineWikiで共有。変更のうち、重要なアナウンスであれば、Newsを使えばいい。

ただ、朝遅刻するメンバーが同僚に連絡する際には、Slack的なツールを使ってるが、あくまでもPCが使えない環境対策。原則としてRedmine一本。

つづくかも。