ODD - おもいやり駆動開発
思いやり駆動開発（ODD）
ソフトウェア開発を成功させる、もっともシンプルな「こころがけベース」のアプローチである。オブジェクト倶楽部2007夏イベントで発表された。ここでは、ついカッとなって私なりにこのコンセプトを膨らませてみたい。
ソフトウェア開発はコミュニケーションでできている。ソフトウェアの欠陥が発生しやすいのは、人と人の境界、プロジェクトとプロジェクトの境界。そしてそこにはコミュニケーションが生まれている。コミュニケーションには相手があり、その相手を「思いやる」ことが、大切だ。読み手のことを思いやるコードを書こう。システムのユーザを思いやる仕様にしよう。そんなシンプルな「こころがけ」だ。
具体的には、こういうこと。
- システムを実際に使う「ユーザー」を思いやろう。ストレスなく使え、「思った機能がそこにある」ようなシステムにしよう。そのユーザが普段使っている言葉のUIを提供しよう。製品開発では、具体的な「顧客像」を得るのが難しい。その場合でも、ペルソナ、のような「おもいやりproxy」を立てて、具体的な相手を意識し、その相手を思いやろう。
- 人が読みやすいコードを書こう。コードはコンピュータに読ませるために書くのではなく、このコードを読む相手を思いやって書く。このコードは読みやすいだろうか？と常にと自分に問いかけよう。 if (flag) と書かない。flag はコンピュータの立場の言葉。このコードを読んでいるのはペアプロの相手、将来のメンテナンス、あるいは将来の自分だ。読みやすいコードを書こう。
- コードの使い手が使いやすいインターフェイスにしよう。自分が書くコードは、その実装ではなくインターフェイスに着目し、それが使い手から見てわかりやすいか、ということを常に吟味しよう。TDD（テスト駆動開発）は、このアプローチの極端な手法。最初に使い手が「こうやったらこうなる」という想定をテストとして書いてしまい、その後で、そのテストをパスする実装を書いていく。そこまでやらなくても、実装よりも、インターフェイスを入念にデザインしよう。名前重要だ。
- 読みやすいコードが書けることを支援しよう。RubyのActiveSupportを見たときにびっくりした。コードを書く人が、20分前、という時間を 20.minutes.ago と書ける。言語やライブラリの側で工夫をして、コードを書く人が、読みやすいコードを書けることを支援しよう。ActiveSupportより前の時代でも、Ward Cuningham も、today = november(20, 1997) というコードを書いている。
- コードには、「意図」をコメントしよう。他人のコードを読んでこう思ったことはないか？「なぜ、ここでこうしているのだろう？」 人間というのはある事柄を理解をするときに、その事柄とその事柄の理由を対にすることで、納得することができる。読み手を思いやり、コードには、なぜ、をコメントしよう。7 * 24 * 3600 と書いたら、「週7日24時間無停止」というコメントを１行入れるだけでもぜんぜん違う。
- モデルにも、「意図」をコメントしよう。UMLやER、業務フローなどのモデルは、読み手が読むのは時間がかるものだ。読み手を思いやるコメントを入れよう。ここでも、「意図」が重要だ。なぜ、こう分析したのか。そもそもこのモデルを書いた理由はなんだ？
- アーキテクトも実装に参加しよう。これはJim Coplienの「Architect Also Implements」という組織プロセスパターンだ。「私は世界を作った。この世界で下々は開発すべし。」というマトリクスの「アーキテクト」は間違っている。そんな「俺俺フレームワーク」には思いやりがない。使う側に立ったフレームワークやアーキテクチャを作るには、その上で動くアプリケーションの実装に、アーキテクト自身が参加することが必要だ。
- 品質保証、テスト、は違った視点の思いやりだ。「相手の裏をかいてやろう」という考え方ではなく、「相手の気づいていないことを気づいてあげよう」と考えよう。あの人ならどう考えるかな、と想像力を使って、テストをしよう。
このように、相手への思いやりという「こころがけ」を基本に考えるだけでさまざまなソフトウェアの活動に応用がきく。さて、ではどのようにこの「相手への思いやり」をはぐくむことができるだろう。「相手」を具体化することはとても重要に思える。たとえば、顧客、ユーザー、実際の開発メンバー、自分のコードを読むであろう人、使うであろう人。。。。そしてその相手とできるだけ会話をすることで相手を理解しよう。一番いいのは、その相手と「食事をする」ことだ。これは、時代と分野を超えて使える。人間の底辺の欲求を共に満たし、おいしい、という感情をともにすることだ。
思いやり駆動開発では、ソフトウェア開発を「ロジック中心」の思考から「感情重視」の思考へと変革する。仕様書には書かれていない、「行間感情」を伝えるために、共感力と想像力を使って、相手を思いやろう。相手に興味を持とう、相手を理解しようと努力しよう、相手に感謝しよう。ソフトウェア開発に、3K(興味、共感、感謝)を導入したいのだ。
ソフトウェアは人が人のために作っている。この仕様書は誰に読んでもらう？そのプログラムは誰を幸せにする？そこを忘れてしまった成果物は、悲しい。
詳しくは、igaiga さんのページを参照のこと！
http://igarashikuniaki.net/tdiary/20070620.html#p01
※余談だが、仕事を終えて帰ってきて、妻と遅い夕食を摂っているときの話。疲れている私に、妻が長い話を始める。「今日、PTAでね、こんなことがあってね。。。」、「それでね、○○さんがこういうのよ。。。」、「そしたら会長さんがね。。。。」、「それで私も困ってね。。。」という話が延々続く。仕事脳のままの私は、「ご、ごめん、結論から言って。」とつい言ってしまう。そして、「そういう場合は、誰々と話をまずして、ああして、こうしたらどう？」と解決策を提示してしまう。そして、結局妻の顔を逆に曇らせてしまうのだ。そして、後で気づく。彼女が欲しかったのは解決ではなくて共感。「あぁ、そんなことがあったのか。本当に大変だったねぇ。」という共感の一言だったのだ、とわかる。相手を思いやることは、ロジックよりも感情を大切にし、相手の気持ちを分かろうと努力する「態度」なんだ。いい加減な態度で、ロジックで解決しても、相手をしあわせにはしない。まず共感すること、おもいやること。そこからはじめ、次にロジックを使おう。