エンジニアのための時間管理術

posted with amazlet at 08.05.08

Thomas A. Limoncelli
オライリー・ジャパン
売り上げランキング: 97278

おすすめ度の平均:

Real Time OS 制御論
事務系のサラリーマンにも役に立つ
真面目すぎ・・・
時間に追われるのではなく、時間を積極的に管理するための良書♪
「普通のエンジニア、プログラマ、SE」を脱皮し始めた人へ

Amazon.co.jp で詳細を見る

システム管理者の業務を対象に書かれており、ややそちら寄りの話題もあるが、エンジニア全般に役立つ内容。

前から気になっていたオープンソースのテスト管理ツールTestLinkをインストールして使ってみました。

好ましいと感じたポイント

• テスト仕様とテスト計画が独立しており、テスト計画でどのテストを実行するかを選択することができる。特定機能だけの再テスト計画を作成するなど、柔軟に使えそう。
• テストケースにキーワードを設定し横串で検索できる。(境界・限界、異常系、追加テスト、顧客受入テスト…）
• 簡単な要件管理機能がありテストケースと関連付けてテストカバレジを参照できる。
• テスト計画やテストレポートをHTML、Word、Excel、OpenOffice形式で出力することができる。顧客や社内向けに簡単に「紙で」状況を報告できる仕掛けがあるのは嬉しい。弊社のプロジェクト管理ソフトProjectscapeのレポート機能、印刷機能と同じ思想。と、少し宣伝(^^;
• 失敗したテストケース、ブロックされたテストケースのみを出力したり、担当者がアサインされていないテストケースを抽出したりなど、実際の現場で役立ちそうな機能がある。
• 「要件に基づくレポート」機能はスケジュール遅延や品質が悪い場合ケースで、事前に顧客へ制約事項を提示するのに便利そう。

こうだったら良いのに…と感じたポイント

• ユーザインタフェースが直感的でなくテスト計画・テストスイート・テストケース・要件仕様ドキュメント・要件・ビルドなどのTestLink用語の意味と関係性を事前に理解しておかないと、どう操作して良いかわかりにくい。
• 要件管理機能がシンプル（要件を階層的に管理できない、要件IDがツリーに表示されない、要件からテストケースを作成できないなど）OSRMTなど他の要件管理ツールとの連携ができないか。

好ましいと感じたポイントが6つ、こうだったら良いのに…と感じたポイントが2つということで、個人的にはかなりのポテンシャルを感じるツールです。
実際のプロジェクトで使い込んでみたいと思います。

最後にインストールして動かすまでにハマったポイントについてまとめておきます。

テストケースと要件を関連付けを行うと以下のエラーが表示される。

[php]
Fatal error: require_once() [function.require]: Failed opening required ‘tlAttachmentRepository.class.php’ (include_path=’.:/usr/share/php:/usr/share/pear:.:/var/www/testlink/lib/functions/’) in /var/www/testlink/lib/functions/common.php on line 109
[/php]

TestLink :: View topic – Error while assiging reuirements to test casesにある通り、/var/www/testlink/lib/functions/common.phpへ以下の行を追加。

[php]
require_once("testproject.class.php");
[/php]

グラフに日本語が表示されない。

こちらを参考に日本語フォントをインストールして設定ファイルを変更。

関連・参考リンク

• きちんと学びたいテストエンジニアのためのTestLink入門
• 脱Excel！ TestLinkでアジャイルにテストをする
• TestLink使用レポート — ありえるえりあ
• TestLinkがExcelのテスト仕様書よりも素晴らしい点: プログラマの思索
• TestLinkの可能性: プログラマの思索

グラフで9割だまされる 情報リテラシーを鍛える84のプレゼン

posted with amazlet at 08.11.15

ニコラス ストレンジ
ランダムハウス講談社
売り上げランキング: 4701

おすすめ度の平均:

大変面白い、しかし内容は不均一。

Amazon.co.jp で詳細を見る

グラフで表現する場合の騙しのテクニックを実例と共に紹介。アンケートでも期待する方向に誘導するためのテクニックがあるが、グラフも同様。情報リテラシーが低いと搾取されっぱなし。

isologue – by 磯崎哲也事務所: データを見ない人々（「オープン化」する社会での「分析」の価値）より。

マスコミの人って、データを全く見ないんですよね。代理店の人ですら。さすがにマーケの人は別だけど。
例えば、子供向け出版物の売れ行きが落ちている説明として、会議で担当者が、
「少子化が進んでいるので」
なんて説明をしたりするけど、調べてみるとここ数年、実は小学生の数はほぼ横ばいなんですよ。
今やインターネットで政府の統計なんか簡単にタダで調べられるのに、調べない。
データがいくらオープンになって、タダでインターネットで見られるようになっても、見ない人は見ないんじゃないでしょうか。

マスコミや投資家といったインテリ層に属する人たちですら、大半はデータを見ずに「少子化が進んでいる」というような（データの裏付けが無い）前提に基づいて判断を下していることが多く「データを分析する機能」は今後も価値を持ち続けるだろうという内容です。

読んでいてプロジェクトマネジメントも同じだなと思いました。

ソフトウェアの開発プロジェクトでは課題やバグ数、テストケース数、生産物の出来高、コストと利益率など多くのメトリクスを扱います。

ほとんどのプロジェクトではこれらのデータを一定期間毎に集計し、社内や顧客への報告資料としてまとめていると思いますが、単に集計するだけで、それらの数値をきちんと分析していないプロマネが意外に多い。

収集したデータの特異値や傾向をきちんと分析することで、大きな問題になる前に早めのアクションが打てるようになります。PDCAサイクルのC(Check)とA(Act)ですね。

そんなの当たり前じゃないかと思いますよね。ですが、トラブルになるプロジェクトは経験上、

• プロジェクトデータを継続的に収集できる仕掛けがない
• メトリクスの分析とフィードバックが不十分(集計して眺めているだけ…）

のいずれかが該当するはず。こういうプロジェクトは個人的にPDDD(Plan-Do-Do-Death)プロジェクトと呼んでます(^^)

オープンソースのプロマネツールも数多く存在する現状を考えると「プロジェクトデータを継続的に収集できる仕掛けがない」プロジェクトは減ってくでしょうから、プロジェクトデータを分析して、早めに適切なアクションを打つことができるプロマネの価値はさらに高まっていくのではないでしょうか。

ソフトウェア開発プロジェクトの現場では課題やバグ、タスクを管理するために、RedmineやTracなどのIssue Trackin System(課題追跡システム。以下ITSと表記)を使っていることが多いと思います。

ITSを使えばこれらの情報を一元化しプロジェクトメンバ間で共有できるため、うまく使えばとても役立ちますよね。

しかし、あまり深く考えずに導入すると、

「入力が大変だし余分な手間が増えただけだよ…」というメンバーからの不満の声
「この課題って本当に終わってるの？」といった疑心暗鬼
「このタスク、誰も進めてなかった！」という驚愕の事実が期限前日に判明

などといった状況に陥りがちです。

ここでは、いくつかのプロジェクトへ導入した経験から得た、ITSを運用する上で重要(と考える)な6つのポイントを紹介します。

ポイント1 チケット項目はマネジメントから逆算しシンプルに

チケットにはオリジナルの項目(属性)を追加できるため、いろいろ盛り込みたくなりますが、多くの入力項目があるチケット画面は見るだけでいやになりませんか？

それに、そもそも用途が明確でない項目を入力してもらうのは全くのムダです。

「どの情報をどのように見てマネジメントするか」から逆算してチケット項目を決定しましょう。できる限りシンプルに。

ポイント2 チケットの運用フローと入力ルールを明確に

• 誰がチケットを起票しどのように担当者をアサインするか
• チケットのクローズ条件
• チケットの各項目(優先度、マイルストーンなど)へどのような情報を入力するか

などのチケット運用ルールを事前に定義し、運用を開始する前にプロジェクトメンバーへ周知しておきましょう。これらのルールもポイント1に書いたようにマネジメントから逆算です。

RedmineやtracであればWikiに書いておくのが良いですね。

ポイント3 ITSをチケットの墓場にしない

• 終了しているはずのチケットが閉じられていない
• 誰にもアサインされていないチケットが放置されている

このような状況は非常に危険です。ITSの情報が「あてにならない」ため、だんだん誰も使わなくなっていきます。そして、ITSはチケットの墓場に…

プロジェクトメンバーがチケットの運用に慣れるまでは週次でチケットの棚卸を行うなどして、チケットの情報鮮度を確保するようにしましょう。

ポイント4 プロマネのチケットに要注意

プロマネやチームリーダーのチケットは要注意です。

管理すべき立場の人が期限切れのチケットを放置していたりすると、ほぼ確実にプロジェクト全体へ蔓延します。率先垂範を心がけましょう。

ポイント5 一元管理を徹底する

チケットへの情報集約を徹底しましょう。メールでやりとりされた内容、口頭で交わした内容などもチケットへ記入する習慣を。

また、社内の管理ルールにより、チケットへ入力した内容を社内の別システムへも入力しなければならないケースもあるでしょう。

そのような場合、プロジェクトメンバはチケットだけを入力すれば良いルールにして、社内システムへの転記は別の方法を考えましょう。二重投入が必要だとメンバにとっては「余分な手間が増えるだけ」です。

ポイント6 チケットのオーナーシップを意識付ける

チケットの担当者が能動的にチケットを処理し、クローズまで責任を持って担当する土壌を作れるかはプロジェクト運営上、とても重要です。

まず、担当者が割り当たっていないチケットは、プロマネかチームリーダーが漏れなく割り当てるようにしましょう。

その上で、前述したチケットの棚卸で担当者別にフォローアップし、オーナーシップの意識付けを行えば良いと思います。

以上、私自身の経験から重要と考えている6つのポイントを紹介しました。

多少なりとも参考になる部分があればうれしいです。ただ、ITSの運用がうまくいってもプロジェクトがうまくとは限りません(^^)

プロジェクトの中に飛びぬけて優秀なメンバがいると扱いに困りませんか？

設計方針からプロジェクト運営、各種基準の制定など、様々な分野へ口を挟んできて、うるさくてたまりません。

そんな悩みを抱えるプロマネの皆様へ優秀なメンバのモチベーションを下げ、平均的メンバとして平準化する3つの方法を紹介したいと思います。

1. 作業計画を徹底して曖昧にする

優秀なメンバほど自分のタスクを効率よく片付けるための段取りを考えたり、作業の最適化をしたがります。

簡単に最適化させぬよう、作業分担やマイルストーン、全体のタスク量などは徹底して曖昧な状態に保ちましょう。

この不確実な世の中、なんでも計画通り行くわけがないという厳しい現実を思い知らせたいものです。

2. 抜け駆けを許さない

優秀なだけに他メンバと比べて生産性が高く、同じボリュームのタスクをアサインしても何倍も早く終えてしまうことでしょう。

その場合、自分のタスクを終えたからといって、一人だけ早く帰宅しないよう常に監視するのが大切です。

帰宅しそうな雰囲気を感じたら即座に呼び止め、ダラダラ残業している他メンバのタスクをアサインしましょう。（カバンを持って立ち上がった瞬間がベストのタイミングです）

一人だけ早く帰られたりすると組織の輪が乱れます。「みんなで深夜までがんばろう！」という日本企業の伝統を守り抜きたいものですね。

3. 改善提案は全て却下する

優秀なメンバは、プロジェクト運営や作業プロセスに非効率な部分があると必ず改善提案をしてきます。

あらゆる改善提案は即座に却下しましょう。

確かに、改善によってプロジェクトの生産性は向上するかもしれません。

しかし、たった一人のワガママで、せっかく皆で我慢してきた（非効率な）手順を変え、今までの他メンバの頑張り（ムダな我慢）を台無しにして良いのでしょうか？

プロジェクトを成功させるためにはメンバ間の「和」が大切です。「出る杭は打たれる」という諺の意味を十分に指導するよう心がけましょう。

いかがでしょう。ここで紹介した3つの方法は、いずれも今日から実行できるものばかりだと思います。実際の現場でお試しいただき、結果をフィードバックいただければ幸いです。

誠 Biz.ID：新人マネジャー田所晋一の場合：やっかいな部下との評価面談、成功のカギは「納得を引き出す」という記事より。

「上司の詳しい説明があれば、部下にとっては次の期のヒントになる。つまり、上司が期待する水準というのが説明によって理解できれば、次はそこを意識しようと思えるということだ。逆にこの説明がなければ、どうがんばっても上司の好き嫌いで評価が決まるのだと思われてしまう。この差が大きいんだ」

「部下を納得させるためだけじゃない。評価の材料を集めることは、部下の足りない能力をどう伸ばすかという気づきにもつながる。その意味では、評価に手間暇をかけることが、自分のマネジメント力を向上していくことになるんだ」

過去に部下の評価面談をしていた際、全ての部下の仕事振りを普段から公平に見て、納得感を持ってもらえるような評価ができていたかというと…正直言って自信がありません。

この記事のように、普段から仕事上の事実（出来事とそれに対するアクションを）を集め、それに対する評価を伝えることができれば、きっと「ちゃんと見て評価しているんだな」という納得感を与えることができますし、自分自身のマネジメント力も向上するでしょうね。

「納得感」はプロジェクトマネジメントにおいても重要です。

例えば、プロマネが独断で作った納得できない(守れるとは思えない)スケジュールをメンバに強要した場合、プロジェクトはどうなるでしょう？

• スケジュールが形骸化し結果として大幅な進捗遅延を招く
• メンバの長期・長時間の残業や休日出勤で、どうにか納期は厳守するがメンバが燃え尽きてしまう…

残念ながら、上記のいずれかになってしまうケースが非常に多いのではないでしょうか。

そうならないためには、

• プロジェクトの制約事項、タスクのゴールイメージ(アウトプットの内容とレベル)、作業ボリューム(工数)についてメンバと話し合い、双方が納得できるスケジュールを作成する。
• スケジュールをコミットメントする。コミットメントは「約束」。プロジェクト全員が約束を守るため、全力を尽くす空気(風土)をつくりだす。

これが大切です。

プロマネはメンバに納得感を与えること、そしてコミットメントを忘れないようにしたいものです。

コミットメントの力―人と人がかかわるとき (NTT出版ライブラリーレゾナント)

posted with amazlet at 09.11.30

三砂 ちづる
NTT出版
売り上げランキング: 275354

Amazon.co.jp で詳細を見る

要求定義を以下のステップに分類し、各ステップ別の進め方・発生しがちな問題点・適用するツールについて、実例を交えて解説している。

• 目的等共有ステップ
• 要求獲得ステップ
• 現状調査ステップ
• 要求リスト作成ステップ
• モデリングステップ
• 要求確定ステップ

「第３部　要求定義のテーラリング」では、企業組合のCMSウェブサイト、文具店の顧客管理システム、精密機器メーカーの在庫管理システム、物流業者の販売管理システムというサンプルケースを設定し、システムの難易度や規模、特性に応じた上記の各ステップのテーラリング例を示している。想定したケースに対する具体的で豊富なアウトプット例が参考になる。

顧客に対してフルスペックの要求定義ステップをベースとして示し、こういう理由でこの部分は省略するが、この部分はしっかりやるべきだと提案し積極的にテーラリングを行うべきであるという主張は同感。

体裁だけ整った中身がスカスカのドキュメントをいくら作ったところで、顧客にも自分たちにも何のメリットもない。攻めの提案で削れるところは削り、その上で「必要十分」を目指したいところだ。

これから要求定義を始める人にお勧めの一冊。

ITプロジェクトの「見える化」 下流工程編 (SEC BOOKS)

posted with amazlet at 08.11.24

情報処理推進機構(IPA) ソフトウェアエンジニアリングセンター(SEC)
日経BP社
売り上げランキング: 68144

おすすめ度の平均:

見える化するとお金を払ってもらえない業界の性格
「見える化」「言える化」「直せる化」
ごちゃごちゃ気味ですが

Amazon.co.jp で詳細を見る

このシリーズは総集編、上流工程編、中流工程編、下流工程編と出ているが、総集編と下流工程編を読んだ限り内容的に重複する部分が多い。１冊にまとめた方が良い気がする。見える化といいながら、内容的にはやや散漫か。

複数の対象に対して優先度付けをしたい場合にに使用する。評価を行う観点を抽出した後、評価観点毎に点数を付け、それらの積を計算した評価点を用いて優先度を決定する。

点数は1,5,9のように離散値を設定し、その中から選ぶようにすると、中央付近の評価が集中し優先度を付けにくくなることを抑止できる。

また、人命や社命に関わるなど絶対に譲れない評価がある場合、最大点数^評価項目数（べき乗）を上回る特別点を設定できるようにする。（たとえば最高9点で3つの評価項目がある場合、9^3=729点となるため特別点は1000点とするなど）

具体例

• 優先度を決定するための評価項目を検討する。重要な評価項目に漏れが生じないように慎重に検討すること。ここでは「販売量」「利益率」「顧客重要度」を設定した。
• 比較対象の名称を記述する。ここでは「Ａ社」「Ｂ社」「Ｃ社」「Ｄ社」について比較を行っている。
• 設定した評価項目毎に議論し点数を記入する。
• 全ての項目に対して点数を記入したら評価点を計算する。評価点の大きいものから高い優先度で対応していく。