社内での仕事術 #1

社内での仕事術について紹介したいと思います。 ソフトウェア開発は一つ一つの案件をプロジェクトとしてすすめるため、はじめにプロジェクトチームを作ります。

プロジェクトチームは提案内容や得意分野により主担当がかわります。 プロジェクトでは複数のメンバーが集まって仕事をすることになるため、情報共有はとても重要。

オープングルーヴではどのようにしているのか、ツールを使った情報共有#1として「Wikiを仕事で使う」について書きたいと思います。

Wikiとは「ウィキ」と言いますが、ウェブブラウザを使ってページの作成・編集ができるコンテンツサービスです。一人でメモ書きとして利用している方もいると思いますが、けっこう書込のためにページを開く。という動作が面倒になりがちということはあると思います。

弊社で利用する場合は、複数のメンバーでプロジェクトを進める上でガリガリ書き込みます。これはあるルールを決めているためですが、そのルールのおかげでWikiがなくてはならいツールになっています。

ルール : プロジェクトの成果物(中間成果物)はWikiで一元管理

Wikiのメリット

• 会議をしながら議事録(画面を見ながらみんなで確認)
• 顧客向けの議事録
• 顧客との打合せで出来る議事録はWikiをPDF化やメールで共有
• 設計書(技術メモ、検討メモ)、技術方式に対する他チームのコメント
• 開発環境構築メモなど、開発に関わる情報源
• 世代管理機能、ページ単位で履歴を確認し、追加された・削除されたがカラー表示される(下図)

などなど、メールでも同様のことはできますが、プロジェクトのポータルとして利用でき、大切な文書が埋もれない･･･(メールは探すのが大変) プロジェクトメンバーで使うことで、ガリガリ更新され、すぐにWikiが必須の情報共有ツールになりました。

デメリットは…

しかし、良い面ばかりではないです。新しく加わったメンバーなどにとっては使ったことがないツールのため、慣れるまで大変かも知れません。 「Wikiを知らない人や初めて使う人にとって慣れ親しんだインターフェースではない。」ということです。ファイル名がない、特殊なフォーマット･･･

Wikiを仕事で使いたい人へ セキュアで、1プロジェクト無料のcikloneを評価してください。

バグのライフサイクルを管理する仕組みがバグトラッキングシステムの特徴の1つである。

簡単に言うと、「バグの発生～調査～対策～確認」のバグ1件毎にステータスを管理する仕組みのことである。

なぜ、バグのステータスを管理必要があるか、というとExcelをつかったバグ管理を実践してみるとわかると思う。

こちらの記事(「とりあえずバグ管理」のための Excel テンプレート)

でバグ管理に必要な項目をリストアップしたが、バグの「状態」をもう少し運用に沿った仕組みで管理したくなる。

Excelを使ってバグ管理の運用をしていくと以下のような課題が挙がると考えられる。

• いつ、だれが、どのような対応をしたのか?わかりにくい
• 対応履歴の管理が出来ない
• 状態の変更履歴（どのようなフローを経由してきたか）がわからない
• Excelファイルをメール添付してやりとりするため、最新がどれかわからない
• 複数の版にわかれたファイルをマージしなければいけない
• YYYYMMDD_○○○.xls という管理になってしまう

など、Excelではバグ管理できないわけではないが、開発者にとっては運用するだけでストレスを感じてしまう場合が多い。

弊社ではバグトラッキングシステムを利用しているが、これは開発者にストレスをかけないために導入したという経緯があるためである。

これまでの経験上、Excelで運用していくと破綻してしまう場合があるので、バグトラッキングシステムはソフトウェア開発では必須のツールになっている。

バグトラッキングシステムの中で最も必要な機能が「状態（ステータス）」とワークフローである。 以前にブログで紹介した、「ソフトウェア開発:バグ管理方法の紹介」で簡単にワークフローについてイメージ図を紹介したが、バグのフローとは

• 1. バグの発生(発見者)
• 2. 担当者への振り分け
• 3. 担当者の対応
• 4. バグの完了確認(対応済みかどうか)
• 5. バグの完了

である。 ソフトウェア開発の現場では、バグの数も半端な数ではなく大量に発生する。それらバグ1つ1つのワークフローをきちんと管理できる仕組みがバグトラッキングシステムの大きなメリットであると考えている。

会社やプロジェクトによって、ワークフローはもっと複雑になっていると思うが、

基本的には

[発生->割当->対応中->確認待ち->完了]

[         ->対応なし             ]

が管理できれば十分である。

今回はバグの場合のワークフローについて書いたが、機能追加の要望、タスクなども同様にワークフローを決めて運用することでソフトウェア開発の効率は格段に上がると思う。

OpenGrooveの社内検索システム : zeera document search

zeera document searchで社内文書検索

Peace Pipe: 効率の良いコードレビュー [software] を読んでソースコードレビューの必要性について考えてみたい。

ソースコードのレビューをやっているか?

ツールなどを使ったソースコードチェックは多くのSIerで行われていると思うが、ここではソースコードレビューについて。 プロジェクトによっては「全くやっていない」「重要なプログラムだけ選んでやっている」など、プロジェクトの状況、状態によって異なると思う。

自分の過去の開発経験では、プリントアウトしたソースコードを2人で組になって読み合わせをした。

1. 1. 開発者がレビュアにロジックを説明する。
2. 2. レビュアーは疑問に思ったことを聞く。
3. 3. ここで、機能的な不具合、アルゴリズム、モジュール分割をみる

時間的な制限があるためすべてのコードについて実施できない場合がほとんどだったため、レビュー対象となるソースコードは次のような点を考慮してレビュー対象を決めていた気がする。

• 特定の担当者が作成したコード
• 共通モジュール
• サーバサイドのコード
• ソースコード(処理)が複雑であるコード(プロジェクトによって複雑度は異なる）
• ソースコードをざっと眺め、引っかかるコード、気になったコードを見つけた場合

ソースコードレビューについて、誰が行うか、観点は?の説明されている以下のサイトが参考になる。

IPA ISEC 第2章 脆弱性回避策とソフトウェア開発工程：ソースコードレビュー

観点

• コーディング規約、命名規約に従っているか
• 言語特有の技術的なノウハウに違反していないか
• ロジックエラー、仕様違反していないか
• 深すぎるネスト、巨大すぎる関数など･･･

ソースコードレビューの必要性として特に言われることとして、以下の2点がある。

「開発者のスキルが上がる」

開発者よりも高いスキルをもつレビュアが、ソースコードのレビューを行うことで、書き方の指導や考え方のトレースをすることになり、開発者のスキルを向上させることができる。 ソフトウェア開発では特にその”人”のスキルに依存しがちである。長い目で見て開発者のスキルを上げることが品質の良いシステムを開発する上で最も効果がある。

「ソースコードの質がよくなる」

ソースコードレビューによりバグを抽出することで品質が向上する。検出されなければいけない工程で確実に検出できることは必須であると思う。当然、前工程で検出されたバグ修正も少ないコストで可能である。 ソースコードが第三者の目に触れず、開発者だけが「正しい」と認識することは避けるべきであり、その仕組みをチーム内に作っておくことは重要である。 進捗ミーティングや報告会と同様にコードレビューを定着させるべきだと思う。

ソフトウェア開発プロジェクトでは、単体/結合/総合/受入試験と製品開発の工程により観点の異なる試験フェーズが存在している。

試験の目的の1つは、

「ユーザが利用しているとき、故障が発生しないよう、事前にあらゆる種類の故障を見つけておくこと」

である。 しかし、現実的に全てのバグを発見することは難しい。

そこで、「良い試験項目」を作成し、限られた時間内に多くのバグを見つけることを行う必要がある。 今回は試験工程（単体、結合、総合）で試験内容の粒度・観点について説明すると

それだけで相当な文書量になるため、「良い試験項目とは?」として押さえておかなければいけない点を説明したい。

「良い試験項目」とは

• 試験実施の方法が説明してあること
• 期待値（捜査の結果）が明示してあること
• 「試験日、担当、結果」が記録されること
• バグを発見できる可能性が高い内容であること
• 重複がないこと
• 単純すぎず、複雑すぎないこと

試験項目を作成するときには、工程や手法によって異なるが「ソフトウェアテスト – Wikipedia」で説明されている点と同じように、

「バグはどうやって発生するのか?」

を考えながら試験項目を作成するとうまくいく場合が多い。

また、バグデータベース（過去の失敗事例、バグトラッキングシステム/BTS）があれば、過去の事例からバグを分析してみると参考になることが多い。

開発の現場でよく発生する例として

本来なら前工程で検出されなければいけないバグが、後工程でみつかることがある。

「なぜ、見つけなければいけない工程で漏れてしまい、後工程で見つかったのか?」

をプロジェクトメンバーが考えることが品質の向上、次のプロジェクトの分析材料になっていく。

過去のプロジェクトの失敗事例や「なぜ、バグが漏れたのか?」をチームで考え、

共有していくことが品質管理の第一歩だと考えている。

zeera document search

「バリバリ働きマン」「めんどくさがりさん」 zeera document search で仕事の効率Up!

近年、ソフトウェア開発の品質管理についてのセミナーやイベントが増えてきていると思う。これは官公庁などが数年前から言ってたことで、ソフトウェア産業の課題として「ソフトウェアの信頼性向上」がもっとも急がなければならない課題であると言われている。ことに関係してると思われる。

• 組込みソフトウェア産業の課題と政策展開(pdf)

上の例は組込ソフトウェアを中心に業界全体について記述されているが、自分たちの一番身近なところでソフトウェアの品質管理に役立つであろう、Excel テンプレートを公開したいと思う。

当社のようにエンタープライズ系のソフトウェアを開発している企業においても、課題管理、障害管理、バグ管理といわれる情報を簡単に確実に管理することは、開発の効率化やバグを漏らさずに修正し、品質の向上につながると考えている。 特に

• バグの発生日、発見者、再現方法、対応者、対応内容、テスト状況等の情報管理
• ソースコードの変更、改修内容、改修理由

を追跡できることが重要である。

バグ管理のためのシステム「バグトラッキングシステム」があるが（実際に当社の開発では利用している）いきなり、バグトラッキングシステムと言っても導入までの手順や仕組みを理解する必要があり、障壁は高い。

そこで、「もっと簡単に、だれでも、すぐに」バグ管理をはじめることができる、MS Excel テンプレートを公開する。

バグ管理をするために最低限必要なこととして

• 起票日 障害を発見した日を入力する
• 起票者 障害を発見した人の名前を入力する
• 区分 バグか課題か要望なのか･･･を決める
• 状態 バグが発生した後、現在の状態「未着手」「完了」「対応なし」などを管理するための場所
• 内容 バグの再現方法や発生状況をわかりやすく書く場所

ここまでの情報がバグを報告する人が記入する内容である。

バグに対して、開発者側の項目として

• 担当(チーム、人） だれが担当するのか名前を入力する
• 回答日/対応日 バグに対して回答した日を入力する
• 対応内容 対応した内容を出来るだけ分かりやすく入力する

簡単にということで項目を挙げていったが、多くなってしまった。

実際に開発現場で運用する場合、もっと多くの項目が必要になると思われる。 もし利用されるという方は、自分たちの環境やワークフローに合わせてカスタマイズしてもらえればと思う。

ダウンロードはこちら(template_bts.zip)

Microsoft Excel 2003 にて確認。 NOD32(2009/07/16)でウィルスチェック済み