ホワイトボードのおかげで次のようなメリットが生まれています。
・その日の予定が一目瞭然。
・直近のマイルストーンを記述することで目標が明確化する。
・その日の予定のうち、必須項目とオプション項目を切り分け可能となる。
一方で次のような課題が発生してしまいました。
１．今までのタスク管理との整合性。無理やりやろうとすると管理コストが増えてしまう。
２．マイルストーンが細かすぎて重要性が薄れる。
３．必須項目があまり必須化していない。
習慣化してきたことはうれしいことなのですが、一方であまり意味のない部分も増えてきてしまいました。
そこでお風呂につかりながら次のような前提の下に仕事を進めていくことを考えました。
１．と２．に対する改善案
・マイルストーンはいくつかのタスクで成り立っている。
・すべてのタスクが完了すると、マイルストーンは完了する。
・これまでのタスク管理表を改変して、マイルストーンに紐づくようにする。
・変わりにマイルストーンの単位をもう少し粒度を大きくする。（１－２週間単位）
３．に対する改善案
・週半ばに行っている定例会議を週初に持っていく。そこで週間予定および先週の実績を発表。
・実績ベースで遅れている場合、どのようにして解消するかもあわせて報告。
・あまり遅れが重なるようだと時間外勤務が増えるもしくは雇用先へクレーム。
・予実管理をもう少し見えるようにする。
最後の予実管理は私にとって一番の課題です。
メンバーに現在の状況を一目瞭然に見せれるようにしていきたいと思います。
実際に導入して使ってみると思いのほか便利です。
基本的には今日やること、各チームの作業予定、そのほか特記事項を記述しています。
今までメンバーは予定や作業全体について分からないことがあると、リーダーである自分に質問がきていましたが、ホワイトボード導入後はそれを見ながら考えるようになっています。
１月からはじめていた紙の予定表も不要になりました。
今後も様々な使い方を考えていきたいと思います。
最近は週末会議で「KPT」を行っているおかげで、チームの作業を見直すということが習慣化されてきています。また小さな改善や決まりごとが生まれたりしています。
せっかくなのでそれらを「文化」まで昇華させてみようという試みです。
手始めとして以下のことに取り組んでみようと思います。
・KPTで挙がっている事項はメールで保管されているのでそれらに対して抽象化の作業を行う。
・抽象化された項目に対して文化のエッセンスとなりそうな言葉をつける。
・壁に見えるところに貼る。
・KPTで挙がった項目は今後メールではなく、Wikiにエッセンスごとに記述できるようにする。
まずはリーダーからメンバーへの提案ですね。受け入れられるといいんですが。
結果はブログにて報告していきます。
■見積もり時に出した資料
１．見積もり概算
１－１．アプリA見積もり詳細
１－２．アプリB見積もり詳細
WBSに落とし込み、それぞれ大体何日ぐらいかかるかをあらわした資料
２．マスタスケジュール
１－１、１－２．をもとにリリースをエンドとしたスケジュールを後ろから引いたもの
日数ベースまで見積もりの段階で落とし込んだので、プロジェクト管理ソフトで
それぞれ線を引きました。またチームメンバーを各タスクへ割り当てます。
３．担当者別スケジュール
マスタスケジュールで各タスクを担当者に割り当てたので、
プロジェクト管理ソフトの別のビューである担当者別スケジュールを印刷。
なんと提示した見積もりではかなりキツキツあることが判明。
■見積もり時に説明した内容
まずは概算の説明。かなりタスクを精査したので、お客さんにとっては納得＋リーズナブル
だったようです。一方で現在のチーム人数でこの工数でできるのかという質問が
でてきました。
そこでマスタスケジュール及び担当者別スケジュールを提示。
キツキツであることをお伝えして、アプリAのうちバッチ部分をスケジュールを
ずらしていただくことを依頼。基本的にはOKでした。
そのほかいろいろ話がでましたが、スケジュールをきっちりと提示したおかげで話が曖昧化せず、またこちらの希望もしっかりと伝えることができました。
スケジュールに落とし込む作業は2人で3hぐらいかかりましたが、効果は抜群です。
]]>本来であれば、
全体スケジュール → 今週のやるべきこと → 緊急度：高
→ 来週やるべきこと → 緊急度：低
といくはずが思いついたときにタスクが追加され、そのタスクが全体スケジュールでみていつやるべきかを判断できない自分がいました。
また開発の規模が大きくなってくるにしたがって、何を作ろうとしているのかの全体像を把握しづらくなりました。そこで以下の2点をとりあえず実施してみようとチームメンバーの一人と話し合いました。
１．開発機能の全体像作成
２．全体スケジュール
特に２．なんか何でないのといわれそうですが、これまでタスク管理だけでまわせてしまうほどチームメンバーが優秀であったというのが原因だと思っています。でもこれからはプロジェクト管理の基本作法を押さえた上で、独自の手法を取り入れられるといいなと思います。
・重要度（高）、緊急度（高）
今週中に必ず片付ける。
・重要度（高）、緊急度（低）
来週以降の予定作業、将来への投資作業
・重要度（低）、緊急度（高）
やるなら今週中。
・重要度（低）、緊急度（低）
ちょっとした楽しみな作業。
週末に行う締めの会議で、それぞれのタスクの意味を考えていけるようにもなり
しばらくこの方式で運用してみようと思います。
さらに一日単位の予定はこれまでリーダーである自分と当番が決めていたのですが、
これを当番がたたき台を考えて作り、それを朝会で確認するというフローに返ることにしました。
このようにすることによって、次の効果を期待しています。
・メンバーが何をすべきかを自分で考えられるようになる。
・メンバーがチームで抱えているタスクのスケジュール感覚を身につける。
とりあえずやってみようと思います。
また結果はブログにてフィードバックできればと思います。
この間、チーム内で戦略会議と名づける会議を行ったのですが、そこで仕事の進め方に関する貴重な意見をメンバーからいただくことができました。内容は以下のとおり。
「朝会でタスクを割り当てられるのですが、その割り当てられたタスクを終わると、リーダーから再度タスクをもらわないと次の仕事まで時間が空いてしまう。」
なるほど、確かにそのとおりですね。それをうけてさらに出た意見がこれ。
「あらかじめ1週間分ぐらいのタスクを洗い出しておいて、割り当てタスクが完了したら次のタスクへ着手できるようにする。」
というわけで来週からタスク管理を進めていくのですが、いわゆるタスク管理表ではあまり面白くないので、冒頭に述べた重要度・緊急度に関連付けたタスク管理表を作成してみました。実際に使ってみないとなんともいえないのですが、一目で確認できるので結構いいかなと思っています。
使ってみた内容は折り見てブログでフィードバックしていきます。
]]>最近はチームリーダーとして過ごす毎日のため、朝会での予定確認がとても重要な作業になっています。
昨年まではGoogleカレンダーで行っていたものの、年明けてからさっぱり使わなくなってしまいました。
チームメンバーに注意を促して使わせることはできるものの、せっかくなのでGoogleカレンダーはやめようかなと考えています。
もう少しアナログな手段に戻ろうと。
その理由としては、以下のとおりです。
・朝会の当番が紙で書けるようにしたい。
・細かい作業なども発生しがちなので、いちいちカレンダーに入力すると面倒くさい。
・紙で書いておけばすぐ確認できる。
というわけで明日から早速実行してみようと思います。
まずは１０日間分ぐらい印刷してみよう。
まずiGoogle。
これは自分用のポータルサイトとして利用している。
しかしながらブログの購読や役に立つテンプレート集などの収集が今後の課題だ。
つづいてGoogleカレンダー。
予定の入力に使っている。
予定と実績を管理してみたいが、まだそこまでの手法は確立していない。
この間人に聞いたが、予定用のカレンダーと実績用のカレンダーを分けて使うとよいという意見ももらった。
GoogleノートブックとGoogleドキュメント。
あるタスクもしくは課題に対してそれぞれ作成することで
メンバー間で共有して使うことができている。
今後さらに使い込み、いい使い方を会得したい。
あとはGmail。今のところメールの格納場所となっているが、検索機能と組み合わせて上手に情報を管理していきたい。
]]>一時書きかけてやめてしまいましたが、自分のチームでは「Mantis」を使ってタスク管理を行いました。Excelと組み合わせることでかなりいろいろできるのは事実でしたが、どうしてもメンテナンスまで行き届かなくなりました。
このツールはちょっと面白そうなのでかるーく、導入してみようかと思案中。
運用にまわす為にはある程度の「ツール依存性」をリーダーだけでなく、メンバーにも持たせる必要があるのかなと思います。もしくはアナログ的に紙やペン、絵などを取り入れてやるのもよいかなとも思いました。
でもこれらは一時的にはよいのですが、最終的には「Excel」で管理するのが一番いいかなと思うこのごろでもあります。
■JMX を使用する監視と管理
■JavaTM プラットフォームの監視と管理
Java5.0からはJMXのAPIがサポートされて、Java仮想マシンやOSの状態を監視できるようになりました。JDK付属のjconsoleを実行すると、メモリやスレッドの状態などを確認できます。
JMXの仕様は以下のサイトからダウンロードできます。
■JSR 3: JavaTM Management Extensions (JMXTM) Specification
これらの仕様を確認してみると、今のプロジェクトでは管理対象のプラグラム呼び出しだけで状態管理までは行っていないなということがわかりました。かなりの数のバッチがありますが、せっかくなので以下の状態ぐらい管理できるといいんじゃないかなとも思います。
・ステータス（成功／失敗）
・更新件数
・バッチ種別
・バッチ概要
上記のような情報をバッチの基底クラスか何かに持たせておき、それらをWebベースの管理コンソールなどの一覧で管理できたりすると素敵かな？もう少し調べて提案してみようかなぁ。
ブック検索の日本語版が出たと思ったらこんなのも出ていました。
IDEの機能から参照するコード見たいので検索できると便利そうです。
そんな中、次のような記事を見つけました。
利用しているツールはともかくとして、日々の作業から自動的に指標を作成できるというコンセプトはとてもありがたいことだと思います。
■JDEE:Java Development Environment for Emacs
必要なファイルをダウンロード＋解凍して、Meadowを起動したら次のようなメッセージが表示。
(error "Recursive `require' for feature `sb-info'")
どうもこれ、speedbarの不具合だそうです。
http://www.et.bs.ehu.es/ess/0013.html
以下のリポジトリから最新のsb-info.elをダウンロードしてspeedbarのファイルを差し替えたらエラーメッセージは表示されなくなりました。
■Log of /cedet/speedbar/sb-info.el
http://cedet.cvs.sourceforge.net/cedet/cedet/speedbar/sb-info.el?view=log
さっそくチームメンバーに配布してみて、共通話題として取り上げてみようかな。
]]>