10月より、約５年にわたるデスマーチツアーから帰還しております。
GTDで言うところの「いつかやる」リストがたまりまくってますが、日記もそのうちのひとつ。

ということで、こっちで再開しております～。

しばらく、このアイデアを書き留めておく場所として
ココを使うことにする。
たまたまココを見て、思うところがある方は、コメント欄でどうぞ。

意義
失敗しがちなソフトウェア開発に対する１つの処方箋として、
いわゆるアジャイルなアプローチが提案されて久しいが、
大規模開発には向かない面が多い。
また、小規模開発であっても、大企業向けの業務システム開発には適用しずらい。
ソフトウェア開発では、規模が大きいほど、失敗・デスマーチ化しやすいにもかかわらず、
この「規模の大きさ」に関する部分でのパラダイムシフト的な提案がないのではないかと思い、
何か有効な手立てがないか考えてみたい。

そこで、自分自身は決してミリタリーマニアでもなければ、規律主義でもないが
大規模な組織運営の模範として、軍隊のメタファーを積極的に持ち込んでみる。
ただし、軍隊式とピープルウェアは背反しないし、させないことに十分に注意する。

以下次号。

今更ながら、ちょっとだけマジメに help を読んだので、メモしておく。
ほぼチュートリアルの要約だけど...。

なんといっても最初が肝心！この手順とルールを知っておかないと
あとがすごくメンドウになる。
# というか、やっぱりマニュアルは読むべきだな。

1. 新規プロジェクトを作成
                開始日を決めて OK とする(他は決めなくても OK)。
                ひとまず保存して「ガントチャート」画面を開く。

2. タスクを積み上げる。
                このとき、開始日・リソースは気にしないで、タスクと期間のみを淡々と入力する。

                ※小技その１：
                期間の欄で、数値の後に次の省略文字を付けると、月、週、日、時、分を簡単に入力できる。
                ・ 月 = mo
                ・ 週 = w
                ・ 日 = d
                ・ 時 = h
                ・ 分 = m
                単位は「日」か、もしくは「時間」で揃えるとラクかも。

                ※小技その２：
                期間の欄に ０日(0d)を入力すると、そのタスクは自動的にマイルストーンに設定される。

                ※小技その３：
                定例会議等、周期的に発生するタスクは、画面上部の「挿入」→「定期タスクの作成」を
                使って入力する。

3. タスクの開始日と終了日を決める。
                先行タスクとのリンクをつなげていく。

                ★重要なルール！
                極力、日付自体をいじってはいけない。
                日付を変更したい場合は、「リードタイム」「ラグタイム」と「タスクの分割」を使うこと！
                タスクの行を選択して右クリック→「タスク情報」から、「先行タスク」のタブを選択し、
                「間隔」の欄に +/- で日付を入力して調整する。

                ★大技その１！
                「タスク情報」を表示するには、Shift＋F2 のショートカットが使える。

                ※小技その４：
                明確な締め切り日がある場合は、「タスク情報」から「詳細」タブを選択し、
                「期限」の欄に日付を入れる。
                スケジュール自体は変更されないが、赤い「！」マークが出るので、後で全体をみて
                修正すればよい。

4. リソースを割り当てる。
                まず、「リソースシート」画面で、メンバーを列挙する。

                ※小技その５：
                チーム分けしている場合は、このときグループ名も入力しておくとラクかもしれない。

                その後「ガントチャート」画面で、ツールバーにある「顔が２つ並んでいるアイコン」を
                クリックすると、「リソースの割当」子画面がでてくるので、これを使って割り当てる。

                ★大技その２！
                この画面を出したままにしておけば、「リソース名」のセルを編集するより圧倒的に早く作業できる。

                ※小技その６：
                リソースを複数割り当てたタイミングで、自動的に期間が減ることがある。
                その場合は、画面上部「ツール」メニューの「オプション」をクリックし、「スケジュール」タブを
                クリックして「新しいタスクに対して、残存作業時間を優先するように設定する」のチェックボックスを
                オフにするとよい。

5. 基準計画を保存する。
                ここまで出来上がったら、画面上部「ツール」メニューの「進捗管理」から
                「基準計画の保存」を選択し、「プロジェクト全体」を選んで、基準計画を保存する。

6. 実績値を入力する。
                ★大技その３！
                画面上部の「表示」から「ツールバー」を選択し、「進捗管理」を選んで
                実績情報を入力するためのアイコンを表示させる。
                オンスケであれば、左から２番目の「スケジュールどおりに更新」ボタンを押せば OK.
                そうでなければ、進捗率を 0%, 25%, 50%, 75%, 100% から選ぶか、
                「タスク情報」の「全般」タブにある「進捗率」に数字を入力する。
                (なぜこれがデフォルトで表示されていないのか....理解に苦しむ)

ひとまずここまで。

ちょっとしたことを忘れないようにするため、よく
テキストエディタにメモったりしますよね。
# 要するに Emacs で言うところのスクラッチファイルなわけですが
# 自分はリアルハッカーではなく「丘ハッカー」なので
# Emacs なんか難しくて使えません。
## お気に入りのエディタは、EmEditor(v4std)です。
## ちなみにお気に入りな理由は『"メモ帳"に近いから』(←ここらへんも"丘")。

で、あとで清書したりメールしたりするまでの間、
ふとした瞬間に内容が消えたりすると危ないので
すぐにデスクトップに保存しておきます。
ファイル名は、「名前ごときで迷うのは時間のムダなのじゃ！」と
ハッカー気取りで(←ここ重要)「foo.txt」としています。
ここまでの一連の動作は、ほぼ指が覚えているので、
無意識だったりします。

で、一気に書き終えてエディタを閉じたときに、
デスクトップに忽然と姿をあらわす「ふぉお.txt」という
ファイルを見て、HG を思い出したりしながら
チマチマと「foo.txt」にリネームしたりしています。

以上ですキャップ！

# 付箋紙とか使えよという案は却下。

久しぶりにフツーの本(＝技術書以外)を買った。

以前から読みたいと思っていた「利己的な遺伝子」(89年版)を近所の古本屋で
約半額で捕獲。
読むのが楽しみなのだが、さて、通読するのにどれくらいかかるだろうか？
電車でもベッドでも、のび太なみの速度で寝入ってしまうので
相当かかると思われる。あせってもしょーがないので、ゆっくり読むこととする。
# 一緒に奥田英朗の「野球の国」も捕獲。こっちはすぐ読めそう。

web開発ではもはや必携の「横取り丸」が
おととい update されていたのでメモ。
リリースノートがついていないが、内容的には bugfix のみらしい。
かなーり久しぶりだったので、ちょっとびっくりした。
--
[追記:10/21]
改版履歴がちゃんとありました。
失礼しました。
１年以上ぶりだったのですね。

http://www.m-on.jp/sp/index_forward=special.html#2005062800000761

いやーよかった。
BONNIE PINK「Perfect/Fairground Attraction」
Crystal Kay「Overjoyed/Stevie Wonder」
LENA PARK「Sweet Child O' Mine/Guns N' Roses」(!)
CHEMISTRY「見つめていたい/THE POLICE」
など。
渡辺等のベースもさることながら、キラキラ系担当 Key. のタオルバンダナの
にーちゃん(名前わからず)がツボをおさえたプレイでなかなか GJ.

業務システム開発で新規にサーバを立てる場合、
本番機のほかに開発機も用意してもらわねばならない。

開発機側のスペックは、大抵の場合、本番機のスペックを
何分の一かにスケールダウンしたサイズで見積もられるのが
通例のように思えるが、実は開発機にこそ、十分なパワーが
求められるのではないかと感じることがしばしばある。
実際、自分がこれまで参加したプロジェクトを振り返ってみると、
過去３つくらいのプロジェクトにおいて、開発工程が進むにつれて
開発機のパワー不足が問題になっていた (今のプロジェクトも...)。

どういうことかというと、本番機には基本的に業務運用に使う
１つの環境だけを launch すればよいのに対し、開発機には
たくさんの環境を launch する必要があるからだ。
たとえば、以下のような具合である。

・メインブランチの結合試験環境
・サブブランチ１の結合試験環境
・サブブランチ２の結合試験環境 (以下ブランチの数だけ続く)
・総合試験環境
・ユーザートレーニング環境
・データ移行準備環境

ただし、時期が過ぎて並行開発や初期移行、トレーニングが
済んでしまった後では、それほどのマシンパワーは必要なくなる。
リッチな開発機を立てたところで、それが必要となるのは
ほんの一時期だけであることが多いため、実際には最初から
十分なマシンリソースが用意されることは滅多にない。
ということで、結局は開発者たちが、ただでさえ忙しい時期に
さらに開発機のリソース不足という問題にアタマを悩ますことになるのだ。

しかし、悩んでも苦しんでも、解決方法としてはそれほど
バリエーションがあるわけでもなく、環境ごとの利用スケジュールを
(マスタスケジュールに影響が出るのを覚悟で) ちょっとづつズラすか、
買うなり借りてくるなりして増設するか、といったところだ。
# 大抵、開発者から不満が上がって PM に相談がもちかけられ、
# PM はスケジュールの遅延と増設費用とを天秤にかけた結果、
# 結局増設するということになることが多いのではないだろうか？

ちょっと前から、「仮想化」というキーワードのもと、
動的なマシンリソースの配分を可能とする技術が出てきている。
これをうまく使ってやりくりできるようになると良いのだが、
この機能が搭載されているのがハイエンドのサーバ機だけだったり、
最終的にトータルでみて余った資源はどうしようもない(単なる無駄)
こともあったりして、まだいまいちピンとこない。

▼各社の仮想化技術
Sun／hp／IBM

開発の計画段階から、開発機のリソース不足を予見するのは
なかなか難しいところだが、結局のところ、最初から費用なり
時期なりを織り込んでおくのが今のベストの解なのであろう。

# と、もっともらしいことを書いたが、これは
# 次回以降に参加するプロジェクトの時に
# 忘れないようにする、自分向けのメモです。

ロイクソップを買いに言ったら
なぜかジノ・ヴァネリとかも買ってました。
ってか、反則ですよ TOWER RECORDS さん！
AOR 特集ってナンですか!! 試聴板30枚も揃えて!!
2005年ですよ今。

いまさらながら、↓コレ安すぎですね。
E-MU Proteus X

桁が１つ間違っているのかと思ったよ...。
これのために PC 買っても元が取れる値段だと思います。
眠っているとはいえ、家の Proteus1/XR や E4K が不憫でなりません。
特に E4K はデザインが気に入っているので、いつか直して使ってやろうと思っていたら
サポートが終了していることを今知りました。がくっ。