設計についてあーだこーだ言う前に、まず「要件」をしっかり定義したほうがいいんだろうね

papapico.hatenablog.com 元のタレントの夫婦関係があーだこーだいう記事には全く興味ないんだけど、「家事はイベント実行ではなくフローでバッチ処理しろ」という主張は、その主張の仕方も含めちょっと面白かった。

ただ、その例えで言うならば、「そもそも人間ってイベント駆動で異なる物事を解決するのは得意だけど、同じ作業を繰り返し行うバッチ処理って苦手なんだから、人間をバッチ処理に組み込むその設計に問題があるんじゃないの？」ということもできるよね。なんでコンピュータのプログラム設計でバッチ処理が多用されるかといえば、それはコンピュータというものが「同じことを何回も同じようにやる」ということが得意だからなわけで。

人間を巻き込んだ作業で、もし同じことを周期的に何回もやらせる作業フローがあったとしたら、プログラマがまず考えることは「それ、自動化できない？」ということ。人間の判断がいらないものは機械に任せて、状況によって異なる、人間の判断が必要な部分だけ人間がやる、そういうシステムを構築する必要が、まずあるわけだ。

そして更に言うなら、「家事」は仕事とは異なり、効率だけを重視する必要もないわけだ。これがもし企業の生産活動なら、それによって利潤を生むという目的があり、その目的を達成するための目的合理性のみが問題となるから、当然効率が最優先となるわけだけど、家事はそうではない。

家事は、その家事を行うことそれ自体が価値となる、価値合理性も持つ行為なわけだ。例として「料理」を考えてみる。もし家事が目的合理性のみを求めるならば、毎日同じ、最もコストパフォーマンスの良い食材を、一番栄養がよく取れる形で調理すればそれでいい（実際、そういう考え方をもとにして作られた商品もある）。

だが実際は、料理そのものに、「美味しさ」「料理の楽しさ」という価値を生むものがあるために、毎日同じではなく、日によって異なる様々なやり方で料理は行われるわけだ。

となると、じゃあむしろ家事は、同じ方法で対応するバッチ処理ではなく、イベント実行の考え方で対応したほうが、それ自身価値をより生むんじゃないの？という考え方もできるわけだ。

設計についてあーだこーだ意見が出るときは、大抵その前の要件に問題がある

とまあ、「家事というプログラムをどう設計するか」ということを考えてみると、ちょっと考えただけでも色々な設計方法が思い浮かぶわけだ。イベント駆動で設計をすすめていくのも必ずしも悪いわけじゃないわけで。

しかし、こうやって設計についてあーだこーだ異論が出てくるときっていうのは、大抵の場合、実は設計の前の「要件」がうまく定義できてなかったりするんですよね。

そのことについては上記で上げた記事でも次のように触れられている。

家事最適化に向けて家庭内PDCAｻｲｸﾙを回すしかない

結局のところ「何をもって家事とするか」というゴール設定が合意できていないと、結局双方不幸になるということなので、「一緒に生活する」という原点に立ち戻って、同じチームの人間として快適に過ごせるように合意形成・ブラッシュアップしていくしかないと思います。

例えば「掃除」一つをとっても

部屋に埃が落ちていない状態を目指す（物は散らかっていてもいい）

全体的にものが仕舞われていてきれいな状態を目指す（整理整頓の優先度は低）

ではゴールが全然違います。

そして得てして人の「感覚」はだいぶ違う。

そのすれ違いを起こさないためには「自分が何を求めているのか」を明確にして相手に伝え、また「相手が何を求めているか」を把握して妥協点なりボーダーラインなりを設定するしかない。相手の「気になるポイント」が全然ないのであれば、自分の「気になるポイント」を相手に伝わるように具体化して、整理するしかないのです。

結局ここなんだろうね。このやり方は、別にウォーターフォール的に、共同生活する前に徹底的に議論して要件定義書にまとめてもいいし、あるいはアジャイル的に日々の生活の中ですり合わせをやっていくでも良いと思うのだが