製品哲学の言語化にいどむ。「カタログ」概論

かつて筆者の所属する会社では「製品哲学」を言語化した文書のようなもの (インセプションデッキお化けのようなもの) を「カタログ」と呼んでいました。この記事はそんな文書を敢えて「カタログ」とカギカッコ付きで表現しつつ「カタログ」というものについてまとめたものです。

要点

「プリンシプル オブ プログラミング」

コードは設計書ですが、コードが唯一のドキュメントというわけではありません。ほかにも必要なドキュメントはたくさんあります。アジャイル開発手法は、ドキュメントを軽視する開発プロセスであるとよく誤解されますが、無駄なドキュメントを作らないというだけで、「ドキュメントを作らなくてよい」と主張しているわけではありません。

コードには、「How」や「What」はよく表現されていますが、「Why」、つまり設計理由がありません。この設計理由をドキュメントに記述しておくと、保守担当者の修正の判断材料として、多くの機会で役に立ちます。

一般的な「カタログ」

カタログ - Wikipedia

商品や展示物などの品目を整理して書き並べたもので、目録や説明書、案内書をいう。漢字で型録と当てる場合もある。

型録。もちろん一般的にカタログとは、目録や説明書、案内書のことです。

「製品哲学」を言語化した文書 - ここでの「カタログ」

説明としては「提案書」あるいは「プレスリリース」がよりわかりやすいと考えている。「カタログ」という呼び方が筆者個人的にしっくりこないので、いっそ「カタログ」という呼び名を捨てるべきではないか。

あるいは「カタログ」という言葉を使わずにより抽象度の高い「提案書」と言ってみたほうが良いのではないか。

はたまたすでに評価の高いAmazon社の「Internal Press Release」と言ってみたほうが良いのではないか。

その他、良いDesign Docs(Software Design Document)を書くためのリソース集
などと考えたりもするのだが、ひとまず改めて読み直して気づきを書いてみることにしたのが以下です。

「カタログ」とは

以下、各「カタログ」の過去説明から要点を再サマリしたもの。

• カタログは 将来的な理想図を意識して記述されるべき で、カタログに記述したからといって、全ての内容をその即座に実現する義務を負うものではない。
• 考え抜いた結果、時間の制約で機能を制限するものを出すと言うことはかまわない。
  • 締切という制約のために不十分なものを出しているという認識を持つことが重要である。
  • 決してその開発タームでできることに限定をして記述するものではない。その開発タームで実現する予定の事とそうでないことはわかるように明記しておく。
• 「設計」ではなく「企画」が重要。「設計手法」としては例えばデータベース設計は重要ではあるが、「企画」という観点の方が 更に重要 である。
• ユーザーの要望を、どのような目的のために、どういった機能を実装すれば良いか考える。
  • もしカタログが書き得ないということなら、その機能には意味がないということである。本当に意味がないのであれば、ユーザーをそのように説得すれば良い。
• カタログはフィードバックを受けるためのものでもある。
  • 煩雑なプログラム仕様書ではなく、解り易くメリットを記述することにより、周囲の人のフィードバックを受けることができる。
• カタログは作成日付によって履歴管理する。
• カタログに**無いものは開発してはならない。**カタログは現在の機能よりもどんどん先行しているようになっていなければならない。少なくとも次クールのカタログ設計がないなどということはありえない。
• デモ版はカタログである とも言える。明確な業務イメージが湧くように作るべきである。
• たとえば、DVDレコーダの「DVDの全てのフォーマットに対応」といったうたい文句はユーザにメリットを想起させにくい。しかし「違うチャンネルを同時に録画できます」といううたい文句はDVDレコーダについてよく知らないユーザにもメリットが分かりやすい。
• ユーザーからの要望のほとんどは、開発者の考え足らずの開発の結果、抜け落ちているものばかりである。そうならないために、仮説を立てた上で「カタログ」を書き、検証していくことでより深い開発が可能となる。
  • Good:「仮説」→「カタログ」→「案件や要望による仮説の検証」
  • Bad :「要望」や「顧客とのミーティング」→「作業」・「カタログ」
• 「その案件を挙げたユーザー、あるいは特定のユーザーへのメリットのみしか分からず、他のユーザー、既存のユーザーにはどのようなメリットがあるのか、その機能が何のためにリリースされるのかが分からない場合がある。『こういう風に工夫すれば、こちらのユーザーにも使える』ということも説明して欲しい。｣との意見がある。
  • 「こういう風に使えば、他のユーザーにとってもこの様なメリットがある。｣という使い方をいくつも想定して記述・説明して欲しい。
• カタログの説明会を、開発者の能力・成果を発表する場としてイベント的なものにもしたい。自分が作った機能の価値をできる限り多く想定・説明できることが重要である。
• 開発者一人一人がいわばプロダクトマネージャーであるために、製品の完成イメージを持ち、それに基づいて、機能を分け、優先順位を付けて、案件の調整を行うべきである。
• 動画を撮っても良い。
  • https://www.cockos.com/licecap/

つまり

変えないことが悪いのではない。変わることが悪いのでもない。大事なのは何故変えるのか、なぜ変えないのかをもう一段階引き上げて説明すること。その理由と目的、そして開発者がそれを語れること。それが愛される製品の条件なのではないでしょうか、とおもいました。

• 良い製品企画書の書き方とは？ - Qiita
• アジャイル初心者だけど、どうしてもインセプションデッキの素晴らしさを伝えたい話 - Qiita
• プロジェクトマネジメントに用いるプロジェクト憲章、Markdownテンプレート - Qiita

「生産者の声を届ける」。説明する。それがアカウンタビリティという話でした。

補足

2022 年 5 月の情報をもとに書いたものを一部 2023 年 9 月追記修正しています。
関連:

「プリンシプル オブ プログラミング」を読んだので、その要点 - Qiita
製品哲学のない製品と「緩やかに死んでいくシステム」を考える - Qiita

以上です～。