Weblog on mebius.tokaichiba.jp

「課題」とは何ぞやという課題

ソフトウェア開発の現場では、よく「課題管理」という言葉を目にする。筆者はソフトウェア開発（間接業務含む）以外の仕事をしたことが無いので、他の業種ではどうかわからないが、特にソフトウェア開発の世界では、「課題管理」という言葉が多用される、というか、安易に使われているような気がする。まるで、ソフトウェア開発というものは、計画通りの進捗を阻害する要因は全て「課題」であり、「課題」を見つけて１つ１つ「解決」していけばいいだけのもの、と言わんばかりである。実際、現場から離れて「プロジェクト管理」なる仕事をする者の中には、本人の業務はMS Projectなどを使って進捗をグラフィカルにするだけの「進捗管理」と、MS Excelなどを使って「課題管理表」に行を追加して「状態」列を「完了」にして行を灰色または非表示にするだけの「課題管理」の2つしかしない者も少なくない。

筆者はこれまでに10以上のプロジェクトを見てきたが、大体どこのプロジェクトにも開発計画と「課題管理表」があり、解決していない「課題」が残っていると上司に追及されるような、外部報告用の「課題管理表」に挙げられた「課題」はどんどん「解決」して行くのに、現場で管理する本当の課題管理表に挙げられた「課題」はどんどん溜まって行く、という傾向があるようである。

少し気の利いたプロジェクトなら、報告用でない現場の課題管理表は、解決方法がわかっている「課題」とそうでない「課題」とを分離して、さらに前者の内作業計画もされたものは計画に、計画無しで作業するものは「TODO」に移動するなど工夫するので、ある程度、何らかの似たような性質のある「課題」に分類されるのだが、それでも、感覚的に粒度や問題の次元が異なる「課題」が同じ管理表にあることがほとんどである。

筆者も一応プロジェクト管理の仕事をしていたことがあり、延々と課題管理表を作っていたある時、「課題」って一体何だろうと思って、相当思いふけったことがある。その時には自分なりの答えを出したのだが、先週、再び混乱することがあったので、もう一度自分なりの考えを整理する。

実際の仕事上で「課題管理」を目的とする時の「課題」の意味は結構広く、緊急のトラブルやバグを除くと、イレギュラーに発生する、計画通りの作業遂行の障害となり得る要因は全て「課題」と呼ばれることがあると思う。筆者が管理していた課題管理表はそのような状態だったので、それらの課題を、管理表上で以下のように分類した。

問題

解決案が想像もできていない課題。

テーマ

長期プランで対応する課題。

調整事項

外部と調整して対応する課題。

調査事項

内部で調査する課題。分析事項含む。

検討事項

内部で検討して対応する課題。決定事項含む。

ToDo

単なる作業、またはすることが明確な課題。

A.I.（アクションアイテム）

ToDoと同義。会議に関係する文脈において使用され、物事を一歩進める意味合いを強めるために使用される。または、会議したことによって明確になったこと、その会議をしたことに意義あったことを強調するために使用される。

リスク

課題となる可能性のあるもの。

mystery

不思議なこと、謎なこと。

もし、課題管理表とは別にToDoリストとリスク管理表があれば、上記の内、ToDoとA.I.とリスクはそちらに移動されていたであろう。

これは7年くらい前に考えたことだが、今見てもまあまあ的を射ていると思っている。しかし、世の中にはそれでは「課題管理」とは呼べない、それでは「課題管理」ができないと言う人々が居る。曰く、「次のアクションが明確になっていないものは『課題』ではなくて『問題』である」なのだそうだ。
課題表の「対策」欄に次に行うべきことを具体的に書けないのなら「課題」じゃないから課題管理表に書くな、課題管理表に記入するのならその対策を具体的な「アクション」に「落とし込」んでからにしろ、という訳である。

「次のアクションが明確になっていないものは『課題』ではなくて『問題』として区別する」という考え方が広く出回っていることは、筆者も知っている。大体、

リスク

まだ具体的な障害になっていないが、障害になり得るもの

問題

具体的に発生した障害

課題

対処すると決まり、対処方針が明確になった問題

ToDo

担当者と期日が明確になった課題

というような定義で、「リスク」の一部が「問題」になり、その一部が「課題」になり、その一部が「ToDo」になる（または、そのように「細分化」／「break down」する）というようにして、「リスク」と「課題」と「ToDo」の区別を明確にしようとか、解決できないままで残る「課題」を発生させないようにしようとする発想によるものだろう。

しかし、このような考え方は机上の空論だと筆者は考えている。その理由は以下である。

• 大抵、「課題」ではなく「問題」だとして「課題管理表」から除外されたものをどのようにして管理するのかについて言及されない。
  そもそも、「問題管理」などという言葉は見たことも聞いたこともない。課題管理において解決困難な課題が存在するからと言って、難しい課題への対策を考えるのではなく、難しい課題を「問題」と言い換えることによって、「課題管理」だけをやりやすくしようとしているだけである。
  もし「問題管理表」が別に作られたら、それらが「課題管理表」にあった時と同じ問題が「問題管理表」に生じるだけである。


• リスクマネジメント上のリスクが現実の問題となっても、リスクは依然リスクである。
  あるリスク要因が現実の問題となるのが１度きりとは限らないし、実際には発生しなければそれがリスクでは無かったことにはならない。リスクは課題の確率事象であり、リスクかどうかと実際に発生したかどうかは関係がない。
  リスクが課題管理表やToDoリストに（コピーされたのではなく）移されたのなど見たことがない。もし「リスク」が「問題」にbreakdownできてしまうなら、「リスク」はゼロにできるということになってしまい、リスク管理というものが意味を失うだろう。


• 次のアクションが明確でなければ「課題管理表」に書くべきでないというのは、上司が部下に対して、問題を報告するなら解決方法も一緒に持って来い、と言ってるようなものである。
  それはつまり、解決方法がわからないなら問題を報告するなということであり、解決方法を考える責任を自分で負いたくないということである。


• そもそも、通常の会話で、「課題」とか「問題」とかいう言葉を次のアクションが明確になっているかどうかで使い分けることは考えられない。「それは今後の課題だ」「難しい課題だ」と言う場合、対応方針が明確になっていることは稀であるし、「それは問題だ」と言うのは、不正や否定のニュアンスを含むこともある。
  もしアクションが明確かどうかで用語を変えたいのなら、「課題」や「問題」という単語を使うべきではないと思う。（そのような呼び分けに興味が無いので、それらに代わる造語を考える気もしない。）


• 次のアクションが明確になっているかどうかは、人による。
  能力や権限がある人ならすぐに何らかの行動が起こせる課題でも、人によっては他人に依頼するか、行動を起こす前の準備が必要な場合がある。
  対処できる人に対処する暇があるかどうかで「課題」か「問題」かが異なるのでは、「課題」の定義として適当だとは到底思えない。

例えば、「仕様書の完成が遅れているため、詳細設計に手戻りが生じている」というのは、次のアクションが明確でないから、それは（課題表に書くべき）「課題」ではなくて「問題」であり、「仕様書の完成が遅れている原因を分析してボトルネックを特定する」や「仕様書の完成を急ぐ為、誰々に応援を要請する」は次のアクションが明確だから「課題」だと言う。
しかし、「ボトルネックを特定する」は明確なアクションと言えるのだろうか？なぜ原因を分析する前にボトルネックの存在がわかるのだろうか。単純に担当者の作業量が増加しているのかも知れない。分析してみないとわからないのではないか。もし「ボトルネック」の定義の違いだ、作業遅延の原因となり得るものは全て「ボトルネック」と呼ぶことが可能なのだ、と言うのなら、「ボトルネックを特定する」は「分析する」と同じ意味になり、その文に意味が無くなってしまう。
そして、「仕様書の完成が遅れている」のが課題なら、自動的にその原因の分析が次のアクションに含まれるのではないだろうか。つまり、課題管理表に「仕様書の完成が遅れている原因を分析してボトルネックを特定する」と書かれていても「仕様書の完成が遅れている」と書かれていても、何ら変わりはない。
課題を表す文章が「すること」を表していないから問題、とかいう国語的な話は興味が無いが、日本語の語尾が「〜する」だったら次のアクションが明確だとは限らないし、「〜が無い」とかでも十分に明確なこともあるだろう。むしろ、「課題」管理表に「すること」が並んでる方が、筆者にとっては遥かに日本語として気持ち悪い。

もし、具体的な次のアクションが決まらない限り課題管理表に挙げられないのなら、それまではその「問題」はどのようにして管理する（最低、記録しておく）のだろうか。
ひょっとして、どんな課題でも、即座に次のアクションを決めながら課題管理表に記入できるという前提があるのだろうか。
「課題」は解決の仕方、対処方法が1つとは限らないし、解決するコストが高ければ回避するしかないこともある。そんな場合、その課題は回避すると決まるまで課題管理表に書かないのだろうか。
課題というのは、対策をこれから考えるために、対策が空欄のままでも存在するのが当たり前だと思う。次のアクションが決まっていなくても、課題が報告、管理されないよりは報告、管理される方が良いと考えるのが普通であろう。
それに、次のアクションが明確になっていれば、それは課題ではなくてToDoなのではなかろうか。

という訳で、次のアクションが明確でなければ「課題」ではなくて「問題」だとか言うのは問題のすり替え、問題の先送りでしかないと思うのである。

続きを読む "「課題」とは何ぞやという課題"

Macのマルチ画面環境の設定

11.6インチ液晶のMacBook Airを買って、13.3インチ液晶の白MacBookをお蔵入りさせた（CD/DVD-ROMドライブが必要な時は引き続き使うのであるが）ら、やっぱり11.6インチのLCDは小さく、使用頻度は激減したが一応まだ残しているWindowsデスクトップPCの17インチのモニターに繋ぎたくなった。
しかし、MacBook Airからケーブル１本でMini DisplayPortからTVにHDMI出力できるらしかったので、やっぱり26インチの液晶TVに接続することにした。

ケーブルを入手して実際に繋いでみると、一発でMacBook Airと同じ画面がTVに表示されて、「ディスプレイ設定」画面が表示された。出力画面サイズを変えたりTVの設定を変えたりしてもどうしても文字がぼやけるが、それでも画面が大きいのは快適であることがわかった。
出力解像度は1600x900（LCDとのミラーリング無し）、TV(Panasonic TH-26LX60)側の設定は、試行錯誤の末、
バックライト「+10」（TV番組受信用は+30）、
ピクチャー「+25」（TV用は+30）、
黒レベル「0」、
色の濃さ「0」、
色あい「0」、
シャープネス「±0」（TV用は+10） 、
色温度「中」（TV用は高） 、
エッジ補正「中」（以下TV用は無設定）、
細部補正「弱」、
ガンマ補正「中」、
黒伸長「+8」、
白文字補正「+8」
にした。これでLCDが狭いことは全く問題でなくなった。13.3インチモデルを買わなくて良かった。

さて、ケーブルを抜き差しして気付いたのが、外部ディスプレイの解像度やLCDをミラーリングするかどうかの設定はずっと残るのに、外部モニター使用時のウィンドウの配置は残らないことだ。何かウィンドウを外部モニターに移動し、ケーブルを抜くと外部モニターにあった全ウィンドウがLCDに移動するが、もう一度ケーブルを挿しても全てLCDに残ったままなのである。これは、特にHDMIの場合、テレビの電源を切ると、ケーブルが接続されたままでも、外部ディスプレイと切断されたことになってしまうので、その状態を保つようにPCをスリープして復帰させるには、

1. スリープ
2. TV OFF
3. TV ON
4. 復帰

という手順を守らなくてはならず、これを間違えると、せっかく外部モニターに移動した全ウィンドウがLCDに戻ってしまう。これでは外部ディスプレイを使いにくい、というか使えない。

それを解決するアプリケーションとして、Forget-Me-NotとStayを見つけた。"Stay"の方が高機能で、外部ディスプレイの着脱に関係なく、ウィンドウの位置を保存することができるツールであるが、明示的にウィンドウ位置の記憶を指示する必要がある（ケーブル差しで自動的に復帰するがケーブル抜きで自動的に保存されない）のと、有料ソフトなのがいまいちである。Forget-Me-Notは、作者のページの見た目が誤解を招くが、フリーソフトであるし、ケーブルを抜いた時にウィンドウ位置が記憶されるので、Forget-Me-Notを導入した。

さてさて、LCD側にJava API Referenceを表示して、EclipseのウィンドウをドラッグしてTV側に移動して、何かJavaアプレットのコードを開いて、これぞ省スペースで理想的な開発環境、と満足してデバッグを開始すると、アプレットのウィンドウがLCD側に表示されてしまうのが非常に面倒であることがわかった。その時大体マウスカーソルがTV側にあるので、アプレット上のボタンを触るために、マウスカーソルを長距離移動しないといけないのである。
それを解決するために、色々調べた。こういう時は、
(a) アプリケーション毎に出力先ディスプレイを設定する
(b) 外部モニターを主にする
(c) キーボード操作でウィンドウを別モニターに移動する
といった方法が常道である。他には、(d)アクティブウィンドウが切り替わった時にマウスポインターがウィンドウ上に無ければ自動的にアクティブウィンドウに移動させるという解も考えられるが、自分が意図しないタイミングでダイアログとかが開いて、ポインターが勝手に移動するのは不便であろう。それに、フォーカスロストした時にワンクリックでフォーカスを復帰させることができなくなるのは不便に違いない。

(a)については、前のMacに最初から入っていたSpaces（仮想デスクトップ）なら、アプリケーション毎にどのデスクトップで開くかを設定できたのだが、新しいMacにはSpacesが無く、代わりにMission Controlというのはあったが、同じような設定をする方法がわからなかった。

(b)は、割と意外な方法で実現できる。「ディスプレイ環境設定」の「調整」ペインを開くと、外部ディスプレイとLCDとの位置関係と、メニューバーをどちらに置くかを決められるが、このメニューバーがある方がメインディスプレイになり、メニューバーを外部ディスプレイに置くと、新たに開くウィンドウは全て外部ディスプレイで開くようになるのである。上記の問題はこれであっさり解決した。

(c)は、ジェスチャー入力を拡張するフリーの超人気ソフト、BetterTouchToolで実現できるので、他の方法を探すまでもない。筆者は元々ジェスチャー入力でなくキー操作でのウィンドウのモニター間移動に病みつきなので、上記の問題とは別に、

Command+Opt+C

Move Window to Next Monitor（隣のモニターへ）

Command+Opt+E

Maximize Window to Next Monitor（隣のモニターで最大化）

という設定にした。

(d)については、意外と方法が見つからず、LazyMouseという、ダイアログが開く時にマウスカーソルを自動的にデフォルトのボタンに移動させる有料ソフトがあったのと、java.awt.Robotクラスを使ってマウスカーソルを移動させるJavaアプリを自分用に作って常駐させている人が世の中に存在するらしいのをどこかで目にしたくらいだった。

続きを読む "Macのマルチ画面環境の設定"

Dia 0.97.2の半円状の矢印が消える問題の修正パッチ

Dia 0.97.2-1には、ジグザグ線の先端の矢印の形状が開いた半円の場合、先端のY座標によっては表示されなくなってしまう不具合がある。例えば、UMLシートのReceptacle（要求I/F、Required I/F）の先端を上向きか下向きにして、Y座標が10〜50の間に先端を持って行くと、先端が消えてしまう。これは表示上だけの問題ではなく、その状態で図を画像ファイルとしてエクスポートすると、Diaがクラッシュしてしまうこともある。

筆者はMacPortsのDia 0.97.2-1とFreeBSDの0.97.1とでこの現象を確認した。

それを修正するパッチを作ったので、公開する。
patch-arrow.diff（MacPortsでのみテスト済み）

MacPortsでこれを使うには、
/opt/local/var/macports/sources/rsync.macports.org/release/ports/gnome/dia/Portfile
に

patchfiles patch-arrow.diff

という行を足して、Portfileがあるディレクトリにfilesというサブディレクトリを作って、そこにこのパッチを置く。

続きを読む "Dia 0.97.2の半円状の矢印が消える問題の修正パッチ"

MacPortsでPython対応Diaをインストールするには

先週、今更ながらPythonでDiaのプラグインが作れることを知ったので、早速試してみようと思ったら、MacPortsでインストールしたDia-0.97.2ではPythonが使えないことがわかった。
ソースコードからDiaをmakeする時に、configureスクリプトに--with-pythonを渡す必要があるのだが、MacPortsのDiaのPortfileがそうなっていないのである。そのようにするMacPortsのパッチは既に作られているが、これはかなり昔のMacPortsに対するパッチで、現在ではそのまま当てられないのはもちろん、それに従って手でパッチを当てても、configureがエラーになるだけだった。

エラーログを見ると、

:info:configure checking for libpython2.7.a... not found config
:info:configure configure: error: could not find files required to build python plugin

というように、どうもインストールされたpy27-gtkにうまく対応できないようだ。

試行錯誤の末、かなり強引だが、以下のようにすると成功した。
（このブログが提供するPortfile-dia.diffとpatch-configure.diffが~/Downloadsにあるとする）
1. libpython2.7.soの作成

cd /opt/local/lib
sudo ln -s libpython2.7.dylib libpython2.7.so

2. Portfileの修正

cd /
sudo patch -p0 < ~/Downloads/Portfile-dia.diff

3. configureのパッチの用意

cd /opt/local/var/macports/sources/rsync.macports.org/release/ports/gnome/dia/
sudo mkdir files
sudo cp ~/Downloads/patch-configure.diff files/

4. port install dia

sudo port install dia

続きを読む "MacPortsでPython対応Diaをインストールするには"

Mac間のデータ移行

物書き用に使っていた白いMacBook MB402J/Aは、使い心地も外見もとても気に入っていたのだが、半年くらい前から、トラックパッドのボタンが固くなって、クリックする度に、引っ掛かった金属片が弾かれたようなガチッガチッという音がするようになり、さらに、たまに固くて押せない（押す位置を変えると押せる、押せないのはどの位置でも起こる）こともあり、ストレスを感じるようになってしまった。
MacBookのバッテリーパックが膨らんで、真上にあるトラックパッドを押し上げて異常が出るというのはよくあることらしく（参考リンク [1] [2] [3] [4]）、筆者のMacBookもそれが原因のようで、バッテリーを外して使うと問題が起こらなかったのだが、MacBookは安全設計で電源プラグが軽く外れるようになっているので、バッテリー無しで使うのは危険すぎる。かといって、トラックパッドでクリックしにくい問題だけのために１万円以上かけてバッテリーを交換する気にはなれない。デスクトップ用の外付けのトラックパッドであるMagicTrackpadを購入するという方法もあるが、6,800円するし、もう少しバッテリーが膨らむと全くクリックできなくなるらしいので、そうなったらMagicTrackpadを購入したことを後悔するだろう。マウスを買うのも同じリスクがあるし、筆者は元々マウスというデバイスが苦手なのである。

半年悩んだ末、悩む時間が勿体なく思うようになったので、携帯性を高めるため、自分への誕生日プレゼントと自分に言い訳して、ついにMacBook Air MC969J/Aを買ってしまった。本当はMC968J/Aを買おうとしたのだが、誕生日の前日に慌てて買いに行った日本橋のどこにも在庫が無かった。

新しいMacの電源を入れたら、セットアップウィザードの数画面先で、別のMacからのデータ移行のメニューが出てきた。ネットワーク経由で別のMacから直接コピーするか、外付けHDDのTimeMachineバックアップから取り込むかを選択できたが、ネットワーク経由でコピーし始めると「残り8時間」とか出てきたので、中断してTimeMachineバックアップから取り込んだ。30分くらいで終わった。すると、アプリケーションからDashboardやDockメニューの配置からFinderのショートカットから「最近使ったフォルダ」に至るまで、前のMacの環境が完璧に再現された。起動したら、多用しているスティッキーズのメモが前のMacと全く同じ位置に現れて、感動した。暫くEmacsやらEclipseやらを触っていたが、キーボードとトラックパッドの違い以外、全く違和感を感じなかった。

しかし、1つだけ問題が起こった。iTunesを起動すると、データも設定も全く引き継がれていなかった。DRM（著作権管理）か何かの都合で、パソコン間で自動的にコピーされるのは問題があるのだろうか、と思ったが、ネットで調べてもそんな情報は見つからない。むしろ、どこを見ても、iTunesライブラリもiPodの設定も全て自動的に引き継がれた、「移行アシスタント」完璧すぎる、と書いてある。最初のネットワーク経由の移行アシスタントを電源断で中断したのが悪かったのだろうか、と、Command+Rを押しながら電源ONでMacOSXユーティリティを起動してTimeMachineバックアップからのリストアをやり直したり、Lionの再インストールをやり直したりしたが、同じだった。

5回目の移行アシスタントにはネットワーク経由でユーザーアカウントを移行させたら、iTunesのデータが完璧に引き継がれた。とりあえず全て移行できたので、そういうもんか、と思って、それ以上追究するのを止めたが、数日後、同じ外付けHDDを新しいMacのTimeMachineバックアップにしようとして、原因がわかった。外付けHDDの容量が少ないので、前のMacでも、~/Music/iTunesをTimeMachineバックアップの対象外にしていたのだった。

続きを読む "Mac間のデータ移行"