うちの日常

何を隠そう私は総務です。

総務は何でもしなければなりません。

具体的には

社長が出演するニコ生用TRPGのキャラクター絵を描いたり

DACに使うトロフィーのデザイン作業したり

ニコ生出演中に社長にコメント連投で業務連絡したりしてます。

　

会社では社長と対面の机に座り、いつも以下のような深刻な経営判断をしてます。

　

総務:保険ってさー、仕組みはギャンブルと同じだよねー

社長:運がいいとお金もらえるのがギャンブルで、運が悪いとお金もらえるのが保険だね

総務:じゃあ社長は１億円くらい保険かければ大金持ちじゃん

社長:がん保険入ると結核になっちゃうタイプなんだよねー

総務:あー才能ないねー

社長:それに死亡保険入ってるけど、まだ死なないんだよねー

総務:あー、才能ないねー

　

で、そんな社長がこだわるのはフォーマット。

フォーマットは色々注文つけてくるので頭いたいです。

仕様書のフォーマットに決まりを設ける

あまり難しいものではないのですが、一応弊社での仕様書についてざっくりとした決まり。

1. 更新履歴を記述する
2. 目次を作る
3. 各仕様にナンバリングする

という感じです。

他の会社様でも多分同じ事されていると思いますので、あまり面白くない話です。

ナンバリングについては社長がこだわってます。

情報の構造化をちゃんとしないと検索しづらいのと後で混乱する、というのが理由です。

構造ですが、そんなに難しい事ではありませんです。

　

例えば「モンスター」が全仕様で4番目の仕様であるとした場合

4:モンスター

となります。

この「モンスター」からぶらさがる仕様があった場合は

4-1:モンスターとは

4-2:モンスターの出現

というふうになります。

また、「モンスターの出現」にぶらさがる仕様があった場合は

4-2-1:モンスターの出現条件

というふうになります。

図にするとこう

モンスター

├モンスターとは

└モンスターの出現

　└モンスターの出現条件

階層の深さですが、3つまでというのがベストとされており、これ以上の階層が発生する場合は何某かの整理が必要であると解釈すべきと言われてます。

この階層構造を作る事によって、インデックスの作成が容易になり、ドキュメント管理に余計な仕事が増える事が減ります。

また、追加削除も的確に行え、更新履歴の参照により作業担当者の閲覧が楽になります。

この作業者担当者の可読性がすごく大切で、担当者の「勘違い」とか「未読」とか「雑多な質問」とかがプロジェクトの混乱を回避し、ゲームのクオリティを守ってプロジェクトを前に進められるポイントになります。

htmlに例えるとこう

この文章構造ですが、htmlを勉強している人だとすんなり入ると思います。

　

title

h1

├p

├h2

│└p

└h2

　└h3

　　└p

　

階層構造はhで表現されます

pはhの内容を記述する段落表記になります。

こんなかんじで構造化するとhtmlだったらwebアプリケーションで処理しやすくなりますし、excelならVBAで処理もできるようになります(かも)

プランナーさんがここいら辺を理解してくれると、データ設計含めプログラマーさんは楽なんですよね。

あまりにも当たり前な内容すぎてやばい。