かねてから技術同人を書いてみたいと思っていたので、ついに実行することにした。
のだが、エイヤでやろうとしたら行き詰った。
しょうがないので改めてちゃんと計画を練って出直すことにしたので、その検討時のメモを残しておく。後で見直して「こんなことも考えてたな」みたいな昔を懐かしむネタになるかもしれない。
何を書く？
それなりに業界に長くいるし（といっても二十年に満たないくらいだが）、書けることくらいあるだろう、と思っていたがこれが意外に難しかった。
まずAWS Well-ArchitectedやThe Twelve-Factor AppのようなBest Practice的なものはどうかと思ったが、これは自分がそもそも書けない。言うてもエンジニアリングに関わる中で自分なりのBestは追ってきたわけだが、それは自分が置かれた環境に最適化したものなのであって、汎用のBestPracticeとしてぶちあげられるかというと、それはまた別の話だ。あと既存のBestPracticeがよくまとまってるんだからそれでいいじゃんという説もある。
ではこれまで関わってきた他社プロジェクトの内容についてはどうか。なんてことは考えるまでもなく、もちろん書けない。ビジネスマナー上NGだ。
では自分でやってみた系はどうか。これは悪くない。ただ当たり前ながら、まずやってみる必要がある。すぐ書き始めるというわけにいかない。いずれやってみたいが、今回の件に間に合わない。
というわけで折衷案に行きついた。"WEBアプリケーションをド新規で作ると仮定して、その場合どんなインフラを構築し、運用手段を用意するか"である。商業誌でもよくある形式である。だがまた変わるかもしれない。
どう書く？
構成は？
結論、構成は抽象的なSummaryから具体的なDetailに落としていく方向で行くことにした。要旨を先に述べたほうが何が言いたいのかわかりやすいので自分好みだからである。
つまり全体像はこんなイメージで
- 本の紹介
- 概要
- 個別テーマ
- 個別テーマその１
- 個別テーマその２
- ・・・
- 付録
- 参考文献
さらに個別のテーマは1)構築する順 2)重要性順で２段階に並べ替える。たとえばテーマがアプリ実行用環境ならこんな感じ。
でもって、それらの項目はやっぱり抽象的なSummaryから具体的なDetailに落としていく。
- 1.1 概要
- 1.2 実現したいこと
- 1.3 具体的な構築方法
- 1.4 備考
だいたいこれでわかりやすくなるのではなかろうか。
文章の校正は？
やさにちチェッカーや校正ツールなどを使う。あとできれば他の人にも見てもらえるといいのだけどなあと思いつつ、まずはモノを作ってから物を言おうということで、当面は自分ひとりでガンバル。
どこで発表すんの？
書いてから考える。
マーケティングガン無視だが同人なら許されるであろう。
