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

Kernel.#system (Ruby 2.7.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一本。

つづくかも。

ためしに、わかりやすく書いてみる 予算の先議権的な議論

大日本帝国憲法衆議院における予算の先議権は、単純に順序だけの問題に見えて、その実は、とても強い権限だということを理解するべきだ。

まず、予算は非常に重要である。内閣は予算がないとまったく動けなくなる。先議権により、衆議院が内閣予算を棚ざらしにすれば、内閣を潰すことができる。

次に、先議した衆議院の意思は、貴族院に押し付けられることになる。たとえば、衆議院多数党が軍拡を主張し、貴族院多数党が軍縮を主張しているばあい、軍拡の主張は衆議院で予算として含められる。貴族院軍縮にする案にすることはできず、軍拡予算を認めるか、前年予算のどちらかを選ぶことになる。たとえ、貴族院軍縮予算にしたとしても、衆議院で可決されることはないから、前年予算が執行*1されるだけである。衆議院の主張と矛盾しない限りで貴族院は予算を変更することができるだけだ。

 

上の説明の展開は、先議権が重要な問題である予算を取り扱う権利で、かつ、先議権がない貴族院衆議院に対して選択肢を狭められてしまうことを示してみた。抽象化して、権利とは他の人の自由を奪うものだということも説明してもいいかもしれないが、抽象的すぎるとついていけなくなる。このあたりの考察は次の回にしようとおもう。

ともあれ、わかりやすいということを分解すると、その問題が重要であることが示されることと、効果があることを示すことが必要なんだろう、ということまで今回例示できたと思う。

*1:大日本帝国憲法では、予算案が議会を通らなかった場合、前年と同じ予算が執行される。

Nozbeのカテゴリについて

Nozbeのカテゴリは、GTDのコンテキストとして使うのがセオリーだと思っています。 しかし、最近は少し違う要素も取り入れていて、いろいろ試しています。

現在のコンテキスト型のカテゴリは@と:を先頭にするカテゴリで、置かれている環境によって取り組むべきタスクを分けています。 @は場所系、:は使えるデバイス別のコンテキストです。 !は、コンテキスト型といえなくもないのですが、消費する精神的リソースの種類によって分けています。 (waiting for)や、(no task)は、誰かに指示や依頼をしたもので、待ちの状態になっているもの。 Accountabilityがあるものはwaiitng forで、Accountabilityもないが興味がある程度のものは(no task)とする整理です。 IFTTTとEvernote Remindersは、タスクの入ってくる入り口別ですので、コンテキストとは趣旨が違います。 ?Bossと?Clientは、上司やクライアントの意向を確認するタイプのものです。

  • @Office
  • @My house
  • @Train
  • @Meeting
  • @Mail
  • @Local
  • @Trip
  • @Travel
  • :Printed Material
  • :iphone
  • :computer
  • (waiting for)
  • (no task)
  • IFTTT
  • Evernote Reminders
  • !決断
  • !気持ちの切替え
  • !ルーチン
  • !集中
  • !休憩
  • ?Boss
  • ?Client

自分の役割が変わると、それぞれの登場機会が変わるので、ずっと同じ使い方をしているわけではないのですが、 ある程度、自分の管理したいカットでカテゴリが切られていないとなかなか使いづらいものです。