nothing but trouble RSSフィード

2005/06/30

[] 最近、Wikiの話をよく見るけど…。お前らも本気で活用してる姿を見せてくれよ!

そんなにWikiって一般的じゃなかったのか…?

あと、「企業内でBlog活用」とかいう記事とかもどっかで見たけど、それいうはWikiの方があってるんじゃないかなとか思ったりした。


俺的にはWikiはソフトウェア開発の時に利用する事が多い。多分同じような使い方してる人も多いと思うんだけど。*1

折角だから、どういう感じで使ってるか書いてみる。

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

こんな感じですかな。

これって突っ込みとかもらった方がいいから、逆にWikiで公開した方がいいと思った。でも面倒なんで、ここに書く。誰かがWiki立てれば出来る限り協力しますけど。*4


---

余談だけど、Coverageツールとか使って、Daily Buildやってる場合は、その結果をWikiから見えるようにしたほうがいいと思う。特にテスト期に入った段階では。んで、いつまで経っても引っかかるところは、BTSに放り込んでミーティングで検討。

*1:ちなみに俺がよく使ってるのは、http://fswiki.poi.jp/wiki.cgi

*2:大抵、Wiki提案した人がそのポジション担当することが多いと思うけど。

*3:毎日一回とかでOK

*4:こういうところが、俺のダメなところ。

スパム対策のためのダミーです。もし見えても何も入力しないでください
ゲスト


画像認証


(C)Kazuaki