はじめに
仕様書作成編その1では、そもそもどこに仕様書を書くかについて書いていきます。
仕様書ツールリスト
仕様書管理のジレンマ
初心者マネージャーが「プロジェクト管理ツール」「タスク管理ツール」などを見ているうちは「いいツール導入してうまくプロジェクトをまわすぞ～！」と思ってしまいがちですが、逆です。まず先に、ツールがないとプロジェクトが回しにくいだけの状況、ツールを導入する理由がある環境があって初めてツールが機能します。極論、2人で1か月で動かすプロジェクトの仕様なんて、ラインで送ればメンバー全体に確実に周知されますよね。こんな状況で複雑な変更承認プロセスなどを入れても非効率的です。
つまり、ツールを導入すればきっちりした管理が出来るが、ツール独自の管理コストが発生するというジレンマがあります。
加えて、同人プロジェクトだと、「ちゃんとツールを使わない人」が出てきます。技術的に使えない人、性格が雑で使わない人などです。さらに、そのようなメンバーには腐ったみかん理論が適用されます。つまり、ちゃんと使わない人がいると、周りがちゃんと仕様書にする意味が薄れるということです。情報がまとまっていない仕様書には意味がないですからね。したがって、ツールを厳格化すれば管理は簡単になるが、厳格なツールは怠惰な運用を生み、結果的に管理がより難しくなるというジレンマがあります。
では、以下、各仕様書管理ツールの紹介とその特徴・評価について紹介していきます。
Line
特徴
lineに仕様がある、というのは実質的に仕様書が存在していない状況です。これは止めた方がいいです。
「開発メンバーでLineグループを作って仕様を会話しながら決めて、そのTLを後から確認して実装を決める。決めたことをまとめてアナウンスする」みたいな雑な開発形態、やりがちではないでしょうか？
- 仕様を探すのに長時間上スクロール
- Lineの感覚で途中で雑談を挟んでしまい仕様会議が中断する
- 仕様のアナウンスを忘れて仕様が消滅する(というかアナウンスの個数制限がある)
- 正式に書式化されておらず認識に齟齬が発生しても気づけない
- 複数の仕様についての会話が同じTLに流れる
など、ほぼ仕様書としての体を成しません。
しかしながら、開発メンバーに仕様書を見るモチベーションがなく怠惰な仕様決定をすると、まず間違いなくここまで堕ちます。
評価：止めた方がいい
Lineのプロジェクトでの使用は止めましょう。Lineは友達とどうでもいい雑談するためのツールです。
Slack
特徴
基本的にはLineと同じです。
もちろん、Slackの方が高機能なのでマシになっている部分はあります。
- スレッド機能があるので、複数の仕様について同一のTLに流れない
- ピン止め機能がLineより強いのであとからトピックの結論にさかのぼりやすい
- 検索機能が充実しているのであとから見つけやすい
評価：2人のプロジェクトなら十分、でも出来れば止めた方がいい
ただ、Slackはチャットツールです。仕様を決める会話をSlackで行うのはいいですが、その結論は別の場所に書きましょう。
怠惰なメンバーがいると仕様書にせずにSlackの機能で済まそうとするので、心を鬼にして仕様書にまとめましょう。
Google Documents
特徴
もっとも単純なドキュメント共有方法だと思います。
仕様を別の場所に書いてまとめている、というだけで圧倒的にえらいです。
しかし、ドキュメントを作るたびに共有が必要であることや、ドキュメント間のリンクが出来ないことなどから、1ファイルが肥大化しやすく、仕様が巨大になってくると厳しいです。
評価：小さなプロジェクトなら十分
体感ですが、開発メンバーが3人程度で仕様書の骨子が10ページ以内に収まるような場合はこれで十分事足りると思います。
むしろ、下手に本格的なツールを使って開発メンバーがチャットツールに流れて仕様書が骨抜きになるより100倍マシです。
Scrapbox
特徴
ScrapBox気軽な無料wikiツールです。
- 誰でも気軽に編集ができる点
- リンクが張りやすく、ドキュメントをたどりやすい点
- ハッシュタグ機能によってドキュメントをまとめやすい点
- 全文検索も可能で記事を見つけやすい
などの特徴から、Google Documentsに比べて圧倒的に複数ページを作りやすいです。
Google Documentsならば仕様書を複雑にするゴミ扱いだった細かい仕様のメモなども、すべてScrapBox上で一元管理できるのも嬉しいポイントです。
欠点としては、ページが増えまくるので、仕様の追加に一定人数の確認が必要になってくるような大きいプロジェクトでは、非常に高確率で認識に齟齬が生まれます。
総括すると、ScrapBoxは情報をばらして情報同士のつながりで整理することに特化していて、トップダウン・一覧性といった機能に弱みを持っています。
評価：「雑に作って十分機能する」というのは同人プロジェクトにピッタリ
体感ですが、開発メンバーにある程度仕様の裁量があるようなプロジェクトであれば、大抵うまく機能します。
個人の開発メモと、全体の仕様が一元管理できると、ツールの切り替えコストも減るので良いです。
実際の運用方法としては、トップダウン型の管理が必要なものだけはハッシュタグをつけてもらい、その他は各メンバーが自分の書いた記事に関連がある記事にリンクを張っていけばよいです。
同人プロジェクトにおいて一番素晴らしい点は「雑な運用をする1メンバー」の悪影響が少ない点だと思います。
また、Google Documentsと同様の運用をしたときに比べても追加で発生する手間がありません。機能が向上して手間が増えないのであれば、積極的に使っていけばいいと思います。
Github
特徴
プロジェクトの参加人数が増えてきた場合には、Githubによる編集が有効です。
その理由は、pull requestによって、仕様書の変更を見てほしい人に通知を送り、認識を合わせることが出来ることです。
また、「エンジニア部門の仕様書変更は、メインプログラマとマネージャーを必ずレビュワーに含めなければならない」というルールを設定すれば、勝手な仕様変更が防げます。
さらに、仕様決定の会話などはissueのテキストチャットで行えるので、slackやlineよりもTLが分散しません。トピックごとの一覧性を高く維持できます。
さらにシステムがGitなので任意のフォルダ構成に任意のファイルを入れることが出来ます。
テキストや画像だけでない様々な情報を管理する仕様書の場合は便利です。
評価：本格的過ぎて同人プロジェクトには向いていないかも…
充実した機能が魅力のGithubですが、しかし欠点もあります。小さなプロジェクトではあまりissue単位の会話などは発生しないことや、1対1でラインすればいいことをわざわざpull requestを投げてごちゃごちゃする作業が面倒なことや、自由な構成が出来るがゆえにルールを決めて守らせないと秩序が崩壊して可用性が下がることなどです。
同人プロジェクトでは、厳格なルールを守らせるのが難しいです。また、ラフな使い方をするメンバーがいても無理に矯正させられません。加えて、そもそもGitが分からないメンバーがいることも多いですし、勉強させるのも難しいです。さらに、レビューする人間が明確になる状況というのは、メンバ間の上下関係がきっちり決まっていて、かつ複雑な組織図になるときです。なぜなら、マネージャーだけが仕様を確認するだけでいいというならば、別にpull requestなどせずとも、単にマネージャーが変更差分を全部読めばいいだけだからです。仕様書においてpull requestが有効になるのは「複数の上司がいて、それぞれ担当部署の変更差分を読む」場合だと思います。通常のコード管理の場合なら、コードレビューやバグ防止などの役割を持ちますが、仕様書はコードほど厳密ではないです。
TL仕様書脱却ガイド
「TL仕様書」とは、LineやSlackなど、流れていくツールに仕様を書いている状況です。
ここからの脱却方法、防止方法を解説します。
こまめな声かけ
「じゃあこれ仕様書に書いておいてくれる？」とか「ちょっと仕様書見といて」とか「仕様書のリンク送るね」とかの発言を心がけましょう。
なるべくTLで質問に答えない
マネージャーは開発メンバーに仕様を聞かれても、すぐに答えるのではなく、何らかの形で仕様書を作って「ここを見ろ！」と言いましょう。心を鬼にする必要があります。
アナウンス・ピン止め・メッセージの削除
マネージャーが定期的にTL上のスレッドやピン止めを見て、まとめが必要だと思われる部分については仕様書に書き出して、TLを消します。(Lineだとアナウンスを消せますし、Slackならメッセージごと消せます)
そして代わりに、仕様書へのリンクを張り付けておきましょう。
TLにノイズ(雑談なりなんなり…)を流す
焦土作戦です。当然悪影響はありますが、メンバーが嫌々でも「仕様書の方を見る方が楽だ」と認識してくれればこっちのものです。
TLと仕様書の連携を簡単にする
Slack Botを使って、「誰かが仕様書を編集したら通知が飛ぶ」を実装すれば、「仕様の相談をしたいから通知を飛ばすためにチャットを送信して、TLで(しかもDMで)相談して、結局TLが仕様書となる」という状況をある程度防げます。また、仕様書側に「○○どうなったか書いて！」と書き込み、その通知を送ることで強制的に仕様書に追加させる運用が出来ます。
Githubを使うなどしない限りは、「固定化された仕様書と会話して仕様を決めるチャット」の2極体制をとらざるを得ないのですが、仕様書変更で通知が飛んでくれれば多少行き来が楽になると思います。
分野ごとに運用を切り分ける
例えば、デザイン部門が小さくてプログラム部門が大きいプロジェクトだった場合、「全体的な仕様・プログラムの仕様はScrapBoxに書いて、デザインの仕様はSlackに書く」といった運用が出来ます。小さい部署に大きな管理コストを持たせるのは良くないという判断です。怠惰な運用をされる仕様書管理ツールを減らすのが最優先です。
おわりに
メンバーの実力が分からない時点でのツール選定はかなり難しいです。
実際の運用としては、まずはSlackあたりから始めて、徐々にレベルを上げていくことをおすすめします。