最近、Wikiの話をよく見るけど…。お前らも本気で活用してる姿を見せてくれよ！
そんなにWikiって一般的じゃなかったのか…？
あと、「企業内でBlog活用」とかいう記事とかもどっかで見たけど、それいうはWikiの方があってるんじゃないかなとか思ったりした。
俺的にはWikiはソフトウェア開発の時に利用する事が多い。多分同じような使い方してる人も多いと思うんだけど。*1
折角だから、どういう感じで使ってるか書いてみる。
- プロジェクトがはじまって、メンバたちにWiki使おうよと言う。
- とりあえず、Wiki立てる。
- CVS等のバージョン管理システムも同時に立てて、定期的にコミットする。
- 編集者をトレースできるように、アカウント制にしておいた方が吉。
- 率先して小人さんと化し、自分分担のところ以外に突っ込み入れたり、編集したりすると、心に誓う。
- ミーティング用の議事録ページを作る。コメントも書き込めるようにする。
- なるべくリアルタイムで書く。
- なるべく修正点は、気づいた人に直接直してもらう。
- 出来れば、ミーティング中にプロジェクタに写しながら編集。
- Wiki慣れしている人がいるなら、最初はその人たちで持ち回り。その後は全員。
- PMとかPLとかも巻き込んで書かせるべき。みんなに使ってもらわないと意味が無いから。というかむしろ偉い人にほど理解してもらうよう努力する。
- 各工程の仕様用のページを立てる。大カテゴリだけ作って、細かいページ分けだとか運用は任せる。
- 大まかな決まりだけ作ればいいと思う。ガチガチにしたらWikiのいいところが失われるし、使い手がしんどいのは本末転倒。利用してもらう事最優先で。
- Wikiの使い方のBBSを立てとく。
- 言いだしっぺの自分が率先して回答。
- 難しい問題や、みんなで決めたいことはミーティングで。
- 仕様書がPDFでいいのならば、なるべくWikiのPDF出力機能でOKしてもらう。
- それがダメでも、コピペでいいから、Wiki-仕様書間の同期を取るようにしてもらう。
- 勿論、ファイルアップロードだけでも構わない。(出来ればブラウザから即座に見れたほうがいいけど。)
- サブシステム/工程ごとに、TODOやBTSを立てる。積み残しと問題点をちゃんと把握できるように。
- 注意点
- 上に書いた事がベストと言うわけではなく一例。プロジェクト/状況に応じて最適化。
- 現時点での状態(決定事項・未決定事項・問題点)が把握できること。
- 用語集は可能な限り作るべき。出来なくとも用語は統一すべき。
- 共通認識を形成する。仕様の理解なんかで齟齬が出たら即バグだし。
- Wiki上でリンクが張られるようにするため。
- 過去の経緯などをトレースできること。
- 形骸化を恐れよう。
- 誰がボールを持っているか明らかにする。
- 誰が、いつまでに、何をやる。そして、いつ報告するか。
- BTSとTODOに入るものは出来るだけミーティングで検討するようにする。
- 言われるのが嫌だからと言って、書かなくなる人もいるかも。その対処法は、汎化出来ないと思うのでとりあえず保留。
- Wikiは忘れてはいけないことの集大成ぐらいで。
- 定例ミーティングの回数は出来るだけ増やす。*3
- Wikiを使う意味は、情報の共有化。ミーティングも同じ。
- 無駄な会議はない。無駄だと思うのは、単に自分が認識しているからだと思うべき。認識を平らにすることが大切。
- 個々人が判断して動く事が出来る。そしてその成果を自発的にレビューできる組織作りが最重要。
こんな感じですかな。
これって突っ込みとかもらった方がいいから、逆にWikiで公開した方がいいと思った。でも面倒なんで、ここに書く。誰かがWiki立てれば出来る限り協力しますけど。*4
-
- -
余談だけど、Coverageツールとか使って、Daily Buildやってる場合は、その結果をWikiから見えるようにしたほうがいいと思う。特にテスト期に入った段階では。んで、いつまで経っても引っかかるところは、BTSに放り込んでミーティングで検討。
