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

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

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

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

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

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

Wikiのメリット

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

Wikiによる備忘録・ルール

Wikiの世代管理(履歴)

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

デメリットは…

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

基本的には

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

[         ->対応なし             ]

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

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

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

zeera document searchで社内文書検索

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

ツールなどを使ったソースコードチェックは多くの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)でウィルスチェック済み

プログラムを作成することはほとんど不可能と考えられている。(バグとは)

開発者はプログラム作成において、バグを取り除く作業に多くの時間が費やされることになるが、 そのデバッグ工程で大活躍しているツールとバグ管理方法について紹介したいと思う。

ソフトウェア企業で障害管理表、バグ管理表といえば MS Excel や MS Word で管理している企業は多いと思う。 実際に過去自分が関わったプロジェクトでは Excel が多く利用されていた。

弊社でのバグ管理方法は、Trac といわれるバグトラッキングシステム(Bug Tracking System/BTS) を利用して管理している。 ほとんどすべてのプロジェクトでバグトラッキングシステムを利用しているが運用するためには最低限のルールが必要になる。ルールを守って、だれでも簡単に運用できるようにしなければ、チーム内でうまく利用されない。

これから導入を検討されている方の参考になればと思う。

基本の考え方

• プロジェクトスタートと同時に開発用の BTS を準備
• プロジェクト内で発生するバグ・課題は必ず BTS に登録すること
• 「BTS に登録されないバグや課題は対応しない」など、徹底させるためのルールをはじめに説明

運用方法

1. すぐやる / 都度やる

バグや課題は見つけたときにすぐ登録、「あとで」は忘れるもと。導入後でデータ登録 が一番めんどうだが、メリットを考えるとちょっとの努力を惜しまずにやる。

1. 各プロジェクトの管理責任者を決める

BTSの導入後、チケットの乱発、処理されないチケット、担当のいないチケットがいつ までも残ることがあるので、管理責任者を用意する方がうまくいく。

1. バグ・課題のクローズはチケット作成 バグ・課題(チケット)をクローズする権限は、発行者、各プロジェクトの管理責任者、品質保証のメンバー

チケット運用イメージ(ワークフロー)

BTS のワークフロー

開発サポートツールをうまく導入するために、できるだけシンプルなルールだけを決めて運用してきたつもり。 開発者ならだれでも使えるだろう Excel や Word ほど学習コストは下げられないが、一度利用しはじめたら そのメリットから開発には必須のツールになる。

まだ導入していないソフトウェア開発者の人は、ぜひ導入を検討してもらえれば幸いである。

プロジェクト失敗の原因は様々あると思いますし、多くの人たちがより良い方法を考えていますが「これだ！」と言われる方法はなく、プロジェクトの規模・内容によって試行錯誤されていると思う。特定の業務では正しいと言われる方法はあるかもしれないが。

その失敗理由について「プロジェクトリーダ/マネジャの力不足」と終わらせてしまっては何も生まれない。

これまで携わってきたプロジェクトの中で特に難しいことの1つに工数見積があります。

破たんした見積もりはプロジェクト失敗への近道 － ＠IT自分戦略研究所

最近自身も経験したことで概算見積がある。 見積手法と言われる方法は様々あるが、これらの方法は顧客の要件が確定している場合、または確定後のフェーズで利用される手法と理解している。 しかし、実際の開発現場では担当者から引き合いレベルで「予算化するために概算見積がほしい」という依頼がよくある。これに対応する場合「FP法などは利用できないなぁ。」と。顧客にとってもこれから導入しようと考えているソフトウェアにいくらかかるのか? 費用対効果は? を判断するために早く概算見積が必要名のは理解しているつもり。

どのようにやっているのかと思って、あるソフトウェア開発企業でプロジェクトリーダの方に聞いたところ、

• 現状で分かっている要件から機能毎の工数を積み上げていく
• それに2～3倍を掛けて提示する(笑)

この「工数を数倍」というところが重要で実際にプロジェクトが完了した時点で「トントンになるか」「すこしマイナス」という場合がけっこうあるという話を聞いた。 この数字に根拠があるわけではないと思うが、甘い見積では確実に穴があり、痛い目をみる。見積精度を高める努力はしているがやっぱり難しい。

[Think IT] 第1回：工数見積もりの見える化 (3/3)

エンタープライズ系ソフトウエア開発における見積もり手法 … 「類似プロジェクトからの類推」 「プロジェクトリーダや担当者の経験」、 そして「積み上げ」が三強で全体の90%以上を占める。

• 見積の間違いはチーム全体を不幸にする、顧客にとっても。
• 正確な見積はできない。限りなく正しいと言える見積はあるはず
• 開発者と顧客が喜ぶことが出来る結果を目指す

開発側ばかりに負担をかけることも問題、顧客側に負担をかけることも問題、開発側と顧客側が満足できるソフトウェア開発とプロジェクト管理の両立を目指したいですね。

[見積手法]

ソフトウェア測定法 – Wikipedia

[Think IT] 第1回：工数見積もりの見える化