id:hitode909 が以下のようなエントリを書いていた．
プランナが画面一覧をもとに作ってくれた開発項目のリストと、エンジニアがボトムアップに必要そうなことを出していったリストがぜんぜん違う内容になっている、ということがあった。結果的にできるものは同じことが期待されているけど、一つの出来事に対して、言い回しが違うものが2種類ずつ用意されている。
この時点で差異があるのはいいのか、悪いのか、どちらかでいいのか、どちらも必要なのか、一つのリストにマージすべきなのかそうでないのか考えていた。
手練の実務家にコメントするのは気が引けるのだが，何かの足しにはなるだろうと思うので「俺はこう思ったっす」みたいな話を書きます． 特に「一つのリストにマージすべきなのか」について．
ソフトウェア工学の分野では「関心事の分離」とか「分割統治」とか言われるけど， 上記エントリに記載されているそれぞれのリストについては， プランナの作成した開発項目のリストは「要件定義」とか「画面設計」でカバーする領域に見えるし， エンジニアがボトムアップに必要そうなことを出していったリストは，「機能設計」とか「内部設計」とかでカバーする領域に見える． ここでは「どういう開発プロセスがいいか」みたいな話や「タスクはどういう粒度がいいか」みたいな話， はたまた「いつまで設計やってるんや」みたいな話がしたいんじゃなくて， あることを考えてるときに，別の抽象度のことを考えることがいいのか，いや良くないんじゃないの?と思ったということを伝えたい！！！ いや，考えているのは別なので，読むときに粒度がごっちゃになるのが嬉しくないのかな．
仕事で開発プロセスについてあーだこーだ言ったことはないので，もはや素人のコメントなんだけれど， 1つのプロダクト開発において，複数の開発プロセスを試しにやってみましょうみたいなトレーニング*1を受けると， どのプロセスにおいても，それぞれ工程ががわかれていて，やることが決まっており， ある工程では，別の工程の関心事には手を出さないことを強く言われる． そのトレーニングで学んだプロセスはどれも「コードよりもドキュメント」という雰囲気のものだったから， 逆の場合はもしかしたら違うのかも知れない．あるいは越境してもうまくドライビングできたりするのかも．
ドキュメントじゃなくても，あるものを「モデリング」するという行為において， いきなり別の粒度のものを混ぜるってことは不思議な気がする． 例えばGoogle Mapsでアメリカの全体の地図を見ていて，州の名前の表示が書かれている中に， 名前も聞いたことないような村の名前が表示されているとか． その村が特別有名だったり，次行くところだったら嬉しいけど，そうじゃないなら表示されないでほしいと思う．
関連して「Google社内で見ないものの一つにUMLがありますね」みたいな記述をWebで読んだことがあるけど， Googleに勤務する高出力パーソンたちは，このあたりの切り分けや抽象化がうまいのかもね，みたいな感想を持ってる．
上記はプロダクトとその機能にフォーカスがあたっているものの話だけと思うけど， 人がやるということにフォーカスを当てるというのは，ある人数までのチームにおいてはそれなりに成功しているアプローチと感じている． ソフトウェア開発のカンバンとかでは，「一つの粒度はn時間でできること(nは適当)」みたいな制限をかけることが良しとされているような気がするけど， プランナのリストは「n時間でできること」という観点で切られてなさそう．そういう意味では実際にやることに落とし込む必要があると思う． あと， リストの各項目について，関わる全員が理解し得る記述になっているのか，みたいなのは気にしたほうがいいのかな，とも思う． 抽象度の異なる2つのリストがあったとして，ある人はどちらかの記述は意味がわかるけれど，もう片方はわかんないという状況は， プロジェクトとしてうまくない気もする．意味がわかんない項目があるリストは，その人が見るべきでなかったリストなのかもしれない，とか思う．これが境界づけられたコンテキストってやつだろうか． でも，現実世界のものごとってそんなにうまく抽象化できうるんですかね．わかんないです．
