ソフトウェア開発で学んだが使わなかったもの

開発手法など、一通り学んだが実際に使っていないものは多少なりあると思う。それらについて掘り起こしてみたい。

スクラム開発

認定スクラムマスター研修には研修会場ホストという立場で数回立ち会った。認定外の研修も幾つか受講した記憶がある。書籍もそれなりに読み、Scrum Gathering Tokyoなどのコミュニティにも顔を出し、まあそれなりに色々考えて捉えてきた。でも、自分のチームでは使っていない。スクラム開発というアイデアに矛盾があるからだ。

そもそもスクラム開発ではチームの自律的な行動を良しとしており、それに対する”フレームワーク”を提供しているということになっている。イテレーション、バックログ、ふりかえり、デイリーミーティング（いまだに「朝会」って言ってる人いないよね？）、そしてそれらのお作法。誰が言ったかわからないが、それぞれの作者の意図を察するためには「守」が大事らしい。守破離の「守」。ここでもう、トップダウンマネジメントが発生している。トップダウンとは上司殿の命令で起こる現象だと思ってない？違うんだよ、権威に基づいた意思決定はことごとくトップダウンなのだ。

ということで、私のチームではスクラム開発というものは実施するつもりはない。というより、目指したとしても実施できないだろう。守とのギャップを埋める作業なんてやりたくないんだよ。

そうはいっても、スクラムの思想から学んだことは多い。権限の委譲、透明性の確保、方向性の柔軟さが大事であるということ。なので、スクラム開発はおすすめしていないが、スクラム開発を学ぶことはおすすめしている。

テスト駆動開発（TDD）

これも古典であるケント・ベック「テスト駆動開発入門」や、TDDBCコミュニティからも学んだ。もちろん「テストから先に書く」っていうのは、やってない。書籍「実践テスト駆動開発」の著者氏とペアプロしたときも「なるほどー」という感覚はあったが、設計パラダイムがそもそも違ってて、自分がやるには無理だった。

TDDはTODO駆動開発という側面もある。古典本の読者なら、いちいちTODOリストを更新していった様子を思い出すといい。実業務ではそこまで詳細にはやっていない。

もちろん、アイデア自体は色々取り入れている。

• 不安であればテストを書く: 「これって心配じゃない？」みたいな会話から検証までの速度があがった
• 良いテストのパターン（早い、実行が安定している、などなど）がある: 常に良くしなければならないわけではないが、良いパターンを知れば妥協ができる
• Red-Green の変化を観察する: たとえばサーバの死活監視でも、この運用は使える

など。

TDDは応用範囲のあるプラクティスだと思う。が、そのものは使っていない。

ドメイン駆動開発（DDD）

「エリック・エヴァンスのドメイン駆動開発」はそれなりに読んだ。言っていることは簡単で、つまり「素直に実装しろ」くらいの話だと思っている。ところが、書籍には重厚なストーリーが並ぶ。非ソフトウェア開発者に対して「オブジェクトとクラスがどうの～」という説明をして議論を深めていく様子は、私には無理だと確信した。素直な実装にたどり着くにはひたすら話を聞いて議論しよう、ということが書いてある。よし、がんばります。

書籍「実践ドメイン駆動設計」は、序盤で挫折した。高コストだから簡単にはできないがとりあえず始めるといい、みたいに書いてあると解釈してしまって、そこで終わり。

開発工数見積もり手法

そういえばこれもそうか。ファンクションポイント法とかいろいろあったなあ。記憶が遠い。

見積もりポーカーはたまにやる。開発期間は3ヶ月か6ヶ月か、くらいボリュームのものの予想を立てるときに、メンバーで集まってやったりしてる。結果的にそれがあってたかとかのトラッキングはしていない。どうせ伸びる。ポイント制にしたところで不安定な材料が増すだけだ。

最近やるとしたら、松竹梅見積もりくらい。すなわち「ちょっと」「まあまあ」「たくさん」で見積もる。見積もりよりも、どう作るかのほうが大事。いい見積もり現場では、数値よりもどう作るかについて議論が深まるらしいよ。

まとめ

ということで、いくつか思い出してみた。そういえばDBマイグレーションツールとかプロビジョニングツールとかも調べたものは色々あれど、結果使わないほうが多い。

「それらは、そこから学ばなくてもわかるだろう」と言われるかもしれない。いいんだよ、人生遠回りで。