あなたはまだそんな「仕様書」を書いているんですか?―ダメダメ「仕様書」の改善提案書

あなたはまだそんな「仕様書」を書いているんですか?

私の考え方とは違うみたい。

以下、違うと思った箇所

1-3 会社の都合を受け入れよう

p.34「会社の都合は悪なのか」より

　手法や技法の決定は「会社の都合」がその理由であることもあります。
組織で行動する以上、ある程度の枠組みは必要です。
経営者や組織側で何か枠組みを決めなければ、無法地帯になってしまいます。
社員として従業員には「その枠組みの中でどうするか」が当然、期待されています。
　ところでITエンジニアは、決められた枠組みの中で仕事をする際に、どれだけそれに対して
（組織の都合を踏まえながら）最適化を行っているのでしょうか？
　要件定義をし、設計をし、開発を行い、納品する。この工程を業務分析し、自社や自分の業務の役割や立場、その問題点を考えた事がありますか？
　枠組みの中で最適化を行うためには、少なくとも以下の3点を満たさなければなりません。また、これらを満たすこと自体が、枠組み無いでの最適化だとも言えるでしょう。

1.（枠組み内の)裁量権の獲得
2.枠組みの明確化
3.ノウハウの蓄積

まあ、おおむね同意出来る。

だが、これまでの現場のプログラマに裁量権はあっただろうか？
枠組みが明確化されていただろうか？

現場のプログラマに与えられている裁量の範囲はとても狭い。
最適化が行えない位、がんじがらめにされている。
たとえば、

• 進捗管理のために、ソースコードの変更差分ステップ数を毎日報告しろ
• バージョン管理システムを使っているのに、ソースコードの修正履歴をコメントアウトして残せ

なんて無駄な管理が行われていても、それを拒否するだけの裁量権は無い。

まちがった枠組みが規定されていた場合でも、会社の都合を受け入れる必要はあるんだろうか？

p.40「アジャイル開発方式の誤解」より

　残念なことに、日本で紹介されている大半の事例は、本物のアジャイル開発ではありません。お客様が納得してくれて、気持ちよく付き合ってくれて、高い顧客満足度を得るためには、かなりの実力と努力が必要です。
　お客様の要望を第一として、作っては捨て、作っては作り直しをし、満足が得られなければ捨てる、を繰り返し、以下の3つの「あえて、この方法を選ぶ証拠」をお客様に突きつけなければなりません。

1.高い実力があること(普通より早くて高品質であること)
2.努力していること（普通よりも何度もつくりなおしていること）
3.お客様がわかる証拠（そこまでしてお客様の要望に応えようとしていること）

最初の１文には同意できるが、「アジャイルは何度も作り直すのが当たり前」という著者の考え方は
アジャイル開発方式を誤解しているのではないだろうか？

アジャイルは変更を受け入れるのであって、
何度も作り直す事がアジャイルなのではない。
「無駄なものはつくらない」ようにするのがアジャイルなのではないか？
(リーン開発っぽい考え方なのかもしれないが。)

変更を受け入れた結果作り直すことになるかもしれないが、
それでも、影響範囲が小さくなるように事前に計画するはず。

何度も作り直しをやってるのは、考えもなしに客に言われたことをそのままやってるからだ。
全部作り直しをするのは、その方が無駄が少なくなる場合のみだ。
（とアジャイル開発をやったこともない人間が言っても説得力がないのだが。）

あと、著者は「楽をしよう」という考えをまるっきり悪いモノだと考えているようだが、
別に同じ品質、同じ結果が得られるならば、より楽な方が良いのではないかと思う。
品質を低下を気にせずに楽をしようとするモラルの低い輩と、そうでない人間は区別しなければいけない。

3-1 一歩手前に戻る

p.103「文書と文章と文」より

　仕様書が書けない人は、仕様書の何が書けないのでしょうか？問題を分解してみましょう。
　仕様書は「〜書」と付く以上、文章といえます。その主な構成要素は、「文と図」です。それゆえ、仕様書を書けない理由は、以下の4つのどれかに当てはまるはずです。
1.文書が作れない、文書にまとめられない
2.文章が作れない、文章にまとめられない
3.文が作れない、文にまとめなれない
4.単語が使えない、単語を使いこなせない

　もちろん、番号が若いほど難易度が上がります。そして、さらに設計図などの図とその解説といった、図解の要素まで必要とされる場合もあります。
　ただ、図解が出来なくても、文章ができれば、問題はありません。仕様書を主体として場合は、文章の方が優先されます。
　もちろん、読み手の事を考慮した場合は、その要約や概要を「見える化」した図があるに超したことはありません。しかし、図解では相手に判断を迫ることはできません。仕様書の話ですので、ここは文章や文が優先されるとしましょう。

変な日本語をなくす、わかりやすい文章を書くという点には同意するが、
文章をメインにして仕様書を書く事には同意しかねる。

なぜなら文章から「曖昧さ」を取り除くのはとても難しいから。
「3-3変な日本語をなくす」で示されているように、
よっぽど注意して記述しないとすぐに曖昧になってしまう。

図解や条件マトリクス、ロジックツリーなどを使って、
曖昧さをなくすように記述した方がよいのではないか？
仕様書を書く人には、まず、「理科系の作文技術」　木下是雄著を読んで欲しい。

理科系の作文技術 (中公新書 (624))

3-7チームワークを育てる

p.164「KJ方の欠点」より

　また、手順3のステップで、論理の一貫性がない状態のものであっても、それを視覚化した状態で見てしまった結果、「それが正しいと思い込んでしまう」現象が起きることがあります。いわゆる洗脳のような現象です。
　KJ法だけでなく、ロジカルシンキングやマインドマップといった手法も同様の欠陥をもっています。（もしかしたら、図解を使う手法すべてに言えるのかもしれません）。この現象はマルチ商法やカルト教団が用いる手法に自らはまった状態とも言えるでしょう。ある種の自己洗脳です。

著者は上記のようなこといっているが、

論理の矛盾を見つけるために視覚化するのではないか？
それで論理の矛盾が見つけられないのであれば、
視覚化の方法が間違っているだけの話。
図解が苦手だからといって、文章にだけ頼るのはどうかと思う。

そもそも、いちいち文章を読んで、理解して、論理の矛盾がないか検証して、
といった事をやらないと論理の矛盾が分からないではないか？

その方がよっぽど「それが正しいと思い込んでしまう」現象が起きることがあるのではないか？
（ソフトウェアの使用許諾書を全部読むのが好きだという人でもない限りは。）

4-6手順書を作る

手順書に一番大切な事、「手順書に従って、実際にやってみる」が抜けています。

手順書を書いた人以外が、実際に手順書に従って作業をしてみます。
これがなければ、手順書はいくらレビューや検証をやっても使いものになりません。

手順書を実用に耐えうるようにするには最低3回くらいはやってみる必要があります。

まとめ

全体的に、なんだかプログラマを敵と見ている記述が散見される。
「あなたはまだそんな「仕様書」を書いているんですか？」をそのまま返してあげたい。

仕様書の最大の敵は曖昧さである。だから、文章を曖昧にならないように記述する。
というのは間違ってないけど、
文章よりも曖昧さを少なくできる方法があったら、文章だけを使っている理由は無いはずだ。