今日はゆず湯にした。
妹からもらったゆず使用。
とってもよい気分だー。
明日はゆずポンで湯豆腐でも。
というわけで1月1日アメリカから里帰り(仕事)した友人とちょっと話した。
お互い、複雑かつ煩雑な作業をしているなーという話になった。
で、最近考えた複雑かつ煩雑な作業を間違いなくもれなくこなすための方法を
ここに記しておこう。
最近流行のライフハックの一種か。
そこらへんに転がっているライフハックって、単なるライフチップスだと思うな。
ライフハックというのはライフスタイルの変更を伴うもっと本質的なものだと思う。
まあそれはともかく。
見直してみると見にくいが、とりあえずアップしてしまうー。
長文。読むには以下の「続きを読む」をクリック。
煩雑な作業や複雑な工程は神経を使う割合が高い。
そのうえ間違えやすいのでストレスがたまり、作業効率が落ちてしまう。
そんな作業をうまく処理するための方法をいろいろ考えて実行してみた。
自分の場合、これはプログラミングのことで煩雑な作業が入れ子になっているのが特徴だ。
ネットで調べていろいろ試してみたがなかなかしっくり来るものがない。
だいたいはプロジェクトの管理みないなことになる。
現在のところ自分で考えた以下の方法がよいと思っている。
名づけて「XMLチェックリスト」
用意するものはコンピュータ(紙ではうまくいかないので)
文字に色がつけられるエディタ。
できればアウトラインプロセッサ。nami2000 を推奨。
まず複雑さと煩雑さの解消に時間と手間をかける、と決心する。
若く短期記憶がよろしいときはこんな手間をかけることはなかった。
3ヶ月くらいの作業なら頭の中にすべてキャッシュしておけたから。
でも今では3ヶ月目には1ヶ月目にやったことを忘れてしまう。鳥頭×20。
これでは仕事にならん。
そこで実際の複雑な作業を「時間をかけて単純なリストの管理をする」という作業に
置き換える。
これで、煩雑さと実作業を分離することができる。
このとき使用するリストがXMLチェックリストだ。
このリストはその形に意味がある。
そして
1 どこから始めればよいのか一目瞭然である。
2 作業の量がわかりやすい。
4 進行状況がわかりやすい。
という特徴がある。
この考えを実現するアプリを作成すればグループの作業にも使えそうだ。
そのリストの作り方は以下のとおり。
たとえば壁紙を張り替える作業を考える。
もっとも単純な最初のリストはこうだ。
1行目 <壁紙を張り替える> ← 作業の内容を書く。
2行目 ← 作業の終了を書く。
XMLという記法なので、項目をかぎ括弧でくくっておく。
その作業の終わりを同じくかぎ括弧で書き、頭にスラッシュを入れておく。
大まかには以上で終わりだ。
ルールは単純。
作業の始めと終わりを書き、その中の作業はその2行の間に書く。
壁紙を張り替える作業をもう少し分析すると、
壁の前の家具をどける、床が汚れるのを防ぐために紙を敷く。
壁紙が家にあるか確認する。
無ければ買ってくる。
など、細かな作業がたくさんあることがわかる。
あとから必要な作業が発生すれば、必要な位置にその作業を書き込む。
後から作業を追加することが前提となっている。
( だから紙ではスムーズにいかない )
まず、作業を一つ1行目と2行目の間に書き込む。
するとこんな風になる。
1行目 <壁紙を張り替える>
2行目 <壁紙があるかどうか調べる />
3行目
2行目の /> というのはその行で開始と終わりをあらわしている。
わざわざ2行に分ける必要が無い場合はこんな風に書く。
ここでのポイントは2行目を右にずらしていること。
これがXML風チェックリスト一番のポイントだ。
すべて書き込んでみるとこんなふう。
<壁紙を張り替える>
<壁紙があるかどうか調べる />
<家具をどける>
<紙を敷く />
<古い壁紙をはがす />
<壁紙を張る />
<紙を敷く (紙を片付ける) />
家具をどける 家具を戻す>
時前にとりあえずこれだけ書いたことにする。
当然、リストの上から取り掛かることにするが、壁紙が無いことが判明。
作業を追加する。
1 <壁紙を張り替える>
2 <壁紙があるかどうか調べる />
3 <壁紙を買ってくる />
4 <家具をどける>
5 <紙を敷く />
6 <壁紙をはがす />
7 <壁紙を張る />
8 <紙を敷く (紙を片付ける) />
9 家具をどける 家具を戻す>
10
そのとき、上のように3の場所に一段下げて追加する。
これで、2の作業の結果増えた作業が3だということが一目でわかる。
ある作業をするのに別な作業が必要だと判明したようなときに特に有効だ。
また、一つの作業の中に複数の並列する作業をする場合など、作業の終わりを確認する
必要がある場合にも大変有効だと思う。
人から頼まれた割り込み作業などもこのように付け加える。
ただし、まったく無関係な作業は、別なものとして一番下につけたり
別ファイルにしたほうがよろしいかと。
請求書をだしてー、などというリクエストは一番下に付け加えればよい。
テキストに色がつけられるエディタを使用して、終了した作業は色をつけておく。
まとめると、
1 タグを使用して記述する。
2 子作業は、右にずらして書く。
3 終了のタグを忘れずに書く。
4 タグの中には終了する条件を忘れずに書く。
5 終了したら、時間を記録しておく。
数日にわたる場合は日付も書いておくとなお可。
行番号は書く必要なし。
終了時刻はなるべく書いたほうがよろしい。
1 <壁紙を張り替える> 10:00 開始時刻
2 <壁紙があるかどうか調べる />
3 <壁紙を買ってくる /> 12:00
4 <家具をどける> 12:30
5 <紙を敷く />
6 <壁紙をはがす /> 14:00
7 <壁紙を張る /> 16:00
8 <紙を敷く (紙を片付ける) />
9 家具をどける 家具を戻す> 18:00
10 18:30
メリット
1 必要な作業が一目で見渡せ、もれも無くなる。
2 進行状態が一目でわかる。
3 どこから作業するべきか、計画が直感的に立てやすい。
4 作業の複雑さを気にする必要がない。
いくら複雑な作業でもリストがちゃんと管理できていれば問題ない。
5 作業の記録としても使えるので、日報の代わりにもなる。
6 慣れてくると事前の分析も細かくできるようになる。
7 作業によっては適当な場所から始められる。
8 終わりのチェックがあることにより、現在の作業さえ気にしていればよい。
割り込みがあっても優先度だけ気にすれば後回しでも問題ない。
9 現在の作業を中断しやすい(中断したところから再開するのが簡単)
段取りのうまい人は頭の中でこんなことが出来るんだろうな、と思う。
自分はとても無理なので、コンピュータの力を借りよう。
以下はこのチェックリストを使用した実例。
最初に使ってみたバージョン 2007-11-26
終了したものを区別するため、色が変わっている。
優先順位が一目瞭然だ。
深いところ(右側に書いてある事項)を終わらせないと左側が終わらないことがわかる。
同じ階層にあるものはどこからやってもよい。
これはインターネットの商品販売サイトに機能を追加するための作業を表している。
最初なので正しいXMLチェックリストになってない。
商品を追加する'
'<テストページに選択できるように追加する>
支払い方法のテストを行う。
'支払い方法が正しく出てこないので修正する
'Util.java 更新 デバッグコード削除 + 支払い方法テストコード追加
'Util.java アップロード & make'
'動作確認
'Check.Util で spSof を使用している部分がある'
'修正
'Check.Util.java で SPSofを使用しないように修正'
'Check.Top.java でエラーが起きたので修正'
'BitCash支払い画面へ遷移してしまうので Check.Top.java 修正 '
'デバッグと絡んでいた。Acceptに遷移するように修正した。'
'CartDAO の loadCartで落ちている。(XXさんテスト)
'CartDAOデバッグコード組み込み
'rtailが無いのは cart.setShopo(cx.sp_no, cx.gr_no);が無かったため
CartDAOデバッグコード削除.UP.make
CartDAOのアップ、make
CartDAOのコミット
'Check.Top.java テストコード削除
Check.Top.java 動作確認
Check,Top,java をコミット
'動作確認
's_soft のテストデータがシェアとProにちゃんと分かれていない。
'というか、データ不足だったので追加する。
Payment テストコード追加
Util.java テストコード削除
Util.java 動作確認
Util.java コミット
'Payment.java Util.java 支払い方法確認
'Payment.java テストコード削除
Payment.java アップ、make 動作確認
Payment.java コミット
'Util.java テストコード削除
'Util.java アップ、make 動作確認
Util.java コミット
テスト仕様書に書き込む。 16:50
テストして終了
改良した最新バージョン 2007-12-20
実際のリストの名前を一般的なものに変更してある。
なかなか複雑で処理も多いが混乱も無く終了することができた。
また、途中で気が付いた疑問や調査の必要な事項なども書き込み、
その結果も書いておいた。それは後で検索するのにも便利だ。
'<レコード作成手順の変更>
'
'
'
'
'check.Util.get_id_fromseq()
'Check.Bill
'String id = Check.Util.get_id_fromseq();
'Pro.log.debug("Check.Bill. get_id_fromseq : " + tr_id);
'
'get_id_fromseq('v') の作成
'get_site_id() の作成
'get_domain の作成
'
'style.cssコミット 17:07
'
'<トランザクションが正しく動いているか確認する>
'<途中でエラーを起こす />
'<途中で例外を起こす />
<レコードが作成されていないこと />
12/13
'Util.java テストコードの削除
'Util.javaアップ
Util.java テスト
Util.java コミット
12/13
'
'<現在はどこからも呼ばれていない />
' 移動
'
'bas でamountが正しく入っていれは完了
'正しく入っていい無いのでjava で作成した
'
'
'型が違っていた
'
'
' utilでうまくいったら更新する
'
'
<カードの判断式は正しいか カード=30 />
'
'<コネクションの確認 />
'結果 payment.gettrancon で nulpo エラーになる。
' test から payment が取れるか確認する
'
' create2 をトランザクション対応に変更する
'
'
' create2 をトランザクション対応に変更する
'
' アップ
'make
'確認
'コミット
「 注 トランザクションは、tran tran_user のみ」
'
'
'
'
' アップ
' 確認
' コミット
'
'
' アップ
' 確認
' コミット
'
'
'
'Bill.bill テストコードの削除
'Bill.billアップ
'Bill.bill テスト
'Bill.bill コミット
'
'アップ
'テスト
' コミットできるか
' ロールバックできるか
'コミット
'
'
' アップ
' テスト
' コミットできるか
' ロールバックできるか
' コミット
'
'
'
'
'
'全体的にロールバックできるか。
やらない
'エラーになった場合は何を表示するか
'
'
'レコード作成手順の変更>
おしまい。