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

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構造変更の必要がないもの
  • 安定動作に支障がないと判断されたもの

メンテナンス期間

source:prj/pne-book/pne-book-9/pne-book-9-4/1.png

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

チームと開発の流れ

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

チーム

現在OpenPNE安定版の開発チームは主に小川、海老原、酒井という三名のメンバーで構成されています。役割としては、チームリーダの小川の下、海老原がコーディング、酒井がバグ収集や要望集という形でチームを組んでいます。

開発の流れ

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

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

バグ、要望収集

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

流れ

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

source:prj/pne-book/pne-book-9/pne-book-9-4/2.png

バグ収集はおよそこの様な流れで進んでいきます。
バグや要望の収集はOpenPNE品質向上のために常に行っています。

以前バグ収集はwikiを用意してこちらに書いてくださいという形で場所を用意する形をとっていましたが、実際あまり収集できていない状況でした。しかし、実際は何らかのバグがあったり、「OpenPNEにこんな機能を入れて欲しい」という要望は頂いていました。試行錯誤のうち2007年の春に実験的に公式SNS内にてバグ要望収集をはじめ、そのまま現在にいたります。実際に収集された要望から取り込まれた機能もあり、SNSからの報告を受けて修正された不具合も多いです。

収集方法

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

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

source: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を確認します。

source:prj/pne-book/pne-book-9/pne-book-9-4/4.png

毎回バグ収集・要望収集を行った後に最後に確認した日記・トピックのIDと結果をトピックに書き込んでいるので、この最終IDの次のIDの記事から確認していきます。

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

次に、Skypeのオープンチャット「OpenPNE開発談義」で収集開始を報告します。
このOpenPNE開発談義はOpenPNEの開発者や運営者など、OpenPNEに関わっている人たちがコミュニケーションを取る場所です。仕様策定などの議論もこちらで行っています。
Skypeといえば音声通話と言うイメージがありますが、ここでは音声通話機能は利用せず、テキストベースのチャットルーム機能を利用しています。誰でも参加できるので、興味があればぜひチャットに参加してみてください。

source: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の古い順から日記・トピックコメントを確認

source:prj/pne-book/pne-book-9/pne-book-9-4/6.png

要望は、タイトルにすみつきカッコ(【要望】)がついているもののみ収拾します。バグは全ての記事を一つ一つ確認していきます。何気ない日記の中の疑問・質問がバグ報告であったりするので、そのような報告も逃さず収集するためにこのようなやり方を採用しています。

バグを発見

source: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を十二分に活用し、チーム開発やプロジェクトを進めています。
 

チケット作成

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

バグ・要望収集の場合は稼働率を上げるために「報告記事のURL」「報告内容(転記)」のみを記載したチケットを作成していますが、これは例外で、通常のチケット作成には一定のフォーマットを設けてあります。

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

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

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

バグや要望を収集した場合、かならず報告者のかたにお礼のコメントを入れます。収集しっ放しで何にも連絡入れないなんて気分が悪いので。報告してくれたかたが収集後の対応も追えるように、コメントには作成したチケットのURLも記載します。

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

トピックで報告

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

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

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

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

まとめ

OpenPNEでは随時バグ収集や要望収集を行っていますが、まだまだ収集しきれていない現状もあります。また、現在は要望も随時収集するようにしてますが、チケットを作成してしまうと誰かがその機能について着手しないと仕様議論が進みずらいことがわかってきました。バグ収集・要望収集には課題が山ほどあるので、これからも試行錯誤して作業を進める必要があると思います。

バグ再現

それでは酒井がこのバグ再現も解説していきます。

流れ

source:prj/pne-book/pne-book-9/pne-book-9-4/8.png

手順としてはこのような流れでバグ再現を行います。
再現環境は、開発チーム側で用意した各バージョンのテスト環境で行います。
バグは危険と判断されるものから優先してバグ再現を行います。中には一人で再現できないこともあるので、分からない場合はSkypeでチーム内の人に呼びかけ、バグ再現を行ってもらうこともあります。

source:prj/pne-book/pne-book-9/pne-book-9-4/9.png

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

バグ再現方法

バグの再現方法はバグによってさまざまです。
実際に、動作してみてすぐにバグだと分かるものもあれば、どの様な環境が使われているか分からず、再現が困難なものも多々あります。
また、技術的に難しいものやサーバ設定が必要なものなどは開発チームにお願いします。
このように、バグの再現はチケットによってさまざまで、なかなか手順として統一することが出来ないのが現実です。

まとめ

バグ収集で効率よくバグ報告を収集出来る様になりつつあるので、このバグ再現ももっと効率よくバグを再現してなるべく早く開発しバグを無くすことが大切だと思います。 ただ、やはり原因不明や環境の依存などで、バグを再現できていないチケットもたまっています。今後の課題はこのような報告をどうやって解決していくかということだと思います。仮にOpenPNE側のバグではなかったにしても、報告してくれた方がその現象で困っていることは確かですからね。

開発

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

流れ

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

source:prj/pne-book/pne-book-9/pne-book-9-4/10.png

レポートの作成

再現されたチケットや、バグと認められたあと、チケットとして作成されます。
そのチケットはすべてView Ticketsに集められます。
収集されたバグはTypeがdefectとなっているので、Custom Queryでソートします。 source:prj/pne-book/pne-book-9/pne-book-9-4/11.png このチケットの一覧から、対応するバグのチケットを安定版の対応項目とします。MilestoneとKeywordsに修正予定のバージョンを指定します。[BR]] 対応項目がわかりやすいように、これらのチケットをまとめたレポートを作成します。レポートにはチケットの一覧が表示されるので、実際の開発・テスト時にはこのレポートを見て対応項目を確認しながら進めていきます。 source:prj/pne-book/pne-book-9/pne-book-9-4/11.png レポートがある程度完成した段階で、他のOpenPNE開発版チームに見てもらったり、OpenPNEコミュニティに見てもらいながら、レポートを完成させます。

修正チケットの消化作業

レポートが完成したら、修正チケットの消化作業に入ります。
レポートではチケットがPriotity(優先順位)の高いものから順に並んでいます。
基本的には、Priotityが高いものから修正に入ります。
始めはCriticalから修正し、次にmajorを修正していきます。
しかし、majorにすぐ修正できるバグがある場合などは、先にそのバグを修正することもあります。 対応するチケットが決まったら、そのチケットを開き、ページ下部のaccept ticketのラジオボタンを選択することで自分がバグを修正することを宣言したことになります。
source:prj/pne-book/pne-book-9/pne-book-9-4/13.png

コーディング

ここで、バグと判断されたものに対して修正を加えていきます。
source:prj/pne-book/pne-book-9/pne-book-9-4/14.png まずはじめに、開発するチケットを決めたらその現象、原因、関連情報を見ます。
このバグはOpenPNE公式SNSからのバグ報告のようです。
そして、そのバグをローカル環境で動作させてみて確かめます。
今回はcoLinuxにPuTTYというSSHクライアントを使ってSSHでアクセスして開発を行っていきます。

バグを確認したらコーディングに入ります。
実際にコードを修正したら、ローカル環境でテストします。
ローカル環境で正常に動くようになったら、修正内容をよく確認し、問題がなければテスト環境にコミットします。
その後、Tracでバグの修正が完了したことを報告します。 また、どのリビジョンで修正を加えたかを書いておきます。
このリビジョンのリンクを貼る場合に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/

(スクリーンショット)

  ツール紹介
    
  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. テスト表作成
  2. 動作テスト

テスト表作成

動作テストをする前に、テストする項目についてテスト表を作成します。
以前はエクセルでこのテスト表を作っていました。しかし、エクセルのテスト表はダウンロードするのが面倒ですし、エクセルを持っていない方もいるため、開発者以外の方にもテスト表を見てもらうには敷居の高いものでした。そこで最近はWEBブラウザで閲覧・編集が可能なGoogleSpreadsheetsを使用するように切り替えて、誰でもテスト表を閲覧できるようにしてあります。
また、このGoogleSpreadsheetsは共有することが出来るの複数人で同時に編集することも可能なので作業効率が上がるというメリットがあります。

source:prj/pne-book/pne-book-9/pne-book-9-4/15.png

テスト表は決まったフォーマットを用意し、テスト表を作成していきます。
現在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/

テスト項目を作る上で注意している点としてはテスト漏れがないかどうかという点です。
現在はマインドマップなどを使用してテストする場所の仕様を確認し、そこからテスト項目に落とし込むようにしています。テストの都度に仕様を確認して、信頼性を高めていきたいと考えています。ちなみに手嶋屋ではFreeMindというマインドマップを作成するツールを使っています。 議事録など日常の業務でもマインドマップはよく使われているんですよ。

ツール紹介

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

  (スクリーンショット)

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

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

(スクリーンショット)

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

動作テスト

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

Selenium IDEは主に繰り返し処理を行うときに使っています。例として、ページャの確認があげられます。OpenPNEはページングの処理が日記、コミュニティ、管理画面などに多く使われています。ページャがきちんと動作しているかなどは多くの記事がないと確認できないので、SeleniumIDEで記事を量産して確認しています。

source:prj/pne-book/pne-book-9/pne-book-9-4/16.png

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

source: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だけに頼ることなく、実機でのテストが必要な場合は実機でのテストもしています。

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

source: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. 開発者の主体性を尊重すること
  2. 違う視点を大切にすること
  3. コミュニティの中で作り上げていくこと

開発者の主体性を尊重すること

OpenPNEを開発していく上で、いかに開発者のモチベーションを上げるかということは大切な要素だと考えています。そのモチベーションを高めるために、各開発者の主体性を尊重するということを考えてチーム開発を行っています。

例えば、機能追加やバグ修正を行う際に開発者がどのタスクを担当するかについては基本的に自己申告によって決まります。それぞれのタスクには優先度が付けられていますが、開発者はそれを参考にした上で、自分の得意なもの、やりたいことを自ら選択することができます。

また、開発ツールについても基本的には開発者に自由に選んでもらっています。もちろん、開発者間でおすすめのツール情報の共有などはしていますが、特定のツールの使用を強要して開発者のモチベーションや開発効率を下げるよりも、各々が自分の使いやすいツールを選択して自由に使用できる方がよいと考えています。

このように、OpenPNEでは開発者の主体性を尊重して開発を進めるようにしています。チーム内での方向性が大きく違っていてチームとして機能しなくなるような事態になれば改善はしますが、基本的には開発者が主体的に開発を進めることによりモチベーションが高まり、開発効率の向上につながれば考えています。

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

OpenPNEのチーム開発をする上で、違う視点を大切にすることも重要だと考えています。

例えば、OpenPNEでバグ修正や機能追加をする際には、実際にコーディングをする人とは別の人がコードをチェックし、さらに別の人が動作テストを行う体制を取っています。違う視点を持った人がコードおよび動作をチェックすることにより、一人では気付かなかったバグや改善点が見つかりやすくなります。実際、OpenPNEのリリース後に見つかるバグの数は、このような体制を組んでいなかった時期に比べ格段に少なくなっています。

コーディングを行っている最中にも「違う視点」の効果を得るため、ペアプログラミングと呼ばれる方法も開発に取り入れています。ペアプログラミングとは2人ペアで一緒にプログラミングをする方法です。一人がプログラムを書き、もう一人はそのプログラムを見ながら指示を出します。この2人の役割を入れ替えながらプログラムを書いていきます。このペアプログラミングも違う視点を大切にしています。実際にコードを書いている人は自分がコードを書くことに集中しているので間違いに気づかないことがよくあります。そこで、もう一人の人が客観的にそのソースコードを見ることで違う視点で物事を見ることができ、早期にソースの間違いを正すことができます。

また、新機能の仕様策定やUIの検証などを行う際にも複数の開発者が集まって意見を出し合いながら進めるようにしています。

このように、一つのことに対して複数人が動くというのは一見無駄な様に見えますが、結果的には成果物の品質を高めることにつながっています。

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

OpenPNEはコミュニティの中で作り上げるものであると考えています。

現在のOpenPNEはさまざまな形でコミュニティと関わっています。バグ報告、機能要望、パッチなどをOpenPNE公式SNSで受け入れたり、メーリングリストやSkypeのオープンチャットルームを作って公開し、常にOpenPNEのコミュニティとコミュニケーションを図りながら開発を進めています。

また、OpenPNEは開発者向けの情報をまとめる場としてTracを立ち上げ、ソースコードの変更履歴をはじめさまざまな情報を公開しています。

このように、OpenPNE開発に関する多くの情報を公開し、よりたくさんの方々に開発に関わって欲しいと考えています。

今後のOpenPNE

私がOpenPNE開発について語る際には必ず「OpenPNEは常に発展途上だ」という話をします。

これまでのOpenPNE開発において最もよかったと思う点は、OpenPNEプロジェクトが止まることなく常に進化しつづけてきたという点です。それはこれからも変わらないし、変えてはならない点だと考えています。

OpenPNEは現状でもまだまだ不完全で発展途上です。ソースコードの設計や品質はもとより、ドキュメントの整備、開発体制のさらなる公開、PRの仕方など改善すべき点はたくさんあります。しかし、これらの多くの課題が残されていることは全てのOpenPNEの開発者が認識しており、常によりよいものに改善していきたいという思いを持って開発を進めています。

OpenPNEプロジェクトではこれからも「OpenPNEをよりよいものにしたい」という思いをもってくださっているすべての方々と共にOpenPNEを育てていきたいと考えているので、興味のある方は是非開発に参加していただければと思います。

Last modified 9 years ago Last modified on Mar 31, 2008, 9:10:18 PM