コミケにサークル参加するプロジェクト計画を立ててみる

人は人に自分の経験として持っている暗黙知を外に出して表現するすることで形式知に変換プロセスを経験することができます。さらに後進に伝える経験は自分に知識を再投入することと後進からの問いに応えることで知識の理解をより深くすることができます。

と書くと、「後進なんていないよ」というSEもいるかもしれません。さて、そんなときはどうしましょうか。別に仕事の後進に限定しなくてもいいですよね。プライベートな領域でもいいわけです。伝えるものは仕事で覚えた技術でも仕事の仕方でも頭の中に入っている暗黙知であって、コンプラに引っかかる内容でなければいいんです。そうでないと情報漏洩になってしまいますからね。

じゃあ、それをどこでどうやって表現すればいいのでしょうか。

「そうだ、コミケでやろう」

コミケを週末自宅のPCから実況やまとめサイトを傍観しているのでも、薄い本を走り回って買い求める側で居続けるのでもなく、コンテツを売る側にまわりましょう。

えっ「そんなの無理」でですって。いままでどれだけこのブログでプロジェクトマネジメントやシステムエンジニアの育成に関するコンテンツを読んできたのですか。今日から来年の夏コミに向けて準備をするのです。

企画を立てる
企画を作ります。さて事業目標を立てましょう。さぁ、事業目標をあげなさい、と急に言われても手が止まってしまうのも忍びないので次から選んでください。

１）コミケにサークル参加（売る側）する
２）事業費を回収する（赤字にしない）
３）コンテンツを提供する

早速、答え合わせです。

１）参加する動機ではないですよね。コミケに参加するのは手段です。
２）事業費を回収するは、目的を達成する際の目標です。数値の目標。
３）コンテンツを提供する、これが暗黙知を形式知としたいという動機を実現することができます。

というわけで３）が正解です。

制約条件を調べる
コミケにサークル参加するには、コミケのルールに従わなければなりません。それが制約条件です。さらに、印刷物であれば、印刷所のルール加わります。印刷物をコピー本で自分でコピーしたりするならそれを利用する際のルールが置き換わりますし、ダウンロード販売するなら提供する手段のインフラを提供側のルールがあるかもしれません。

マスタープランを立てる
仔細なWBSやスケジュールはまだ先でいいです。コミケに参加するなら参加方法を調べなければなりません。それは制約条件で調査済みのハスです。その制約条件に日程に関することがあるはずです。

例えば、2016年夏コミ（c90）のサークル参加の申し込み用紙の入手などです。また、例年の開催日を参考に開催時期を想定することもできます。こうした外部から情報提供を受けたり、自らが成果物を完成させたりするポイントになる日付を押さえ、マイルストーンとします。

・サークル参加申し込みの入手日
・c90の想定開催日

さらに制約条件からジャンルコードを調べて、１日目から３日目のどこに当たるかを調べておきます。

要件を定義する
事業目的は、コンテンツを提供することです。事業目標は、c90にサークル参加すること、事業費を回収することです。

ただ、コンテンツそのもは決まっていませんから、それを要件の一部として決めなければなりません。コンテンツにより、実現仕様が変わってしまいます。薄い本を提供するのか、技術の本を作るのかで、技術要件が変わるからです。また、コンテンツの提供方法により、媒体（紙、電子、光学等）が変わりますし、コスト計画も変わります。

ちょっと要件を決めないと不確定要素が大きすぎますね。要件定義の中で事業目的を達成するためのコンテンツを決め、そのあとで見積もりをすることにしないとコストを見積もりするにしても振れ幅が大きそうだということが想定できます。

こうした諸条件からも要件を決めなければなりません。目的達成のためには。ここでは、習得した技術手法について小冊子を発行することにします。薄い本を提供するには画力も液タブの投資も必要になるので。

プロジェクト計画を立てる
サークル参加に当選する前提を置き、プロジェクトとして計画を作成します。QCDを整理しましょう。

・Q　技術小冊子を完成させる・印刷所で印刷する
・C　可能な限り、低コストで作成する
・D　8月14-16日とする

このQCDから、WBSを展開します。要件は技術小冊子という漠とした要件しかありませんから、基本設計で仕様を決めなければなりません。印刷所で印刷するとありますが、可能な限り低コストでという条件もあるので要件の優先順位を決めたほうがよさそうです。

基本設計で仕様を決め、詳細設計でコンテンツを作成する章立てを決めていく必要があります。さらに、開発工程では執筆や扱う技術によっては検証とエビデンスである画面キャプチャの取得が必要となります。

開発工程で章立てのコンテンツ素材が集まったら、編集に移ります。おっと、技術小冊子なのですからデザインも必要でした。要件定義で技術小冊子としてのコンセプトを決めておいたほうが良いでしょう。それを具体的なユーザインタフェースとして仕様を決める必要があります。

これら、デザインとコンテンツを一揃い揃えて、編集が初めてできるようになります。ただ、開発工程後に初めて編集すると要件定義で想定していたイメージと違う小冊子が出来上がるかもしれません。そうならないように基本設計でプロトタイプを試験的に組み上げたほうが良いでしょう。

編集し終わった小冊子のデータはテスト工程で校正して誤字脱字やレウアウトの調整などを経て仕上げる必要があります。このときにどこまでやればいいのか品質目標を立てておかなければ、誤字脱字が混入したままで完了としたり、逆に校正が終えられないということになってしまいます。テスト工程の工期工費に影響するため要件定義の中で品質目標を決めておきます。

校正の終わったデータは最小限のコストに見合う手段の媒体に変換します。変換後は、媒体に変換された成果物を受け入れ検査します。

あとは、サークル参加の当日に必要な備品・お釣りなどの金銭の準備など当日の運営のための準備を行います。テーブルにクロスをかけたほうがいいとか、技術小冊子を展示するスタンドがあったほうがいいとか、諸々あるようなので調査の上、調達します。

ここまでやって初めてc89の当日を迎えられるのです。が、まだプロジェクト計画を作成しているだけでなんら成果物のかけらもありません。

ことの経緯は、コンテンツを提供するでしたが一大プロジェクトの様を相してきました。でも、普段周りの誰かに要求して準備してもらうことを体験できるかもしれません。とくに、要件を出すところとか、目的を設定するところとかは。今まで要求していたことが実は難しいことだったと感じられたら、技術小冊子を作成する際に経験したことを生かして上手に聞き出す方法を伝えられるようになるかもしれません。