このエントリーをはてなブックマークに追加

Book

前職の本棚にあったのでちょっと読んで購入したは良いものの、積読になっていたので読んだ。

TL;DR

  • エンジニアと働く人やサービス開発のディレクターはエンジニアの考えを知れるのでおすすめ
  • 気になるエッセイだけ読んで、自分のチームや自身の行動に導入できれば十分
  • 特に良かったのは「ジョエルテスト」「やさしい機能仕様」のパート

読む前の問い

今回は特に無し。名著?とどこかで取り上げられていたのでどんなことが書いてあるかなーくらいで読んだので、印象に残った項目と考えたことを書く。

「ジョエルテスト」で良い開発チームかをテストする

下記のYes/Noクエスチョンに答えて、11ポイント以上で合格、10ポイント以下はチームを見直そうというテスト。

1. ソース管理してる?
2. ワンステップでビルドできる?
3. デイリービルドしてる?
4. バグデータベースはある?
5. 新しいコードを書く前にバグを直している?
6. アップデートされているスケジュールがある?
7. 仕様書はある?
8. プログラマは静かな環境で作業している?
9. 手に入る最高のツールを使っている?
10. テスターはいる?
11. 採用面接のときにコードを書かせてる?
12. ユーザービリティテストはしてる?

自分が所属している開発チームは10点以下だったのはさておき、開発チームとしてうまく機能するための最低限の環境はこうであるというのが示されていて、それがチェックリストになっているというのはとても大きい。この項目について、Noの方が良いよねという人の方が少ないのではないかと思う。(ちょっと古い項目はあるけれど)とりあえず、自分の所属チームが10点以下だったのでできていない部分については上司とちょっと話そうと思う。実際は優先順位の問題もあったりするので、改善には少し時間がかかるが、それはしょうがない。

仕様書を書かないことは「最大かつ不必要なリスク」

昔の自分を棚にあげて言うが、これが分かっていないのか、仕様を書かないでなんとなくで作ってという人が多い気がする。
 
書籍内だと仕様書を書く理由として下記2つがあげられている。

  • プログラムをデザインできる
  • コミュニケーションにかかる時間を節約できる

ここは自分の過去の失敗含め、とても共感したところ。文章(仕様)よりもプログラムを直す方が圧倒的に大変だったり、仕様をしっかり書けば、「これってどうなってましたっけ?」と何度も聞かれなくて済むというのは、仕様担当者は全員知っていて欲しい。仕様は書くのはそれなりに大変なので、なんとなくで一行仕様を書きたくなる気持ちは分かるが、それこそただの丸投げでそれをリーン開発と呼ぶのは論外。仕様を書くなら、クオリティに責任を持てるぐらいのものは書いて欲しいなと思う。書籍内だと仕様が書かれない理由に「書けない(文章力がない)」というのがあり、その解決策が「書くこと」っていうのは、正直笑ってしまった。論文、小説を書くための本を買うと大体「とりあえず書け」と書いてあるのもまぁそういうことで書かないと書けないというだけの話なんだけど、それで書けたらみんな書けてるよねとも思う。それでも仕事なら書くしかないし、今はエンジニアになったので(仕様も書いているけど)、しっかり書いてもらえるように誘導している。

 
仕様書を書く上で良いヒントだなと思ったのが、読まれる仕様書を作るには下記ルールを守ろうというもの。

  • 可笑しくすること
  • 理解できるように書く
  • できる限り読みやすく書く
  • 何度も見直し、読み返す
  • テンプレートを作らない

読むのがおもしろい仕様書ってのは考えたことが無くて、そういった工夫はとても良いなと思った。本書で挙げられているのは、使っている場面を無駄に詳細なストーリーにしてジョークを入れようというものだったが、そこまでできなくてもちょっとおもしろくする工夫で読んでもらえる可能性はあがるんじゃないかと思う。2, 3個目は読む相手の視点にたって分かりやすい用語を選ぶことや文書を長くしすぎず、図解を使うなどでこれはパワーポイントを使うときも同じなので、4の見直しでしっかりチェックできれば良い。
一番気になったのは5つ目のテンプレートを作らないというやつで、私はテンプレートを作った方が良い派。もちろん、テンプレートがすべてを解決するわけではないし、本書でも指摘されているように人によっては無限に項目を増やそうとするだろうけど、毎回0から仕様書くのはつらいと思うので最低限の項目はテンプレート化して、それをベースにしっかり仕様を書くという運用にすれば良いんじゃないかなー。考えなければいけないことと考えなくても良いことを分けることが大切。

 
仕様のところが長くなってしまったが、仕様について改めて見直す良い機会になった。 
読まなくても良かった章(今は必要性が感じられなかった?)もあったけれど、上記2つについて考える機会となったので読んで良かった。 ところどころで参照されていた「ピープルウェア」も近いうちに読みたいなー。

(おまけ)目次

はじめに
1. 言語の選択
2. 基本に帰れ
3. ジョエルテスト:いいプログラムへの12ステップ
4. すべてのソフトウェア開発者が絶対確実に知っていなければならないUnicodeとキャラクタセットに関する最低限のこと(言い訳なし!)
5. やさしい機能仕様 パート1:なぜわざわざ書く必要があるのか?
6. やさしい機能仕様 パート2:仕様書とはどんなものか?
7. やさしい機能仕様 パート3:だけど……どうやって書くの?
8. やさしい機能仕様 パート4:ヒント
9. やさしいソフトウェアスケジュール
10. デイリービルドは君の友達
11. 手強いバグ修正
12. 5つの世界
13. ペーパープロトタイピング
14. アーキテクチャ宇宙飛行士たちに脅かされるな
15. 射撃しつつ前進
16. クラフトマンシップ
17. コンピュータサイエンスの3つの誤ったアイデア
18. 二文化主義
19. ユーザからクラッシュレポートを自動的に取得する方法
20. 採用面接ゲリラガイド
21. 報奨金有害論
22. テスタを雇わない(間違った)理由、ベスト5
23. 人のタスク切り替えは有害であると考えられる
24. あなたが絶対すべきでないこと PART I
25. 氷山の秘密、明らかに
26. 漏れのある抽象化の法則
27. プログラミングにおけるロード・パーマストン問題について
28. 測定
29. リック・チャップマンの愚かさの探求(あるいは「アホでマヌケな米国ハイテク企業」)
30. この国では犬はどんな仕事をしているの?
31. 下っ端でも何かを成し遂げる方法
32. 2つの話
33. ビッグマック 対 裸のシェフ
34. 何ごとも見た目ほど簡単ではない
35. 「ここで発明されたものじゃない」症候群を擁護する
36. ストラテジー・レターI:Ben & Jerry's 対 Amazon
37. ストラテジーレターII:鶏と卵の問題
38. ストラテジーレターIII: もとに戻してくれ!
39. ストラテジーレターIV:ブロートウェアと80/20の神話
40. ストラテジーレターV:オープンソースの経済学
41. マーフィーの法則が吹き荒れた一週間
42. MicrosoftはいかにしてAPI戦争に負けたか
43. Microsoft、羽目をはずす
44. 私たちの.NET戦略について
45. 申し訳ありませんが、リンカをいただけないでしょうか?
付録:「ジョエルに聞け」選集
このエントリーをはてなブックマークに追加

© 2018, Udayan28