日々の破片

_ ソフトウェアと出版

良く建築に例えられるソフトウェア開発だけど、それは人数と作業数の規模の問題だから（例えば銀行の第3次オンライン開発についてはある程度見知っているからわかるけど、まあ、例えられるのも理解できる）、現在のソフトウェア開発のうち、相当多くはむしろ出版（Webへの掲載を含む）に近いかもなぁと思う。

出版について工程を考えてみよう。

1)企画がある（開発者ベースもあれば編集者ベースもあり、企業持ち込みのPRのようなものもある）。

2)筆者を選定する。場合によると内製もある（＝編集者が執筆する）し、グループ執筆もある（UI担当とDB担当とフレームワーク担当みたいなものだ）。

3)執筆作業（その前に企画についての打ち合わせがあって、要件確認とか、非機能要件の擦り合わせもある）。純粋な執筆というのは、プログラミングの中のコーディングに相当すると考えると正しそうだ。「ですます」調でいくか常体でいくか、会話型にするか、論文調にするか、というような文体の決定は文章の内容や筆者の得手不得手、媒体の性格などに依存するから、ちょうどプログラミング言語の選定とフレームワーク選定に相当するのだろう。

4)校正(誤字脱字＝コンパイルエラーからユニットテストくらいから、内容や参考文献のチェック＝システムテストかな、レビュー（コードレビュー相当から受け入れテストまで含む)とかまで含む、本来は執筆＝コーディングよりもむしろ時間がかかるくらい）

5)ディストリビューション（デプロイ作業だ）

出版も、大事典からWeb上の記事までバラエティーがあって、それによって開発者や編集者の人数、ディストリビューション作業に大きな幅がある。

で、編集者というのは、上の工程からわかるように、プロマネであり、アナリスト（ビジネスアナリストとシステムアナリストの兼業）であり、アーキテクトであり、プログラマーも兼ねることがあるし（プレイングマネージャだ）、しかもテスターであり、QA担当でもあり、パッケージマネージャであり（雑誌だと割り付けしたりする場合もあるので、これはライブラリアンの役割もしていることになる。メモリきつきつの専用機器へのメモリ配置とかするレベル。しかも文字通りワード単位で（さすがにバイト単位ではない））、リリースマネージャである。知っている範囲ではコールセンターサポート業務まで担当していたりもする。

つまりは、DevOpsのプロなのだった。

すげぇ。

で、そういう観点から見ると、東洋経済がリスクを恐れずに実験的なアプリケーションを外注してリリースしたら、脆弱性が見つかったので、早めに回収したという状況なのだろう。まあ、しょうがないな、と同情してしまうのだった。