2008年08月09日
品質向上１
ここ最近、本番環境での障害を発生させてしまいました。
障害が発生してから、なぜそれが発生してしまったのかを考えると
チェックが甘かったとか、時間が足りなかったとかいろいろな要因がありますが
そのときに気づけなかった、できなかったのが最大の原因です。
後から見返せば、なんで？と思うのですがやっているときには気づかない、
その今の仕組みを見直す必要があるなと思います。
たとえば入力項目であれば、基本チェック項目は以下のとおり。
・必須か？
・最小長、最大長は？
・画面の入力項目のサイズおよび最大入力桁数は？
・入力可能な文字の種類は？
数字、英字、全角、第1水準、第2水準、13区、日付はなどなど。
・入力可能な範囲は？
数字であれば１－９とか。
・入力可能な形式は？
日付：YYYYMMDD、MM/DDとか。
メールアドレス：RFC822に準拠していたり、一部準拠だったり。
・入力チェックの内容は？
・入力チェック前の変換処理は？
トリム、文字コード変換、ユニコードマッピング、ハイフン変換など。
その上で業務仕様チェックがあったりします。
・コード値であれば最初はAではじまっているかとか
・日付の範囲はいつからいつかとか。
そして入力項目の登録先はどこなのか？
登録前に変換処理や加工処理が入るのか？
こういった仕様をきちんとおさえるのは当たり前なのですが
ちょっとした思い込みで見落としてしまったばっかりに
痛い目にあってしまいました。
こういったチェック内容をまとめて各開発者にシートとして配る必要があります。
レビュー前には必ずこのシートの結果を提出してもらうようにして
それをお客さんにも見てもらうようにできればと思います。
投稿者 thatanaka : 09:38 | コメント (0)
2008年04月11日
習慣化と形骸化
ホワイトボードを使い始めてそろそろ１月半立とうとしています。
ホワイトボードのおかげで次のようなメリットが生まれています。
・その日の予定が一目瞭然。
・直近のマイルストーンを記述することで目標が明確化する。
・その日の予定のうち、必須項目とオプション項目を切り分け可能となる。
一方で次のような課題が発生してしまいました。
１．今までのタスク管理との整合性。無理やりやろうとすると管理コストが増えてしまう。
２．マイルストーンが細かすぎて重要性が薄れる。
３．必須項目があまり必須化していない。
習慣化してきたことはうれしいことなのですが、一方であまり意味のない部分も増えてきてしまいました。
そこでお風呂につかりながら次のような前提の下に仕事を進めていくことを考えました。
１．と２．に対する改善案
・マイルストーンはいくつかのタスクで成り立っている。
・すべてのタスクが完了すると、マイルストーンは完了する。
・これまでのタスク管理表を改変して、マイルストーンに紐づくようにする。
・変わりにマイルストーンの単位をもう少し粒度を大きくする。（１－２週間単位）
３．に対する改善案
・週半ばに行っている定例会議を週初に持っていく。そこで週間予定および先週の実績を発表。
・実績ベースで遅れている場合、どのようにして解消するかもあわせて報告。
・あまり遅れが重なるようだと時間外勤務が増えるもしくは雇用先へクレーム。
・予実管理をもう少し見えるようにする。
最後の予実管理は私にとって一番の課題です。
メンバーに現在の状況を一目瞭然に見せれるようにしていきたいと思います。
投稿者 thatanaka : 00:28 | コメント (0)
2008年02月24日
ホワイトボードを使う
現場の別のベンダーが利用しているホワイトボードを見て、自分のチームでも使ってみようと考えました。ちょうど席の後ろにキャビネットがあり、そこにホワイトボードをおくことも可能だからです。
実際に導入して使ってみると思いのほか便利です。
基本的には今日やること、各チームの作業予定、そのほか特記事項を記述しています。
今までメンバーは予定や作業全体について分からないことがあると、リーダーである自分に質問がきていましたが、ホワイトボード導入後はそれを見ながら考えるようになっています。
１月からはじめていた紙の予定表も不要になりました。
今後も様々な使い方を考えていきたいと思います。
投稿者 thatanaka : 00:21 | コメント (0)
2008年02月09日
チーム文化を育てる
サブバージョンのリポジトリ構成を見直すという話がチーム内で出て、その一環でディレクトリ名にチーム名を割り当てましょうということになりました。チーム名はこの週末中に考えなければいけないのですが、ふとチーム名をつけるだけでなく、「チーム文化を育てる」ということを思いつきました。
最近は週末会議で「KPT」を行っているおかげで、チームの作業を見直すということが習慣化されてきています。また小さな改善や決まりごとが生まれたりしています。
せっかくなのでそれらを「文化」まで昇華させてみようという試みです。
手始めとして以下のことに取り組んでみようと思います。
・KPTで挙がっている事項はメールで保管されているのでそれらに対して抽象化の作業を行う。
・抽象化された項目に対して文化のエッセンスとなりそうな言葉をつける。
・壁に見えるところに貼る。
・KPTで挙がった項目は今後メールではなく、Wikiにエッセンスごとに記述できるようにする。
まずはリーダーからメンバーへの提案ですね。受け入れられるといいんですが。
結果はブログにて報告していきます。
投稿者 thatanaka : 17:28 | コメント (0)
2008年02月09日
スケジュールの効果
前回、書いたとおりスケジュールを明確化することで各人に仕事を早め早めに進めていこうとする姿勢が見えてきました。さらにお客さんへの見積もり説明時の添付資料としても有用でした。今後のために以下にその結果をまとめておきます。
■見積もり時に出した資料
１．見積もり概算
１－１．アプリA見積もり詳細
１－２．アプリB見積もり詳細
WBSに落とし込み、それぞれ大体何日ぐらいかかるかをあらわした資料
２．マスタスケジュール
１－１、１－２．をもとにリリースをエンドとしたスケジュールを後ろから引いたもの
日数ベースまで見積もりの段階で落とし込んだので、プロジェクト管理ソフトで
それぞれ線を引きました。またチームメンバーを各タスクへ割り当てます。
３．担当者別スケジュール
マスタスケジュールで各タスクを担当者に割り当てたので、
プロジェクト管理ソフトの別のビューである担当者別スケジュールを印刷。
なんと提示した見積もりではかなりキツキツあることが判明。
■見積もり時に説明した内容
まずは概算の説明。かなりタスクを精査したので、お客さんにとっては納得＋リーズナブル
だったようです。一方で現在のチーム人数でこの工数でできるのかという質問が
でてきました。
そこでマスタスケジュール及び担当者別スケジュールを提示。
キツキツであることをお伝えして、アプリAのうちバッチ部分をスケジュールを
ずらしていただくことを依頼。基本的にはOKでした。
そのほかいろいろ話がでましたが、スケジュールをきっちりと提示したおかげで話が曖昧化せず、またこちらの希望もしっかりと伝えることができました。
スケジュールに落とし込む作業は2人で3hぐらいかかりましたが、効果は抜群です。
投稿者 thatanaka : 17:14 | コメント (0)
2008年02月05日
タスク管理と全体像
緊急度、重要度によるタスク管理をはじめたことによって、目の前にある作業を順調にこなせるようになりました。一方で全体感をつかみながらのタスク作成ができなくなっていることに気づきました。
本来であれば、
全体スケジュール → 今週のやるべきこと → 緊急度：高
→ 来週やるべきこと → 緊急度：低
といくはずが思いついたときにタスクが追加され、そのタスクが全体スケジュールでみていつやるべきかを判断できない自分がいました。
また開発の規模が大きくなってくるにしたがって、何を作ろうとしているのかの全体像を把握しづらくなりました。そこで以下の2点をとりあえず実施してみようとチームメンバーの一人と話し合いました。
１．開発機能の全体像作成
２．全体スケジュール
特に２．なんか何でないのといわれそうですが、これまでタスク管理だけでまわせてしまうほどチームメンバーが優秀であったというのが原因だと思っています。でもこれからはプロジェクト管理の基本作法を押さえた上で、独自の手法を取り入れられるといいなと思います。
投稿者 thatanaka : 23:47 | コメント (0)
2008年01月27日
一日の予定を当番に決めさせる
今週頭からはじめた、緊急度、重要度によるタスク管理は思いのほか、効果がありそうです。
それぞれのエリアの意味づけが次のようになりました。
・重要度（高）、緊急度（高）
今週中に必ず片付ける。
・重要度（高）、緊急度（低）
来週以降の予定作業、将来への投資作業
・重要度（低）、緊急度（高）
やるなら今週中。
・重要度（低）、緊急度（低）
ちょっとした楽しみな作業。
週末に行う締めの会議で、それぞれのタスクの意味を考えていけるようにもなり
しばらくこの方式で運用してみようと思います。
さらに一日単位の予定はこれまでリーダーである自分と当番が決めていたのですが、
これを当番がたたき台を考えて作り、それを朝会で確認するというフローに返ることにしました。
このようにすることによって、次の効果を期待しています。
・メンバーが何をすべきかを自分で考えられるようになる。
・メンバーがチームで抱えているタスクのスケジュール感覚を身につける。
とりあえずやってみようと思います。
また結果はブログにてフィードバックできればと思います。
投稿者 thatanaka : 02:23 | コメント (0)
2008年01月20日
重要度と緊急度によるタスク管理
最近読むプロジェクト関係や勉強に関する本では、たいてい重要度、緊急度をつけてやるべきことを管理することを推奨している。実際に家でもそのような方法で家事を分担したり、計画を立てたりしています。
この間、チーム内で戦略会議と名づける会議を行ったのですが、そこで仕事の進め方に関する貴重な意見をメンバーからいただくことができました。内容は以下のとおり。
「朝会でタスクを割り当てられるのですが、その割り当てられたタスクを終わると、リーダーから再度タスクをもらわないと次の仕事まで時間が空いてしまう。」
なるほど、確かにそのとおりですね。それをうけてさらに出た意見がこれ。
「あらかじめ1週間分ぐらいのタスクを洗い出しておいて、割り当てタスクが完了したら次のタスクへ着手できるようにする。」
というわけで来週からタスク管理を進めていくのですが、いわゆるタスク管理表ではあまり面白くないので、冒頭に述べた重要度・緊急度に関連付けたタスク管理表を作成してみました。実際に使ってみないとなんともいえないのですが、一目で確認できるので結構いいかなと思っています。
使ってみた内容は折り見てブログでフィードバックしていきます。
投稿者 thatanaka : 03:25 | コメント (1)
2008年01月17日
１日の作業予定
最近はチームリーダーとして過ごす毎日のため、朝会での予定確認がとても重要な作業になっています。
昨年まではGoogleカレンダーで行っていたものの、年明けてからさっぱり使わなくなってしまいました。
チームメンバーに注意を促して使わせることはできるものの、せっかくなのでGoogleカレンダーはやめようかなと考えています。
もう少しアナログな手段に戻ろうと。
その理由としては、以下のとおりです。
・朝会の当番が紙で書けるようにしたい。
・細かい作業なども発生しがちなので、いちいちカレンダーに入力すると面倒くさい。
・紙で書いておけばすぐ確認できる。
というわけで明日から早速実行してみようと思います。
まずは１０日間分ぐらい印刷してみよう。
投稿者 thatanaka : 00:19 | コメント (0)
2008年01月01日
Googleを使う
IT業界の人にとっては当たり前かもしれないけど、Googleが提供するツールを少しずつ使えるようになってきた。
まずiGoogle。
これは自分用のポータルサイトとして利用している。
しかしながらブログの購読や役に立つテンプレート集などの収集が今後の課題だ。
つづいてGoogleカレンダー。
予定の入力に使っている。
予定と実績を管理してみたいが、まだそこまでの手法は確立していない。
この間人に聞いたが、予定用のカレンダーと実績用のカレンダーを分けて使うとよいという意見ももらった。
GoogleノートブックとGoogleドキュメント。
あるタスクもしくは課題に対してそれぞれ作成することで
メンバー間で共有して使うことができている。
今後さらに使い込み、いい使い方を会得したい。
あとはGmail。今のところメールの格納場所となっているが、検索機能と組み合わせて上手に情報を管理していきたい。
投稿者 thatanaka : 23:26
2007年08月27日
さまざまなプロジェクト管理ツール
少し仕事が落ち着いてきたこともあり、今までプロジェクトでやってきたことをたな卸ししてみようと思った矢先、プロジェクト管理ツールの紹介記事があったので読んでみました。
一時書きかけてやめてしまいましたが、自分のチームでは「Mantis」を使ってタスク管理を行いました。Excelと組み合わせることでかなりいろいろできるのは事実でしたが、どうしてもメンテナンスまで行き届かなくなりました。
このツールはちょっと面白そうなのでかるーく、導入してみようかと思案中。
運用にまわす為にはある程度の「ツール依存性」をリーダーだけでなく、メンバーにも持たせる必要があるのかなと思います。もしくはアナログ的に紙やペン、絵などを取り入れてやるのもよいかなとも思いました。
でもこれらは一時的にはよいのですが、最終的には「Excel」で管理するのが一番いいかなと思うこのごろでもあります。
投稿者 thatanaka : 22:36 | コメント (0)
2007年07月31日
JMXを学習する
最近のコンテナでは当たり前のように使われているJMX。
今の現場でもバッチ処理の呼び出しの箇所に使っています。
■JMX を使用する監視と管理
■JavaTM プラットフォームの監視と管理
Java5.0からはJMXのAPIがサポートされて、Java仮想マシンやOSの状態を監視できるようになりました。JDK付属のjconsoleを実行すると、メモリやスレッドの状態などを確認できます。
JMXの仕様は以下のサイトからダウンロードできます。
■JSR 3: JavaTM Management Extensions (JMXTM) Specification
これらの仕様を確認してみると、今のプロジェクトでは管理対象のプラグラム呼び出しだけで状態管理までは行っていないなということがわかりました。かなりの数のバッチがありますが、せっかくなので以下の状態ぐらい管理できるといいんじゃないかなとも思います。
・ステータス（成功／失敗）
・更新件数
・バッチ種別
・バッチ概要
上記のような情報をバッチの基底クラスか何かに持たせておき、それらをWebベースの管理コンソールなどの一覧で管理できたりすると素敵かな？もう少し調べて提案してみようかなぁ。
投稿者 thatanaka : 05:53 | コメント (0)
2007年07月08日
Googleソースコード検索
http://www.google.co.jp/codesearch?hl=ja
ブック検索の日本語版が出たと思ったらこんなのも出ていました。
IDEの機能から参照するコード見たいので検索できると便利そうです。
投稿者 thatanaka : 02:20 | コメント (0)
2007年05月12日
プロジェクトの定量化
ついこの間、スケジュールとタスクについての話を書きましたが、それ以外にもプロジェクトにまつわる指標というのを記録できるといいなと考えています。
そんな中、次のような記事を見つけました。
利用しているツールはともかくとして、日々の作業から自動的に指標を作成できるというコンセプトはとてもありがたいことだと思います。
投稿者 thatanaka : 23:08 | コメント (0)
2007年05月06日
Meadow3.0+JDEE
最近Eclipseが重いので、Meadow3.0+JDEEでJavaの開発環境を作成しようとした。
■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