SHOEISHA iD

※旧SEメンバーシップ会員の方は、同じ登録情報(メールアドレス&パスワード)でログインいただけます

DeveloperZine(デベロッパージン)- エンジニアの意思決定を支える技術情報メディア ProductZine

CodeZine編集部では、現場で活躍するデベロッパーをスターにするためのカンファレンス「Developers Summit」や、エンジニアの生きざまをブーストするためのイベント「Developers Boost」など、さまざまなカンファレンスを企画・運営しています。

独善のススメ

【第3回】身近な所からチームを独善する


チームを独善する

 それでは、私が実践した「チームの独善」を3つ紹介します。

メトリクスの収集

動機

  • 見積もり精度の向上と、品質の確認

手法

 メトリクス収集を義務化し、全メンバーに周知徹底させました。

収集したメトリクス
  • 各工程の成果物のボリュームと、実施にかかった時間
  • 各成果物のレビュー時間、指摘件数、指摘内容

 収集にあたり、従来使用していた「週報」を廃止し、各開発工程の作業時間/作成量のみを記入する専用のExcelフォーマットを作成しました。記入タイミング/記入内容/記入方法/記入例など、細かく記述した説明書を作成し、全メンバーに周知し、運用を開始しました。

感想

 最初、メンバーから収集に反対されるのではないかと考えていたのですが、ルールを細かく決めて実施したところ、全員きちんと記入しており、有効なデータを収集することができるようになりました。

 このメトリクスのおかげで、チームの生産性、開発スピード、作業時間の割合など、様々なデータが分かるようになりました。

成果物に対する確実なレビューの実施

動機

  • 品質の向上
  • ミスによる手戻りの削減

手法

 効率的なレビューの実施方法を策定しました。

策定内容
  • [レビュー前成果物] [レビューシート] [指摘事項反映成果物] を格納するフォルダを策定。
  • レビュー指摘区分の策定。
  • 指摘区分件数を自動集計するレビューシートを独自に策定。
  • レビュー実施方法の明確化。

 下記の図のように、レビューの実施方法を明確化しました。

レビューの実施方法を明確化
レビューの実施方法を明確化

感想

 レビューの実施内容が不明確であったため、指摘内容が人によって変化したり、指摘事項の反映漏れなどの問題がありました。

 そこで、指摘区分を明確化し、確実な指摘事項反映をルール化し、実施しました。これにより、担当者側も指摘区分を意識した成果物の作成に取り組むようになり、また、指摘事項の反映漏れを大幅に削減することもできました。

スクラム・ミーティング(朝会)の実施

動機

  • プロジェクト後半のミーティング時間の削減
  • 問題の早期回避

手法

 アジャイル開発手法の1つ「スクラム」で紹介されているスクラム・ミーティングを導入しました。スクラム・ミーティングとは、毎朝決った時間、決った場所で、立ったまま行うミーティングです。毎朝実施することで、メンバーの抱えている問題を最大24時間でキャッチアップできる点、メンバー全員で進捗状況を共有できる点、手短に実施できる点にメリットを感じ、導入することにしました。

 それまでミーティングといえば、プロジェクト前半はほとんど実施せず、問題が多発するプロジェクト後半に毎日1時間以上の長いミーティングを行うのが普通でした。毎朝実施することに抵抗がありましたが、プロジェクト後半に毎日1時間以上ミーティングを実施するのであれば、プロジェクト初期段階から毎朝10分程度のミーティングを実施して早期に問題回避したほうが得策だと判断しました。

 数年後、プロジェクト・ファシリテーションにめぐりあい、プロジェクト・ファシリテーションで提案されている「朝会」の手法を取り入れ、コミュニケーションツールとしてのメリットを追加することができました。

 スクラム・ミーティング導入時は、「集合時間」と「進捗報告」の2点しか決めてなく、特に文書化はしていませんでした。しかし、朝会では3点(「昨日実施したこと」「今日実施すること」「作業の残件数」)の報告を義務化したのですが、なかなか定着しなかったため、wikiに報告内容を明記し、周知徹底を図りました。

感想

 導入直後は「スタンダップミーティング」ではなく、「シットダウンミーティング」になっていたのですが、メンバーが増え、イスが足りなくなったため自動的に「スタンダップミーティング」へと移行しました。

 朝一番に今日実施する内容をみんなに宣言することで、自分の作業が明確になり、朝会終了後即座に仕事に集中することができました。また、声の調子や顔色を見て体調をチェックすることができたり、声の調子で進捗が思わしくないかどうか判断することができました。

終わりに

 「チームの独善」、いかがだったでしょうか。この記事の内容を100%そのまま利用することは難しいと思いますが、改善したいことと記事の内容を付き合わせていただくと、きっとヒントやきっかけが見つかると思います。

 改善に定石はありません。今回ご紹介した「ルールを活用する」のも1つの方法だと思いますし、すでに皆さんが実践されている方法があれば、それも1つの方法です。色々模索してみてはいかがでしょうか。

 前回は「自分」、今回は「チーム」と、少しずつ視点が高くなっております。次回は、さらに視点を高くして、社内に対する独善への取り組みについてご紹介したいと思います。

この記事は参考になりましたか?

連載通知を行うには会員登録(無料)が必要です。
既に会員の方はを行ってください。
独善のススメ連載記事一覧

もっと読む

この記事の著者

にし たけよし(ニシ タケヨシ)

某社で組込み系ソフトウェア開発に従事。ソフトウェア開発手法に興味を持ち、様々な手法にチャレンジしている。社内/社外を問わず、様々なセミナーやワークショップにも出没。最良のソフトウェア開発手法を追い求め、日夜修行中。知る人ぞ知る、自称『歌って踊れるプログラマ』。

※プロフィールは、執筆時点、または直近の記事の寄稿時点での内容です

この記事は参考になりましたか?

この記事をシェア

CodeZine(コードジン)
https://codezine.jp/article/detail/3804 2009/04/03 11:31

イベント

CodeZine編集部では、現場で活躍するデベロッパーをスターにするためのカンファレンス「Developers Summit」や、エンジニアの生きざまをブーストするためのイベント「Developers Boost」など、さまざまなカンファレンスを企画・運営しています。

新規会員登録無料のご案内

  • ・全ての過去記事が閲覧できます
  • ・会員限定メルマガを受信できます

メールバックナンバー