wiki:pne-book-9-4
 ここの情報は古いです。ご理解頂いた上でお取り扱いください。

Version 12 (modified by imoto, 12 years ago) (diff)

--

TOC

OpenPNEのチーム開発

解説:小川、海老原、酒井
文:井本

概要

現在、OpenPNEは基本的にチーム開発で開発を進めています。
その理由としては、OpenPNE開発はバグ修正、ドキュメント、開発など仕事が多岐に渡り個人がバラバラに動くよりチームとして役割を決める方が開発の効率が上がるということが挙げられます。しかし、チーム開発をする上でいくつかの障壁もあります。
中でもやはり情報共有やコミュニケーションといった開発者間での情報がスムーズに流れにくいという点が挙げられます。開発者間での情報がスムーズに流れなければ、開発効率が落ちて、チーム開発で開発を行うメリットは少なくなります。
そこで今回は、OpenPNE安定版を開発しているチームを中心に、OpenPNEがどの様な流れで開発されているかを紹介しながら、OpenPNEのチーム開発を見て行こうと思います。

目次

リリースガイドライン

実際のOpenPNEのチーム開発を見る前に、まずはOpenPNEのリリースガイドラインを一部参照しながら、OpenPNEのリリース方針を見てみましょう。

OpenPNEには現在「開発版」「安定板」という2つの製品があります。
今回は、安定版の開発を中心に見ていくので開発版のガイドラインは割愛します。もし開発版のガイドラインを参照したい方はOpenPNE開発のガイドラインの開発版リリースガイドラインを参照してください。
それでは簡単に安定版リリースガイドラインを見ていきましょう。

OpenPNE開発のガイドライン
http://trac.openpne.jp/wiki/pne-guidelines

安定版リリースガイドライン

OpenPNEには、リリースガイドラインがあります。基本的に、このガイドラインに則ってOpenPNEの開発を進めています。

OpenPNE安定版はOpenPNE2.10までは3ヵ月ごとのリリースをしてきました。しかし、OpenPNE2.10のからリリース期間が3ヵ月から6ヵ月に変更になったことによってこのリリースガイドラインも大きく見直されました。
中でも大きく見直された部分は機能追加条件です。3ヶ月から6ヶ月になったことで、製品の信頼度は上がるが、新たな機能の追加まで期間が長くなるというデメリットも出てきました。そこで、この機能追加条件をリリースガイドラインに追加し、機能追加条件を満たしたものであれば、安定版にも機能が追加されるようにしました。この機能追加条件を導入したことによって、OpenPNE開発版のバージョンアップが3ヶ月から6ヶ月に変更になっても機能追加がされ常に新しいOpenPNEを使うことが出来る様になりました。

また、OpenPNEはメンテナンス期間が長いというのも特徴です。OpenPNEでは常に2つのバージョンをメンテナンスしています。
例えば、OpenPNE2.12のベータ版がリリースされる時には、OpenPNE2.8のメンテナンスが終了します。この様にある程度長い期間安定版のメンテナンスしているので、安心してOpenPNEを利用出来るのも特徴です。

リリーススケジュール

  • 原則として、月に一度リリースする
  • リリース日は基本的に第3水曜日とする
  • 緊急のバグが見つかった場合は、上記日程に関係なく緊急リリースを行う

機能追加条件

  • リリース2週間前までに開発版としてリリースされている(コミットされているだけでは不十分)
  • DB構造変更の必要がないもの
  • 安定動作に支障がないと判断されたもの

メンテナンス期間

https://trac.openpne.jp/svn/prj/pne-book/pne-book-9/pne-book-9-4/1.png

OpenPNE開発のガイドライン
http://trac.openpne.jp/wiki/pne-guidelines

チームと開発の流れ

それでは、いよいよOpenPNE安定版のチームと開発の流れについて見ていきましょう。
まずは、どのようなメンバーでOpenPNE安定版が開発されているかチームメンバーのプロフィールと仕事内容を簡単に紹介します。次に、誰がどのような流れで開発を進めているかを紹介します。

チーム

現在OpenPNE安定版はチーム小川という小川さん率いるチームが開発をしています。現在チーム小川は数名のメンバーがいますが、今回は小川さんも含めこの安定版リリースに関わる3人のチームメンバーの紹介をします。

■■■■■■ここは最後に開発者紹介から抜粋する■■■■■■■■■■■

小川 倫平
(画像)
チームリーダ

海老原 昂輔
(画像)
自己紹介
酒井 希和
(画像)
バグ収集、要望収集

開発の流れ

それでは、OpenPNEの安定版がどのような流れで開発されリリースされているか基本的な流れを見ていきましょう。
基本的には以下の様な流れで開発しています。しかし、常にこの流れで開発を行っているというわけではなく、バグ収集や要望の収集の様に常に活動しているものもあります。しかし、今回は分かりやすく説明するためにこの様な流れでOpenPNE開発をしているということにし、OpenPNEのチーム開発について紹介していきたいと思います。
それではここからは、酒井さん、海老原君、小川さんに仕事の内容とチームとしてどのように役割を分担しながら開発を進めているかを解説して頂きます。

  1. バグ、要望収集(酒井)
  2. バグ再現(酒井)
  3. 開発(海老原)
  4. 動作テスト(酒井)

バグ、要望収集

概要

それでは「バグ、要望収集」は酒井がバグ収集の解説をしていきます。
まずは、バグ収集の流れを説明してその後、実際にどこでどのようにバグを収集しているかという説明をしていきます。

流れ

  1. OpenPNE.jp内のバグ要望収集コミュニティで最終IDを確認
  2. 収集する日記数・トピックコメント数を計算
  3. 日記・OpenPNE開発談義にて収集開始報告
  4. 管理画面内でIDの古い順から日記・トピックコメントを確認
  5. バグを発見
  6. チケット作成
  7. バグ報告者へお礼のコメント
  8. トピックで報告

https://trac.openpne.jp/svn/prj/pne-book/pne-book-9/pne-book-9-4/2.png

バグ収集はおよそこの様な流れで進んでいきます。
バグや要望の収集というのは安定版リリースのためにやるというのではなく、OpenPNE品質向上のために常に行っています。

以前バグ収集はwikiを用意してこちらに書いてくださいという形で場所を用意する形をとっていましたが、実際あまり収集できていない状況でした。しかし、実際は何らかのバグがあったり、「OpenPNEにこんな機能を入れて欲しい」という要望は頂いていました。そこでいろいろな方法を考えているうちに、日記でバグや要望について書いている人が多いことに気づき、ここでバグ収集や要望の収集をしようという結論に至りました。
この方法でバグ収集や要望収集をすることによって以前より報告するという行為の敷居が下がり報告の件数も増加しています。

収集方法

基本的にはOpenPNE.jp~OpenPNE公式SNS~の中でバグ収集や要望収集を行っています。
OpenPNE.jp~OpenPNE公式SNS~の中に「バグ・要望吸い上げチーム」というコミュニティがあります。現在はこちらでそのバグや要望の収集結果を報告しています。
バグがどのように収集されたか詳しく知りたい人はこちらを参考にしてみてください。

それでは、先ほどの流れ通り上から見ていきたいと思います。

https://trac.openpne.jp/svn/prj/pne-book/pne-book-9/pne-book-9-4/3.png

OpenPNE.jp~OpenPNE公式SNS~
http://sns.openpne.jp/
   
バグ・要望吸い上げチーム
http://sns.openpne.jp/?m=pc&a=page_c_home&target_c_commu_id=393

OpenPNE.jp内のバグ要望収集コミュニティで最終IDを確認

まずは、OpenPNE.jp内のバグ要望収集コミュニティで最終IDを確認します。

https://trac.openpne.jp/svn/prj/pne-book/pne-book-9/pne-book-9-4/4.png

基本的に前回のバグ収集、要望収集を行った後にこの様な形式でコミュニティのトピックに書き込んでいるので、まずはその最終IDを確認します。この最終IDの次のIDから収集を始めます。

【最終確認ID】
日記:*****
トピック:*****
トピックコメント:*****

-----------------------------
収集したバグのタイトル
収集したバグのURL

収集する日記数・トピックコメント数を計算

次に、集計する日記の数とトピックコメント数を計算します。
これは、次のOpenPNE開発談義で報告するためです。

日記・OpenPNE開発談義にて収集開始報告

次に、Skypeのオープンチャット「OpenPNE開発談義『雑談』」で収集開始を報告します。
このOpenPNE開発談義『雑談』はOpenPNE開発者が雑談などOpenPNEの話をする場所です。
仕様策定についての議論など、リアルタイム性が必要なコミュニケーションをこのチャットルームで行っています。Skypeといえば音声通話と言うイメージがありますが、ここでは音声通話機能は利用せず、テキストベースのチャットルーム機能を利用しています。Windows MACの最新Skypeはオープンチャットに対応しているので興味があればぜひ参加してみてください。

OpenPNE開発談義『雑談』に報告するときは、以下のフォーマットで開発談義に報告しています。一言コメントなどを入れてコミュニケーションを図ることを心がけています。

【確認件数】
日記:***件
トピック:***件
トピックコメント:***件
一言コメント

https://trac.openpne.jp/svn/prj/pne-book/pne-book-9/pne-book-9-4/5.png

ツール紹介
    
  Skype公式サイト
  http://www.skype.co.jp/
  
  (Skypeのスクリーンショット)

OpenPNEでは、コミュニケーションの手段としてSkypeを活用しています。
現在オープンチャットとして、OpenPNE開発談義『雑談』を公開しています。
参加方法は、OpenPNE.jp~OpenPNE公式SNS~(http://sns.openpne.jp/)の右サイドバーの「OpenPNE開発談義Skypeチャットルーム」をクリックすると、参加することが出来ます。
OpenPNEを開発するときも、プロジェクトのグループチャットを作ったりとさまざまな活用をしています。

管理画面内でIDの古い順から日記・トピックコメントを確認

https://trac.openpne.jp/svn/prj/pne-book/pne-book-9/pne-book-9-4/6.png

管理画面内で一つ一つ目で見て確認していきます。
基本的にはすみつきカッコ(【バグ】)で覆われているものだけに注目して収集していきます。要望がある場合も、すみつきカッコ(【要望】)を収集しています。

バグを発見

https://trac.openpne.jp/svn/prj/pne-book/pne-book-9/pne-book-9-4/7.png

バグ報告の日記を発見したら、このバグについてOpenPNEのTracにチケットを作成します。

ツール紹介
    
The Trac Project
http://www.edgewall.com/trac/

  (Tracのスクリーンショット)
  
Tracはバグ追跡、バージョン管理、wikiなどを統合したオープンソースのソフトウェアです。また、Subversionのリポジトリブラウザ機能も兼ね備えており、ソースコードの管理も出来ます。
  
現在OpenPNEプロジェクトにはTracを使っています。以前はwikiやCVSでバグやバージョンの管理を行っていました。しかし、現在はこのTracにすべての情報を集約してOpenPNEを管理しています。
また、OpenPNEでは社内の業務などもTracのチケットと呼ばれるバグ追跡システムを利用して管理しています。チケットでTODO管理を行っているチームもあります。
チーム小川では報告連絡などもこのチケットのやり取りで行っています。このように、OpenPNEのチーム開発だけではなく、手嶋屋ではTracを十二分に活用し、チーム開発やプロジェクトを進めています。
 

チケット作成

次に、先ほど発見したバグのチケットを作成します。

チケット作成にはある一定のフォーマットを設けてあり、誰がチケットを作ってもそのチケットの品質を保つことが出来る様にしています。

チケット作成フォーマット
    
=== ■現象 ===
発生した現象を記入

=== ■発生バージョン ===
バグが発生したバージョンを記入

=== ■再現手順 ===
バグを再現するための手順を記入
(手順をかきようがない場合は空欄でかまわない)

=== ■環境 ===
バグが発生した環境を記入
 * OS
 * ブラウザ
 * 携帯キャリア・機種
 * サーバ環境
など

=== ■関連情報 ===
報告元へのリンク・関連するチケットなどの補足情報を記入


チケット作成の詳しい情報はOpenPNEのチケット作成はOpenPNE開発のガイドライン(http://trac.openpne.jp/wiki/pne-guidelines)の「チケット作成ガイドライン」にまとめられていますのでこちらを参照してください

OpenPNE開発のガイドライン
http://trac.openpne.jp/wiki/pne-guidelines
  

バグ報告者へお礼のコメント

このバグ報告者へお礼のコメントは私がバグ収集をしている中で大切にしているところです。確かに、バグを収集するだけでコメントはいらないという意見もあると思いますが、私は必要だと考えています。なぜなら、OpenPNEはコミュニティで作り上げていくもとだと考えているからです。

実際に、何気ないコメントが多いかも知れませんが、そのコメントによってコミュニケーションが図れ、またバグ報告や要望収集をして頂けると非常にありがたいですし、より良いOpenPNEが完成されると考えています。 OpenPNE開発談義『雑談』にコメントしてバグ収集をするというのも、このようにコミュニティの中でOpenPNEを作っていきたい、盛り上げていきたいという気持ちがあるからコメントを続けています。

まだ、日記やコミュニティのコメントなど収集する場所が残っていれば、「管理画面内でIDの古い順から日記・トピックコメントを確認」まで戻ってまた収集を始めます。
この一連の流れを続けます。
そして、収集が終了すれば、次のトピックで報告します。

トピックで報告

さて、最後のトピック報告です。報告する場所はOpenPNE.jp~OpenPNE公式SNS~(http://sns.openpne.jp/)のバグ・要望吸い上げチームコミュニティです

バグ収集と要望収集を分けて、コミュニティトピックを立ち上げます。
次回の収集開始場所が分かるように、一定の形式で書き込みます。
これでバグ収集の一連の流れは終わりです。

【最終確認ID】
日記:*****
トピック:*****
トピックコメント:*****

-----------------------------
収集したバグのタイトル
収集したバグのURL

まとめ

OpenPNEでは随時バグ収集や要望収集を行っていますが、まだまだ収集しきれていない現状もあります。
そこは試行錯誤して収集していければいいと思っています。しかし、やはりコミュニティの中でOpenPNEをより良いものにしていきたいという軸があるのでその軸がぶれないようにしていきたいと考えています。

以前は要望収集を日記では行っていませんでしたが、現在は日記のタイトルに【要望】と入れるだけでOpenPNEに要望を提出することが出来る様になりました。この様に今後も試行錯誤を繰り返していき、要望収集やバグの収集をしていきたいと思います。

バグ再現

概要

それではまた酒井がこのバグ再現を解説していきます。
このバグ再現にもある程度手順は決まっています。こちらのバグ再現手順と共に、今回は普段使っているツールも紹介しながらバグ再現を紹介していきます。

流れ

https://trac.openpne.jp/svn/prj/pne-book/pne-book-9/pne-book-9-4/8.png

手順としてはこのような流れでバグ再現を行います。
バグは危険と判断されるものから優先してバグ再現を行います。中には一人で再現できないこともあるので、分からない場合はSkypeで小川さんや海老原君にバグ再現を行ってもらうこともあります。

https://trac.openpne.jp/svn/prj/pne-book/pne-book-9/pne-book-9-4/9.png

また、収集したバグの中には環境に依存するものや、情報不足なものもありバグの再現が難しい場合もあります。そのような場合は、なるべくバグ情報をもとに直接コミュニティで聞いたり日記でコメントしてどのような状況でそのバグが発生したかなどの原因を追究するようにしています。

バグ再現方法

バグの再現方法はバグによってさまざまです。
実際に、動作してみてすぐにバグだと分かるものもあれば、どの様な環境が使われているか分からず、再現が困難なものも多々あります。
また、技術的に難しいものやサーバ設定が必要なものなどは開発チームにお願いします。
このように、バグの再現はチケットによってさまざまで、なかなか手順として統一することが出来ません。そのため、バグのチケットを作成する時にバグに関する詳細な情報をチケットに書く必要があります。このチケットの書き方次第で、バグが再現できるか出来ないかが決まります。
曖昧なバグのチケットは作らないで、環境など必要な情報がある場合は、バグを収集するときにバグ情報を提供してくれた人に聞くことが大切です。

まとめ

バグ収集で効率よくバグ報告を収集出来る様になりつつあるので、このバグ再現ももっと効率よくバグを再現してなるべく早く開発しバグを無くすことが大切だと思います。ただ、やはり原因不明や環境の依存などで、バグを再現できていないチケットもたまっています。今後の課題は、いかにしてこのようなバグを再現していくかということだと思います。それはバグ再現の技術を上げることも必要ですが、その前の収集の段階でバグの報告者とコミュニケーションをとってより詳細なバグの情報を得ることが必要だと考えています。
そして、バグ収集、バグ再現を効率よく進めてより良いOpnePNEを作り上げたいと思います。

開発

概要

次は、海老原が再現されたバグを修正をしていく開発流れを解説していきます。
開発と言ってもさまざまなバグ修正の方法があるので、具体的なバグ修正は割愛します。
まず全体の流れを確認して、その後それぞれについて詳しく見ていきましょう。

流れ

1.レポートの作成 1.修正チケットの選定 1.コーディング 1.コードの確認 1.動作テスト 1.リリース

https://trac.openpne.jp/svn/prj/pne-book/pne-book-9/pne-book-9-4/10.png

レポートの作成

再現されたチケットや、バグと認められたあと、チケットとして作成されます。
そのチケットはすべてView Ticketsに集められます。
収集されたバグはTypeがdefectとなっているので、Custom Queryでソートします。
この時、Kyewordsに「再現待ち」「再現せず」「PNEMonster」を設定し、バグでないものを表示しないようにしておきます。

https://trac.openpne.jp/svn/prj/pne-book/pne-book-9/pne-book-9-4/11.png

このチケットの一覧から、ユーザーが不便だと感じたり急ぐ必要があるものを開発者の判断で安定版のチケットに変更します。
そのチケットを開き、KeywordsとMilestoneを変更します。
ここにバージョンを入れることで、このバージョンに対して修正しますということを宣言します。
Milestoneは修正されるバージョンを表します。このMilestoneを集めたものをレポートと呼びます。
例えば、MilestoneにOpenPNE2.10.4と入れると、OpenPNE2.10.4に修正するバグがレポートとして一覧で表示されます。

https://trac.openpne.jp/svn/prj/pne-book/pne-book-9/pne-book-9-4/11.png

安定版のレポートは基本的にdefect(不具合)が多いですが、開発版になると、enhancement(対応済みの機能追加・改善)もあります。
基本的には開発者はこのレポートを見ながら、次にどの不具合を修正するかを決めています。
レポートがある程度完成した段階で、他のOpenPNE開発版チームに見てもらったり、OpenPNEコミュニティに見てもらいながら、レポートを完成させます。

修正チケットの選定

レポートが完成したら、修正チケットの選定に入ります。
レポートは基本的に上からPriotity(優先順位)が高いものから並んでいます。

基本的には、Priotityが高いものから修正に入ります。
始めはCriticalから修正し、次にmajorを修正していきます。
しかし、majorにすぐ修正できるバグがある場合は開発者の判断で修正していきます。

次に、実際にこのチケットを修正したいと思った時にはそのチケットを開き、自分がチケットを修正することを宣言します。
具体的には、そのチケットの下のaccept ticketのラジオボタンを選択して「Submit changes」を押すと自分自身がこのチケットをやりますと宣言したことになります。

https://trac.openpne.jp/svn/prj/pne-book/pne-book-9/pne-book-9-4/13.png

「Submit changes」を押すと、誰から誰にこのチケットの担当が移ったのかがChange Historyとしてチケットに記入されます。
誰も担当していないチケットはnobodyとなっています。
また、このChange Historyが残ることで、以前は誰が担当しているのかなど分かるようになります。
また、reassign toにユーザ名を入れたら自分以外にも他の人にチケットを担当してもらうことも出来ます。例えば、一度やって見たけど、分からなかったので他の出来る人に担当してもらうなどすることも可能です。
しかし、OpenPNEでは基本的に自分がやりたいチケットを自分で担当する方法をとっています。
それでは、次は実際にバグの修正をしながらどのようにバグを修正していくかを解説していきます。

コーディング

ここで、バグと判断されたものに対して修正を加えていきます。

https://trac.openpne.jp/svn/prj/pne-book/pne-book-9/pne-book-9-4/14.png

まずはじめに、開発するチケットを決めたらその現象、原因、関連情報を見ます。
このバグはOpenPNE公式SNSからのバグ報告のようです。
そして、そのバグをローカル環境で確かめます。
今回はcoLinuxにPuTTYというSSHクライアントを使ってSSHでアクセスして開発を行っていきます。OpenPNE開発者の中にはローカル環境にVMwareを使う人もいます。

バグを確認したらコーディングに入ります。

実際にコードを修正したら、ローカル環境でテストします。
ローカル環境で正常に動くようであれば、テスト環境にコミットします。

その後、Tracでバグの修正が完了したことを報告します。

ここではチケットのkeywordsに確認中と入力します。
また、どのリビジョンで修正を加えたかを書いておきます。
このリビジョンのリンクを貼る場合にTracはr5000とするだけでリビジョン5000にリンクを貼ってくれます。

ツール紹介
VMware
http://www.vmware.com/jp/

(スクリーンショット)

現在OpenPNEではVM4PNEとしてOpenPNEの開発を支援するための開発用バーチャルマシンのイメージファイルを配布しています。このイメージを使えばすぐにOpenPNEの開発環境をローカルに作ることが出来ます。VM4PNEの構成は以下の通りです。

VM4PNE
http://www.openpne.jp/docs/vm4pne/

VM4PNEの構成
【OS】CentOS ServerCD4.4最小インストール
【ミドルウエア】PHP、MySQL、Postfix
【アプリケーション】OpenPNE2.8RC2、TRAC、Subversion
【初期ID】admin / VM4PNE root / VM4PNE

coLinux
http://www.colinux.org/

(スクリーンショット)

OpenPNE開発者はローカル環境にVMwareを使う人とcoLinuxがいます。
どちらを使うかは開発者が好みで判断しています。
ただ、初めてOpenPNEのローカル環境を作る場合は、VM4PNEが公開されているので、VMwareの方が比較的簡単にローカル環境を作ることが出来ると思います。

  ツール紹介
    
  PuTTY
 http://www.chiark.greenend.org.uk/~sgtatham/putty/download.html  
  
  (スクリーンショット)
  
  PuTTYjp
  http://hp.vector.co.jp/authors/VA024651/PuTTYkj.html
  
  SSHでローカル環境に接続する時、テスト環境に接続するときに使用しているSSHクライアントです。
  OpenPNE開発者はPuTTYの他に、Tera TermやVaraTermを使う人もいます。
  

コードの確認

次に、実際にコーディングが終わったらソースコードを小川さんに確認してもらいます。

このソースコードの確認ではコードが正常に動作するかなど基本的な確認はもちろん、コードの設計やセキュリティ面での抜け漏れなども確認してもらっています。

確認してソースに不具合があった場合などは確認中のkeywordsが削除され、不具合を修正をします。

そして、良いと判断されたものはテストkeywordsがテスト待ちにされ、testing defect (テスト待ちの不具合)の一覧に入った後に動作テストされます。

まとめ

このような流れで、OpenPNEのバグは修正されています。
以前はバグを修正するのもすごく時間がかかったり、小さなミスがありました。しかし、SVNを使ったり、バグをチケットで管理することで効率が上がると共にミスが少なくなくなりつつあります。
このようにあらゆるツールを使うことで効率よくOpenPNEを開発することを心がけています。

また、この開発で重要なことはソースコードの品質を保つことだと考えています。
一人で開発をするのではなく、ソースコードの確認や動作確認を何人もの人の目を通すことで、ソースコードの品質が保たれています。
このようにしてOpenPNEはソースコードの品質を保ちながら効率よく開発を進めています。

動作テスト

概要

それでは最後に、動作テストを酒井が解説します。
先ほどのバグ修正で実際にバグが修正されているかをテスト環境を使って動作テストをしていきます。
この動作テストのポイントは、実際にユーザー側の視点で動作テストをすることです。
コードを見ただけで修正されたかどうかを判断するのではなく、実際にユーザー視点で動作テストをすることが大切だと考えています。もちろん、開発の段階で開発者はテストをしていますが、あらゆる視点からテストをしてバグの修正抜けや修正漏れを防ぐためにこのように開発が終わった後に開発者以外の人が動作テストをしています。
それでは、実際にOpenPNEがどの様に動作テストが行われてみているか確認していきましょう。

流れ

1.テスト表作成 1.動作テスト

テスト表作成

動作テストをする前に、テストする項目についてテスト表を作成します。
以前はエクセルでこのテスト表を作っていました。しかし、現在はこのテスト表をGoogleSpreadsheetsで管理しています。この理由としては、テスト表を見たい時に一度ダウンロードしてエクセルで開くという動作が必要でしたが、このGoogleSpreadsheetsにテスト表を移行したことで、その手間を省くことが出来ました。
また、このGoogleSpreadsheetsは共有することが出来るので2人同時に編集することも可能なので作業効率が上がるというメリットがあります。

https://trac.openpne.jp/svn/prj/pne-book/pne-book-9/pne-book-9-4/15.png

テスト表は決まったフォーマットを用意し、テスト表を作成していきます。
現在OpenPNEのテスト表には以下のような項目でテスト表を作成しています。
詳しくは、OpenPNEテスト表の一覧を参照してください。

ID 	 1からの連番
ticket 	チケットのURL
Summary 	チケットのSummary
module 	テストする画面のモジュールを(admin,pc,ktai,biz,ktai_biz)
type 	テストする画面のタイプ(page,do)
action 	テストする画面のアクション名
動作 	テストの動作
入力値・設定値 	フォームの入力値、設定値などの条件
結果 	テスト動作から期待される結果
テスト結果 	期待される結果が得えられたかどうか
テスト備考 	テスト結果の補足
OpenPNE テスト表一覧
http://docs.google.com/a/openpne.jp/

テスト項目を作る上で注意している点としてはテスト漏れがないかどうかという点です。
このテスト項目を作った後にテスト項目を作成する人以外の人に確認してもらうということを行っています。この作業をすることで、テスト項目の漏れを防いでいます。

現在は、このGoogleSpreadsheetsを使用していますが、今後テスト表をマインドマップへと移行させていく予定です。
マインドマップでテスト表を管理するメリットとしては、マインドマップの持つ一覧性と関連性がテストに向いているからです。
テストはあらゆることを想定して、どの様な動作が起きても対応出来る様にテストする必要があります。マインドマップを使って、あらゆる動作に気づくことでより多くのテストをして、OpenPNEのバグを発見し、信頼性を高めていきたいと考えています。

現在、手嶋屋ではマインドマップを議事録など日常の業務の中でも使用しており、マインドマップに慣れているという点で、今後テスト表をマインドマップに移行させるときもある程度スムーズに移行できると考えています。手嶋屋ではFreeMindというマインドマップを作成するツールを使っています。

ツール紹介

Google ドキュメント
http://docs.google.com/

  (スクリーンショット)

OpenPNEではGoogleドキュメントをテスト表などあらゆる場面で使っています。
メリットとしては、共有することが出来るという点と同時に編集することが出来るという点です。

ツール紹介
  
FreeMind
http://freemind.sourceforge.net/

(スクリーンショット)

手嶋屋ではこのFreeMindを使ってマインドマップを作成しています。
用途としては、何かアイデアを出すとき、考えをまとめるとき、会議の議事録など幅広くマインドマップを活用しています。
今後OpenPNEのテスト表もこのFreeMindを使って作ることになるでしょう。

動作テスト

それでは実際に動作テストの方法を見てきましょう。
ただ、動作テストはその動作テストによってそのテスト方法が違うので、今回はツールを紹介しながら動作テストの方法を解説していこうと思います。
動作テストによって使うツールはさまざまですが、私が普段多く使用しているのが、「Selenium IDE」「Web Developer」「User Agent Switcher」です。数多くあるツールの中から今回はOpenPNEの動作テストに良く使うこの3つのツールを紹介したいと思います。
この3つのツールはどれもFirefoxのアドオンです。

Selenium IDEは主に繰り返し処理を行うときに使っています。特にOpenPNEはページングの処理が日記、コミュニティ、管理画面などに多く使われています。このように繰り返しの処理の動作テストには、このSelenium IDEを使って自動化しています。

https://trac.openpne.jp/svn/prj/pne-book/pne-book-9/pne-book-9-4/16.png

次に、Web Developerですが、これは主にフォームの値チェックやバリデーション関係のバグ再現で使用しています。OpenPNEには日記やコミュニティトピックなどフォーム入力が多くあります。そのようなフォーム入力のテストなどにはこのWeb Developerを使用しています。
Web Developerの「フォーム」メニューの中にある「フォームの詳細情報を表示する」というというのにチェックをすると、そのフォームの詳細情報を表示させることが出来ます。例えば日記投稿の確認画面などでフォームの詳細情報を表示させると、実際にそのフォームの値を表示させると共に、書き換えることも出来ます。 そこで、フォームのセッションIDを偽装したときにエラー画面がちゃんと表示されるかなどのテストをWeb Developerでしています。

https://trac.openpne.jp/svn/prj/pne-book/pne-book-9/pne-book-9-4/17.png

最後にUser Agent Switcherですが、このUser Agent Switcherは携帯でのテストに使用します。
このUser Agent Switcherは簡単にUser Agent名を変更することができます。しかし、携帯でのテストはこのUser Agent Switcherだけに頼ることなく、実機でのテストが必要な場合は実機でのテストもしています。

このように、実際にテストをするときは効率よくテストをするためにあらゆるツールを使ってテストをしています。ただ、テストツールだけに頼ってテストしていくのではなく、携帯のように実機のでのテストが必要な時は実機でテストしていくことが大切だと考えています。

https://trac.openpne.jp/svn/prj/pne-book/pne-book-9/pne-book-9-4/18.png

ツール紹介

Selenium IDE :: Firefox Add-ons
https://addons.mozilla.org/ja/firefox/addon/2079

(スクリーンショット)

OpenPNEでは主にバグ再現やテストツールとして使用しています。
このSelenium IDEはFirefoxのアドオンとして提供されているため、非常に簡単に導入できるという特徴もあります。
OpenPNEのバグ再現にはあまりしない機能ですが、テストケースをHTMLやPHPなどさまざまな形式でエクスポートできるのも特徴です。

ツール紹介

Web Developer :: Firefox Add-ons
https://addons.mozilla.org/ja/firefox/addon/60

(スクリーンショット)

このWeb Developerは普通はCSSの編集やテーブル表示などに使うことが多いと思いますが、OpenPNEのバグ再現やテストをするときにはではフォーム関連の機能を使うことが多くあります。その他にもWEBページを作っていく上で便利な機能が満載です。

ツール紹介

User Agent Switcher :: Firefox Add-ons
https://addons.mozilla.org/ja/firefox/addon/59

(スクリーンショット)

このUser Agent Switcherは簡単にUser Agent名を偽装することが出来るツールです。
主に、携帯でのテストやバグ再現などに利用します。携帯のテストするときには携帯シミュレータなどを使うこともありますが、このUser Agent SwitcherはFireFoxのアドオンなので比較的簡単に携帯のテストを行うことが出来ます。

OpenPNEチーム開発まとめ

では最後にOpenPNEのチーム開発について小川がまとめます。

チーム開発

現在OpenPNEではチーム開発をしていますが、開発をする上でいくつか大切にしていることがあります。

1.開発者の主体性を重視こと 1.違う視点を大切にすること 1.コミュニティの中で作り上げていくこと

開発者の主体性を重視こと

OpenPNEを開発していく上で、いかに開発者のモチベーションを上げるかどいうことは大切な要素だと考えています。
そのモチベーションを高めるために、この開発者の主体性を重視するということを考えてチーム開発を行っています。
例えば、バグを改善するのもOpenPNEでは基本的に優先順位の高いチケットからバグの修正をしていきますが、その優先順位の高いものの中からどのチケットからバグの修正を始めるのかなどは開発者に任せています。
それは、開発者のモチベーションが開発スピードに依存することを分かっているからです。自分の得意なものや、やりたいことを自ら選択することで開発スピードが上がると考えています。
また、開発ツールも開発者の主体性を重視しています。もちろん、推奨しているツールなども紹介していますが、使い勝手で開発効率を下げるよりも主体性に任せて開発ツールを選択してもらっています。

このように、OpenPNEでは基本的に開発者の主体性を重視して開発を進めています。 もちろん方向性を間違えたりチームとして機能しなくなれば改善はしていきますが、開発者の主体性を重視して開発効率が上がりOpenPNEの品質が向上すればいいと考えています。

違う視点を大切にすること

OpenPNEを開発する上で違う視点を大切にすることも大切だと考えています。
特に、テストやバグ再現の時は違う視点を大切にしています。
開発者とテスターの違いを考えてみましょう。
開発者は開発する上で開発効率の良し悪しを常に考えています。いくつもの機能を修正する際に一箇所修正してあとは同じ箇所を一括で変換すれば他のファイルも適用されて正常に動作するだろうという風に考えます。
しかし、テスターというのはそのような考え方であってはならないと考えています。
常にどこかに穴がないか探りながら慎重に見て実際に検証する必要があります。すべてを信頼しきってしまうことは良くありません。
また、開発者というのは同じ視点を持っている場合や、当たり前という共通意識があったりします。その辺りの視点を変えるという点でテスターは開発者ではない方が良いと考えています。
チーム開発をする上で人の役割分担は非常に重要なことであると考えています。

また、違う視点を大切にすることはテストやバグ再現だけではありません。実際に開発を行うときも、ペアプログラミングを行い違う視点を大切にしています。
ペアプログラミングとは2人で一緒にプログラミングをすることです。ただし、一人がプログラムを書きもう一人はその書いているソースを見るという手法です。この2人の役割を変えながらソースコードを書いていきます。
このペアプログラミングも違う視点を大切にしています。実際にコードを書いている人は自分がソースを書くことに集中しているのでソースの間違えに気づかないことが良くあります。
そこで、もう一人の人が客観的にそのソースコードを見ることで違う視点で物事を見ることができ、ソースの間違えにも気づくことが出来ます。
この様に開発を進めることでソースコードの品質が高まります。

この違う視点を大切にすることというのは一つのことに対して多くの人手を必要とするので一見無駄な様に見えますが、その無駄だと思えることが結果的には品質を上げるために必要な要素であると分かります。

コミュニティの中で作り上げていくこと

OpenPNEはコミュニティで作り上げるものであると考えています。
現在のOpenPNEはさまざまな形でコミュニティと関わっています。要望などもOpenPNE公式SNSで受け入れたり、SkypeにOpenPNEのオープンチャットルームを作って公開して、常にOpenPNEのコミュニティとコミュニケーションを図りながら開発を進めています。
また、OpenPNEは開発情報としてTracを立ち上げ、ソースコード以外にもさまざまな情報を公開しています。 このように、OpenPNEはあらゆる情報を公開し、多くの方に関わって欲しいと考えています。
OpenPNEに関わる人に共通していることは、OpenPNEをより良いものにしたいという想いだと考えています。もし、この想いや価値観を共有できる人は、一緒にOpenPNEをより良いものにしていきましょう。

OpenPNEは手嶋屋だけで作られていると考えている人も多い様ですが、実際はコミュニティの中で作られていることを知って欲しいと考えています。手嶋屋はOpenPNEのコーディネータなのです。OpenPNE開発の理想はバザール方式で開発されることです。つまり、ソースコードなどの創造活動は参加者を限定せず、参加者の自主性を尊重し、個人が中心となって開発を進めます。その最終的なとりまとめをするのが手嶋屋ということです。
この様な理想の開発体制を目指して、今後もコミュニティと深く関わりOpenPNEをより良いものにしていきたいと考えています。

伽藍とバザール
http://cruel.org/freeware/cathedral.html

今後のOpenPNE

私がOpenPNEを語る時、OpenPNEは常に発展途上だという話をします。
OpenPNEにはまだまだ改善する所はたくさんあります。それは常にOpenPNEの開発者は認識していることで、これからも変わらないことだと考えています。

これまでOpenPNE開発をしてきて良かったと思う点はOpenPNEの開発者全員が常にOpenPNEをより良いものにしたいという気持ちだけで開発をしてきたことにあると思っています。
この様に常により良いものを追い求めて発展をし続けてきたことで、現在のOpenPNEがあると思っています。ただ、やはりOpenPNEがまだまだ発展途上だと考えています。それはOpenPNE開発には終わりはないということも表しています。

今回、この様にチーム開発としてOpenPNE開発のことを紹介したのはOpenPNEは多くのこと公開していますということを伝えたかったというのもあります。
OpenPNEはソースコードがオープンなだけではなく、開発体制なども公開しています。
OpenPNEっていろいろなことを公開してるんだなと思ってもらえるキッカケになればと思い、今回この本の中にOpenPNEの開発体制を紹介しました。
また、公開することによってOpenPNEの開発体制などを知ってもらい、OpenPNEをより良いものにしたいと考えている方がいれば一緒にOpenPNEを育てていけたらいいなと考えています。
実際に今後は積極的にソースコードの受け入れをしていきたいとも考えています。
OpenPNEは手嶋屋の中だけで開発しているのではなく、OpenPNEコミュニティでOpenPNEを育てていきたいと考えています。

OpenPNEをより良いものにするためには、もちろんソースコードの質も大切だと思います。しかし、ソースコードだけではなくOpenPNEの開発体制などももっと改善していきたいと考えています。現在のOpenPNEのチームもまだまだ発展途上で不完全です。
もっと多くの人と関わり合いながらコミュニティの中でOpenPNEをより良いものにしていきたいと考えています。
私たちOpenPNE開発者はOpenPNEをより良いものにしたいという思いだけでOpenPNEを開発しているので、ぜひそういう思いがあれば一緒にOpenPNEを育てていけたらいいなと考えています。