ciklone(サイクロン)のリリース前に、自分たちが実際にプロジェクトで利用して、 ciklone(サイクロン)を改善してきました。 サイクロン開発プロジェクトの最後の6ヶ月間にソフトウェアのライフサイクルをくり返します。すべての機能を使いながら、「BTS/SCM/プロジェクト管理に必要なことができ、効率的か」、を試験してきました。

開発しながら、実際の現場で利用することで、バグがどんどん見つかったし、使いにくい点、改善すべきことがよく見えます。自分たちが作ったシステムを自分たちのプロジェクトで使う最大のメリットだと思います。

よくいわれる「ドッグフードを食べる」ことをやったことで、BTSやバージョン管理に必要な機能と必要ではない機能を切り分けることができ、開発の現場に必要なツールとして、 ciklone(サイクロン)がリリースできました。

「ドッグフードを食べる」とは、 自社で作ったソフトウェアを実際の業務で利用して、評価することです。有名なのはマイクロソフトのドッグフードです。また、Google ケータイも同様です。

シリコンバレー101[Googleケータイ販売で、Googleは何を変えたいのか?]

Googleでは、常に新しい製品や技術を実験しており、短期間でフィードバックと提案を集めるために社員にテストを依頼している。われわれは、これをドッグフーディング(“eating your own dogfood”から)と呼んでいる。

この「ドッグフードを食べる」経験は、お客様からのフィードバックと同じくらい重要なモノになったと感じています。 ベータ版が完成した頃から、特定のお客様にもご利用頂きました。 ドッグフードを食べ、お客様からのフィードバック経験によって、ciklone(サイクロン)はチームにとって、すばらしいソフトウェアを開発するためのプラットフォームとして十分に機能しました。

オープングルーヴでは、ciklone(サイクロン)を最大限に活用して頂き、他社の利用方法を紹介することで、みなさんのチームのソフトウェア開発を効率化とコストダウンしていく支援をさせて頂きます。

オープングルーヴでは、Wikiサイトを使って、実証済みのガイドとベストプラクティス(と考えられる)を提案していきます。

プロジェクトが失敗に終わる可能性は非常に高く、 おそらく90–95%くらい

「オープンソースソフトウェアの育て方」という書籍があります。副題にフリーソフトウェアプロジェクトを成功させるコツとあるように、著者がオープンソースプロジェクトでの経験を元に実例を交えて説明されています。バージョン管理システムで有名なSubversionプロジェクトでの実際の経験から書かれています。 実践的な内容なので、ぜひソフトウェアエンジニアの方には読んで欲しい内容です。 （技術的な側面よりもオープンソースプロジェクトをうまく運営するための考え方やプロジェクト運営方法についての説明が多くなっています。）

さらに、うれしいことにウェブで全文を公開しているためだれでも読むことが出来ます（当然、日本語で）300ページにもなる専門的でためになる文書を公開された作者の方と翻訳者の方に感謝しなければいけません。

本の内容で特にビジネスアプリケーション開発の困難な点と共通する部分が多く（同じソフト開発なので当たり前ですが）さらに多くの課題に対処するための方法も参考になります。 「3. 技術的な問題」で紹介されているツールとその運用方法は、ビジネスアプリケーションの現場でも十分有効に使えるので、新入社員などに読ませるのも良いと思います。紹介されているツール群は若干古いですが、どのようなツールを、どのような場面で、どのように使っているのかを知る上でとても分かりやすいです。

また、「6.コミュニケーション」などは自分たちの開発でも学ぶべきコトが多いと思った部分で、読んでおくべき章だと思います。

• 書いたことがすべて
• 陥りがちな罠
• 付録C.なんで自転車置場の色まで気にしなきゃならないの？

ソフトウェアエンジニアに求められる能力として、はじめに思いついたことは、「文章を作成する力」です。コミュニケーション能力や提案力、プログラミング能力などよく言われる能力も必要であると思いますが、自分の考えを正確に正しく伝えるための書く力はインターネットが仕事に欠かせないツールになったことで重要であると考えています。

そのためには書く（まとめる）内容以前に考える力が重要になってきますが。。。

あなたの開発チームはバグ管理をどのようにやっていますか?

組込みシステムエンジニアやWebアプリケーションエンジニア、多くのソフトウェア開発に携わる開発者達。 製品開発やシステム開発の現場で「バグ管理」はどのようにおこなっているでしょうか。

• 「ワープロソフトやスプレッドシート?」
• 「オリジナルのツール」
• 「高いライセンス料を払ったシステム?」
• 「オープンソースで構築」

様々な方法でプロジェクトのバグを管理していると思います。

この記事を見てくださった方達はバグ管理の重要性を知っていて、今のやり方になにかしらの課題があって改善したいとお考えだと思います。

プログラムを開発するとき、複雑で大量にある課題・タスク・バグをきちんと漏れなく管理し、 データベース化しておくことは重要なことです。プロジェクトの成果物やリソース、活動状況をすべて追跡できる仕組みを導入することで、 問題を発見しやすく、製品の品質向上に繋がります。

複雑で大規模化しているソフトウェア開発にとって、バグ管理システムは必須のツールです。

ここで、バグ管理の必要性（メリット）について書き出してみたいと思います。

• バグデータベースが用意されることで障害についてチーム内の意思疎通がスムーズになる
  • 標準化されたレポートは、自由形式の電子メールや机越しの話よりも正確に内容を伝えることが出来ます
• データベース化することで、バグの通番管理(追跡と参照)が自動化され、レポートのための分析や報告が提供できる
• 開発チームは、プロジェクトチーム、マネージャ、顧客、ユーザのそれぞれにとって重要な観点から考え修正を進めることができる。
  • バグ管理システムを使わない場合、開発者やテスターの声が大きい担当者の報告したバグほど早く修正されがちになる
• バグの発見→レポート→担当者割当→解決について、全てのライフサイクルを通じたバグ管理が出来る。
  • バグがどこかのライフサイクルに潜り込み、早期修正が必要なバグから注意がそれることがない。
• 開発チームやプロジェクトチーム、テスターの全員が最新の状況を簡単に入手できる。
• 解決したバグはナレッジとなる。
  • これらのバグ情報は、出荷される製品に紛れ込み、サポート部隊のコストを上げる原因、売上の伸び悩み、使えないシステムという辛らつな評価につながる傾向を見つけることが出来るかも知れない。

参考資料:基本から学ぶテストプロセス管理 – コンピュータシステムのテストを成功させるために -

---

Webベース バグ管理&バージョン管理システム「Ciklone」
60秒ではじめることが出来る、ソフトウェアエンジニアのためのバグ管理システム

少し古い情報ですが2009年7月頃に、2009年版の組込みソフトウェア産業実態調査報告書が公開されています。 これは、経済産業省がおこなっている組込みソフトウェアに係る企業・個人を対象に調査を行い、その調査結果をまとめた資料です。2003年から毎年行っているようです。

調査内容も多岐にわたり、

1. 経営者及び事業責任者向け
2. プロジェクト責任者向け
3. 技術者個人向け
4. 海外向け

と分けられて詳細な調査報告が掲載されています。

ref.2009年版組込みソフトウェア産業実態調査報告書の公表について（METI/経済産業省）|

2009年時点で組込みソフトウェア開発のプロジェクト概要をみていると、

プロジェクトの予算

• 開発の基本方針として、自社開発をしている企業が5割（系列会社含む）
• プロジェクト費用の総額は2000万～5000万が最も多く(約19%)、次いで5000万～1億(約18％)
• 1000万～1億規模のプロジェクトが全体の50％

開発ソフトウェア

• 新規開発(コード)行数の平均は21.7万行
• 新規、既存あわせた行数の平均は181万行
• 言語はC言語で約68%が利用

このソースコードの規模の大きさに驚きます。 新製品を開発する場合、ゼロからソースコードを書くことは考えにくく、 ほとんど既存の製品で開発したコードを再利用して新しい機能を組込み、製品化しているだろうと想像できます。 実際にソフトウェア開発は組込み以外では、エンタープライズ系も同様に過去の資産を再利用して開発することはけっこうあります。このとき開発規模が小さければ、過去の資産を利用するのか、捨てるのか判断は比較的簡単にできますが、上で挙げたように組込みの場合簡単ではなさそうです。

その判断を下すための調査だけで、開発者の仕事は楽しいものではなく泥臭い作業になる場合がほとんどです。 現場では、スパゲティプログラムと言われるコードやツギハギだらけのライブラリ群。このような過去の資産を取捨選択し、方向だけでも教えてくれる仕組みがあればどれだけ助かるか分かりません。

ソフトウェア開発をサポートするツールはたくさんありますが、普及していない、便利さが分からない、メリットがわかりにくい、など埋もれている製品がたくさんあります。

今後、ソフトウェア開発（プロジェクト管理）に活用できる情報やツールなどを調査していきたいと思います。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

基本的には

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

[         ->対応なし             ]

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

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

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

zeera document searchで社内文書検索