nDiki : 計画

ソフトウェア ガントチャート 目標 Linux GTD 開発 書評 GanttProject 書き方 プロジェクトマネジメント Windows インストール 日本語 見積もり コミュニケーション PERT 図 ソフトウェア開発 目標による管理 Firefox TaskJuggler 時間管理 問題解決 画像 Eclipse LABI品川大井町 アイデア Web ブラウザ OS 納品 メール

■ 成功するビジネスプラン

新しいアイデアをもとに新しいソフトウェアを開発・販売あるいはサービス提供を行おう。

開発についてはいろいろ学んでいるけれど、もっと大きな視点でどう事業化していくかという点についてはほとんど理解していない。 どういったビジネスシステムでそれを実現していけばいいのかわからない。 どのようにプランニングし、提案していけばいいのか正直よくわからない。

何を分析して、何を考え、何を書けばよいのか。

まずは入門書にあたろう。ということでまずは「成功するビジネスプラン 日経文庫」を読んでみた。

本書は、事業や顧客の分析といったビジネスプランを立てる上でのフレームワークから、具体的な事業計画書の書き方、財務計画の立て方までを解説。-- (表紙裏 [POINT] より)。

新書サイズということで深くはないものの、ビジネスプランを作成する上で必要な分析のフレームワークが一通り紹介されているので、どんな事を考えなければならないのかが分かってきた。

さらにビジネスプランの構成が説明されているので、まずはこれに従ったアウトラインで書きはじめることができる。

三色方式で線を引きながらでも1日で読めてしまうので、急にソフトウェア製品/サービス企画を具体化する必要がでてきた時に、慌てて読むのになかなかよい1冊である。 で、書きながら詳細を知りたくなった点を他の書籍で補っていけばよいだろう。

ただ財務計画についてやはり別途基礎知識がないと駄目だな。

[ 書評 ]

• Joel on Software - 必読書 (2008-08-14)
• PLANNING に違う期待をしてしまった「PLANNING HACKS!」 (2007-07-12)
• 開発の現場 Vol.004 「上流脳」をつくろう! (2006-04-14)
• 個人目標設定における課題 (2006-02-06)
• ソフトウェア技術者御用達のプロジェクトマネジメントツール TaskJuggler (2007-04-23)

■ 完成度まだまだの GanttProject

年度末に向けて複数のプロジェクトが立て込んでくる。 あらためてチーム内での分担を整理して、無理のない計画を立てておきたい(作業量が多いのでどう割り振っても無理が出そうではあるが)。

ということで、久しぶりに GanttProject で線表を引いてみることにした。 最新の GanttProject 2.0-pre3 を試してみる。

以前のバージョンに比べて使い勝手は良くなったものの、スクロール操作などはやはりどうも違和感がある。

それと、やはりまだ印刷機能が弱いな。 印刷がうまくできないと役立ち度がかなり低い。

• ソフトウェア技術者御用達のプロジェクトマネジメントツール TaskJuggler (2007-04-23)
• Project@Hand 2 購入 (2004-12-27)
• GanttProject 2.0.3 でガントチャート書き (2007-01-17)
• ガントチャート関連ツール (2004-04-13)
• GanttProject で開発スケジュールを作成 (2004-08-26)

■ 個人目標設定における課題

去年失敗している「個人目標を用いた評価制度」を今年もやるらしい。

私が感じる限りでは、去年とほとんど何も変わっていない。

• 観念的な事業方針から、各スタッフに個人目標に一気にブレイクダウンさせようとしている。部門目標 / プロジェクト目標も明確にされないまま、個人に対しては執拗に詳細計画を求めている。
• 詳細な記述を求めるわりに、シートの欄が狭く書き辛い。
• 面談等のプロセスが明確化されておらず場当たり的。
• 「評価」「評価」と「評価」を全面に押し出しており「評価」が目的になりすぎ。しかも、その「評価方法」「評価基準」が存在しない(あるいは公開されない)。

中途半端な導入では「目標による管理」にあるような効果的な自己統制や意欲向上に結びつかず、逆効果になる可能性も高い。

もとよりスタッフは日夜より良いソフトウェアやサービスを開発しようとしているのに、それを萎えさせるようでは論外である。

えーと。

• 目標設定は「何をするのか」「何を達成するのか」で。期日と成果とメジャーメントを明確に書くようにする(ガイドラインの明示と、それらに沿った記入シート)。当然、押しつけられるのではなく各個人が自ら約束する。
• (組織上として)上の人が下の人に、まず部門の目標および個人の目標をきちんとさらす。下に書かせて問題点を指摘するのではなく、どのよう書くのかまず示す。
• プロセスを明確に。
• 人事考課に使いたいのなら、きちんとした「評価方法」「評価基準」を。評価する側は、公正な評価スキルを会得しておくこと。評価者も評価されるような仕組みであること。

まずは、こんなところ?

• 「目標による管理」を勉強しよう (2005-01-11)
• 成功するビジネスプラン (2006-01-08)
• コミットメント・リスト vs ガントチャート (2005-10-19)
• 今日のさえずり - ささやかな気持ちDES (2008-11-07)
• テストセンター (2004-04-22)

■ コラボレーションを促進するオフィスレイアウトへ

今日は土曜日であるが、平日なみ(よりちょっと遅く)に起床。 電車にゆられて秋葉原で下車。オフィスで向かう。 昨年から昼休みに同僚がメジャーを持って歩きまわって 3D 化してシミュレーションするなど、少しづつ計画をあたためてきたレイアウト変更のためである。

夜通し飲んで顔の赤い腰を痛めている若手スタッフと、年寄りがかかると思われている病気のスタッフと、バイクでこけて怪我をしているスタッフと、還暦を過ぎているスタッフと、日本語が堪能ではないスタッフと、体調のよろしくない FF 好きなスタッフと自分で総勢7名。

2月末の納品作業のバタバタ後で細かい配線計画等はできていなかったが、まぁそこは何とかなるでしょうということで。

予想通りパーティションの分離・合体と移動がうまくいかずに、一部破壊しつつ無理矢理に新レイアウトへ。 前半戦でパーティション・デスクなど什器の移動を終え、後半戦からは電源・電話・LAN の再配線。

電話に関しては現状の配線図がないため、こんがらがっている配線をほぐしつつ接続図を作成。

ネットワーク系は、サーバ PC の移設と UPS の差し替えも含めてなので思ったより時間がかかる。

あちらことちらで「ガシャン」と物を落とした音が聞こえたり、「アッ」という声とともに足にひっかかって無理矢理な状態のコードが目に入ったりと(それぞれ自分もやらかしているわけだが)、やばそうな部分もあったが奇跡的に故障している機器はなかったようである。

なんとか夜の 9:00 を過ぎて目処がたち、記念撮影をして解散。

真中にオブジェのそびえ立つ、以前より開放感のオフィスになった。 さて来週以降、効果のほどは。

• 作業風景 (スライドショー)

• 今日のさえずり - スプーのえかきうた騒動について勉強している (2008-10-24)
• 今日のさえずり - ホームレスグーチョコランタン (2008-10-27)
• 今日のさえずえり - スパイだからミハルだってようやく気がついた (2008-11-28)
• 5年ぶりに ThinkPad X31 のメモリ増強 (2008-10-30)
• CLIE マルチスタイラス購入 (2004-03-11)

■ 自然に計画するためのモデル(GTD) と High-Performance OS

GTD では、収集バケツからのワークフローが有名である。 しかしあまり取り上げられることが少ないのだが、かなり重要だとここ最近思っているのが「自然に計画するためのモデル」である。このモデルでは、次の順に頭を動かしていく。

1. 目的と原則を定義する
2. 結果を思い描く
3. ブレーンストーミングする
4. 整理する
5. 次の行動を明らかにする

(仕事を成し遂げる技術 p.85)

ついとりがちなのは「反応型の計画モデル(不自然な計画モデル)」で、目先の行動で行き詰まって手遅れながら逆順にステップをあがっていくというものである。

GTD というと細かい「次の行動」をガンガン進めていくという印象があるが、それらの行動は(意識的に、あるいは無意識的に)目標からブレークダウンされたものでなければならない。

@ High-Performance OS

「自然に計画するためのモデル」はハワード・ゴールドマンの High-Performance OS に通じるところがある。 High-Performance OS でも

1. ビジョン
2. 戦略的フォーカス
3. 何をするか? (what)
4. どうやってするか(how)

というように、目的・目標から始める。 重要。

@ 日常ではどうか?

大きなミッションでは、まず計画フェーズでこれらを熟考する(マズイ、何となくでいってしまうことも多々アリ)。

しかし比較的小さな規模の(GTD でいうところの)プロジェクトは、つい反応的に行動をとってしまいがちである。 依頼のままのアクション・思いついたアクション・やりやすいアクション・面白そうなアクションから手をつけて、結果的に忙しい割にはあまり成果が出ていないこともしばしばだ。

もっとゴールを見据えて効果的に行動していきたいところである。

• 仕事を成し遂げる技術--ストレスなく生産性を発揮する方法
• すごい考え方

• 問題とは「あるべき姿」と「現状」の「ギャップ」である (2006-10-13)
• 2008年夏の GTD 運用ツール (2008-07-23)
• GTD アクション確保のための時間割 (2006-09-26)
• GTD 週次レビューが2時間で終わらない (2006-09-29)
• DateBk5 + Progect で GTD (2005-08-11)

■ GTD アクション確保のための時間割

複数の提案書レビューをショートサイクルで繰り返すというスタイルのフローをいま実践中で、そのため最近はスケジュールにミーティング時間がどんどん書き込まれるという状態である。

自分の中でルールを確立していないため、ミーティング時刻の設定はなんとなく。 何も考えずにこのまま続けていくと、スケジュールがミーティングで埋まってしまいそうだ。 しかしそうなるとその他のアクションが実行されず、責任ある仕事ができなくなってしまう。

いい機会なので、GTD にある次の行動リストの項目を実行するための時間帯とミーティング時間帯をある程度分けて決めてみてしまうことにした。 生理的な「はかどる時間帯」等も考慮してタイムテーブルを考えてみた。

• *1 金曜日は GTD 週次レビュー時間
• *2 単調作業 / 事務処理 / 整理等

論理的な仕事に向いている午前中には社内ミーティングを入れずに、頭を使うアクション(計画や提案立案など)を実行したい。

14:00 - 15:00 は眠くなる時間帯のようなので、待つリストをチェックして他の人に状況を確認するなど、コミュニケーション用時間とする。

社内ミーティングは原則 15:00 - 17:00。場合によっては前後 1時間もミーティング設定可。この時間帯にミーティングがない場合は、単調作業があればこなすようにする (貴重な午前中にやらないように)。この時間帯は繰り返し作業などに向いているらしい。

そういえば社内ミーティング 13:30 開始っていうのがあるのだが、これは準備する側の時には楽だけれど、そうではない側の時はその30分が中途半端であまり効率が良くないというのが最近の印象だ (その隙間時間を活用するのが GTD の極意ではあるのだが)。

最後の1時間は日によって無かったりする可能性があるので、バッファ的な時間としておく。in-box もここで処理しておく。

まずはこれでトライ。

[ 時間管理 ]

• なぜか、「仕事がうまくいく人」の習慣 (2007-04-15)
• 2008年夏の GTD 運用ツール (2008-07-23)
• GTD 週次レビューが2時間で終わらない (2006-09-29)
• 次の行動がたまってきた (2005-08-29)
• そうか、備忘録ファイルがあればいいのか (2006-03-30)

■ 問題とは「あるべき姿」と「現状」の「ギャップ」である

「問題解決プロフェッショナル『思考と技術』」の姉妹本「問題発見プロフェッショナル - 『構想力と分析力』」を火曜日に購入し読み始めている。

本書における問題の定義が明快であり、目から鱗である。

問題とは「あるべき姿」と「現状」の「ギャップ」である -- 「問題発見プロフェッショナル - 『構想力と分析力』」 p.16

現在の状況の中で「マズい点や困っている点」などが問題であると今までごく当たり前に考えていた。しかし本書では問題は「目標(あるべき姿)と現状のギャップ」であると説明している。

「目標をどこに置いているのか」「どういう立場で考えているか」によって、同じ状況でも問題が変わってくる。 全くその通りで非常に納得である。しかし自分ではなかなか気がつかない視点で、またついつい忘れて目の前のマズい点にのみ目が向いてしまいがちである。

• 問題発見プロフェッショナル - 『構想力と分析力』

GTDの「自然に計画するためのモデル」でもハワード・ゴールドマンの「High-Performance OS」でも「目的・目標」からプロジェクトがスタートする。 問題発見・問題解決のプロセスも「目的・目標」の再認識から。

「目的・目標」はどこから来るのだろう。 やっぱり価値観から? 価値観はどこから?

[ 書評 ] [ お薦めの本 ]

• 問題解決プロフェッショナル 「思考と技術」 (2006-08-27)
• すごい考え方 (2005-12-10)
• 自然に計画するためのモデル(GTD) と High-Performance OS (2006-07-09)
• Life Hacks PRESS で Life Hacks をおさらい (2006-03-28)
• なぜか、「仕事がうまくいく人」の習慣 (2007-04-15)

■ なぜか、「仕事がうまくいく人」の習慣

2月に読んだ「スピードハックス 仕事のスピードをいきなり3倍にする技術」(書評) の中で紹介されていた本。興味を持ったので買って読んでみた。

本書によると「仕事がうまくいく人」の習慣とは「すぐにやる!」ことだ。

• すぐにやる!
  • 書類、メールはすぐに処理する。
  • すぐに整理する。
  • すぐに計画する。
  • すぐに正しくやる。
  • すぐに整備する。

あとは

• 機械的に行う作業を決める。
• 歩きまわりコミュニケーション。

など。

GTD で言われていることとかぶる部分も多いので、やはり本書においては「すぐにやる!」というのが一番ポイントであろう。

先送りすればするほど、「問題は大きくなる」し「何度も同じ事を考えたりするはめになる」し「何度も同じメールを読み返すことになったりする」し「他人にせっつかれたりする」し「余分な進捗報告が必要になったりする」しで、達成するまでに余計なコストがかかるようになる。つまり同じ仕事をするのに必要な時間が長くなってしまうというワケ。

一見しんどそうでも結局のところすぐやってしまった方が、効率的にも精神的にも圧倒的にもお得だということ。

これを自分のものにするには

『すぐやる』方式は、長く継続しなければ意味がないという点だ。-- p.35

というのが肝だ。

人間の行動研究で著名なウィリアム・ジェームズによると、何かを毎日やって三十日間続ければ、習慣になるという。-- p.61

そうだ。

私が「すぐにやっていな」かったら「すぐに」指摘してください。> ALL

• なぜか、「仕事がうまくいく人」の習慣 PHP研究所

[ 書評 ]

• GTD アクション確保のための時間割 (2006-09-26)
• ステーショナリーに手を出した - 私的10大ニュース2005 [ misc ] (2005-12-31)
• メールによる社内コミュニケーションの問題 (2006-04-12)
• 「グズ病」が完全に治る本 (2008-09-10)
• 来客用を想定してオフィスに La Fonera を設置 (2007-02-26)

■ ソフトウェア技術者御用達のプロジェクトマネジメントツール TaskJuggler

ときたまやってくるソフトウェア開発の計画作成、今までは GanttProject を使っていたのだけれども、挙動が安定しないのと印刷機能が貧弱なのとで満足できていなかった。

ということで今回は新しいツールを使ってみることにした。チョイスしたのは TaskJuggler。

Linux 上で動くツールである。 GanttProject は Windows でも Linux でも使えるのが利点だったのだが、ここ数年の中でプロジェクトファイルを共有することも無かったので、まあ Linux だけでしか動かなくてもいいかなと。

@ テキスト形式でのプロジェクト記述

TaskJuggler が特徴的なのは、プロジェクトをテキストファイルで記述するところである。 一般的なプロジェクトマネジメントツールは GUI 上でガントチャートを直接編集したりできるのだが、TaskJuggler はそんな軟弱者向けの機能は用意されていない。

あくまでテキストで書く。プロジェクト・リソース・タスク・レポートをテキストファイルに書く。 でコンパイルするとガントチャート等のレポートが生成される。実績もテキストで入力する。

書き方に問題があればコンパイルエラーになるし、定義したタスクの依存関係等でプロジェクト期間からはみ出てしまうような時もコンパイル時に怒られる。 渋い。

@ TaskJugglerUI

とっつきにくく見えるが、慣れると以外とそんなに難しくない。 effort と length と duration の違いが分かればあとは楽勝。

TaskJugglerUI という GUI ソフトウェアでは、補完機能の優れたエディタが内蔵されているしサイドバーのリストからタスク等を選んで、対応する行に移動することもできる。

さながら Eclipse でコードを書いているような感じ。

下手にガントチャート上でタスクをドラッグアンドドロップして、日にちを動かすよりも思った通りに定義していけるので良い。

@ 印刷

ガントチャートについては、それなりに見やすいフォーマットの印刷物を生成してくれる。 印刷からプリンタとして「Print to File (PDF)」を選択すれば日本語も含めて問題なく PDF 化できるので、でき上がったものも配付しやすい(ここら辺は KDE 側の範疇か)。

GanttProject では PDF 出力がイマイチで結局、画像ファイルにエクスポートしてプリントアウト/配付していたのでこれは便利。

@ 面倒な点といえば

面倒な点があるとしたら、タスクに ID をつけてその ID で依存関係などを指定してあげなければいけない点か。 識別子を考えるのが面倒なのと、タスクの数が増えてきた時にその指定したい ID を探す(思い出す)のが面倒である。

あと、識別子の名前変更リファクタリング機能があればいいな (一括置換だと関係ないところまで置換してしまう可能性がある)。

@ ということで

ソフトウェアエンジニアには使いやすいツールだと思う。

マクロ機能やインクルード機能などもあるのでもう少し使いこんでみたい。

• http://www.taskjuggler.org/

• コミットメント・リスト vs ガントチャート (2005-10-19)
• amaroK で Linux 上の iTunes 音楽データを聞く (2006-01-22)
• GanttProject で開発スケジュールを作成 (2004-08-26)
• フォト イメージング エキスポ 2005 (2005-03-18)
• Adobe Reader for Palm OS バージョン3.0 (3.... (2004-07-14)

■ PLANNING に違う期待をしてしまった「PLANNING HACKS!」

本屋で探していた本が無かったので、タイトルに魅かれて買ったのがコレ。 プランニングという言葉について(本書の狙いとは)違うイメージと期待を持って読んだため、「パッとしないと感じ」というのが読んだ仮想。

自分の仕事がら、プランニングというと「計画」的な意味合いをイメージしてしまうんだけれど、こちらは「企画」の方の話なんだよね。 読み終わってから、表紙のタイトルの横に「企画ハック!」と書いているのに気がついたよ。

ということで本書はプロジェクトの計画のハックではなくて、企画のハック本。内容は

「プランニング・システムとアイデアの二段階抽出法を使えば、誰でも優れた企画が量産できるよ」-- p.40

に集約されている。 企画のために普段から準備しておくというのはごく自然な発想だが、なかなかできていないことなのでこのようにあらためて気づかされるというのは良い。 本書では「準備」と「アウトプット」の2段階を基本軸に仕事術を展開している。

発想法については何でも「二段階抽出法」に結びつけているののがちょっと違和感があった。 本書ではそのテーマにきちんと絞っているといえばそうなのかもしれないが、やはり「それだけ?」と思えてしまう。

本書では、企画を考え出し続けるのに必要なテクニックが紹介されている。 どう違うかと問われると困るが、本書に書かれているのは「ハック」ではなく「テクニック」というかそういうような感じがする。

いわゆる Life Hacks 系で言うところのハックとは香りが違う気がするのはなぜだろう。文体からだろうか。 本書自体が、パワポスライド的なテイストだからかもしれない。

プランナーとして、日々アイデアを出してプレゼンテーションをする人向けの1冊。

• PLANNING HACKS!

[ 書評 ]

• Life Hacks PRESS で Life Hacks をおさらい (2006-03-28)
• 成功するビジネスプラン (2006-01-08)
• 今日もよくたれています。 (2006-11-17)
• 「グズ病」が完全に治る本 (2008-09-10)
• 新幹線用「ウェブ進化論」 (2006-05-13)