March 19, 2008

…あくまで「僕の場合」という前置きをつけておきます。

普段、プロデューサーという肩書で、サービスでうまくお金をいただけるように考えて実行する仕事が僕の会社での役割ですが（多分、はてなで言うサービスディレクターかな）、その流れで、たまに新しい何かを実現するためにシステム設計をしたりします。

ずっと開発担当者と並行してソースコードはずっといじっていたのですが、開発とプロデューサーは似て非なる仕事だということに気がついたので、開発は努めて移譲するようにしました。

でも、たまにプロデューサー的思想（「おもてなし」的なのや、もっとビジネスライクなのもある。）を実装に落とすにあたって、さまざまな理由で思いついたことを伝えるのが難しいなーと思う場合は、自分で詳細仕様を書いて、プロトタイプを作ってみたりします。

こういう時につくづく思うのが、昨日まで覚えていたことをシステム設計するとすっぽり忘れてしまうことがあるんですね。

次の日の朝にヌケがあったことに気がついたりする。何故かなーって通勤しながら考えてみたんですが、

「自分が目の前に責任を持たなきゃいけないパラメータがあると、それについて漏れなく対処することを考えるだけで気持ちが一杯になってしまう」

…んだなと。

なんだろ唯心論？と唯物論？の違いみたいなイメージ。

wikipediaより引用
唯心論（ゆいしんろん）とは、人間社会において、心、もしくはその働きこそは至上の要因であるとする哲学の立場。

唯物論（ゆいぶつろん）とは、事物の本質ないし原理は物質や物理現象であるとする考え方や概念。

あくまでもイメージなので意味が伝わらないと思うけど。

プロデューサー的アプローチと、開発者的アプローチは視点の置き場所が違う。

この気持ちを切り替えて両立するのは難しいですね。そもそも作ってみないとわからないところがあるし。

また同様にチームの開発者にモノ作りを移譲しすぎると、人をまたいで同じことになるわけです。

それこそ「おもてなし」の精神を実装に変換する際に必要なのは、実現したい仕様に対する確固たる理念かもしれません。仕様書の最初に、何故それをやるのか？常に忘れてはいけない理念はなんなのか？を書いておく。

それでも具体的な実装（戦略とも言う）に落とし込む際には忘れてしまいます。

後から忘れずに精査して後戻りを許容するプロセスも必要ですね。

仕様書から目をそらして、それが実現するものをじっくり考えるプロセス。
仕様書ドリブンの開発プロセスではないですね。そこまで設計するの無理。

納期の兼ね合いがあるけど、土壇場での改善重要。

その施策を考える動機は、自分の立場、視点から来る考える時間の長さがあってこそなのかもしれないので、これを100%他人と共有するのは結構難しいのです。

そこを伝えるのがコミュニケーション力だろ！ってのは理屈上は理解してるますが、まぁ、なかなか難しい。（放棄してるわけじゃない）

さらに言えば、そこは直感の世界だったりして、必要なのか否かはやってみなきゃわからないというか、全体のバランス感の問題なので、そこだけを議論して理論的に良し悪しを解決するのは難しいのです。

なのでアジャイルが開発プロセスとしては近いけど、もっと外側の世界に動機があるような気がする。

この部分での妥協を許さない調整力は、ジョブスは天才らしいですね。

要はジョブスや子ジョブスの人たちの経験とエゴが今のアップル製品を作ってると考えれば、理論的に解決できることが全てじゃないと思うので、それが実際の開発タスクに関わるときには、それこそ「スーツとギークの調整力」というあたりが重要なのかもしれませんね。

と、何の解決法もない話で申し訳ないですが、いやーなかなか難しいですねぇという話でした。