たまにはブログ更新したいから、ついさっき流れてきたエントリに食いついちゃうよー。
ソフトウェア設計とは何か 〜 設計にはプログラミング経験が必要か否か | Social Change!
工程の分断はあり得ません
ソフトウエアの設計に実装経験が要るか要らないかというのはそもそも議論にならない。「ソフトウエアの設計＝仕様の設計+コードの設計」なんだから、例えればコインの表と裏。それらは引き離すことは出来ないのに引き離して分業しようとするからよろしくないことが起きてしまうというのが、上記記事の主題かと思います。簡単に言えば。
僕もこの点については「工程の分断」という言葉で何度も書いています。コインの表と裏であるべきものを分断してしまうと、互いのフィードバックを得る術を無くしてしまいます。そうなったら良いことは無い。ここは誰でも納得がいく所でしょう。
仕様を設計するチャンスって超少ないんじゃない？
倉貫さんの言葉を借りますと「ソフトウエアの設計＝仕様の設計+コードの設計」になりますが、現実問題としてこの２つを同時にできるSI案件って少ないのではという気がします。プライム取れないとこういうチャンスに巡り会えないから。欲しいソフトウエアの仕様を決めるオーナーさんとソフトウェアの開発を行うプログラマが直接やれば話は早いけど、それができる開発プロセスが整備された会社ってどんだけあるのか僕にはわからないけど、絶対少ないと思う。
ソフトのオーナーとプログラマが直でやるとソフトウェアの密度はめっちゃ濃くなるし仕事も面白い。これは疑いようが無い。今後は内製部隊のスピンアウトで新しいサービスを作ってそれをビジネスにするSIがメインになって社内企業でものれん分けでもなんでもいいから会社化して業界を牽引して欲しいなーってのが僕の長期的な業界展望。市場規模は小さくなるだろうけど。
あ、あと内製で大切なことは、プロダクトオーナーの言うことは正しいから彼らが納得いくまで議論を積み重ねて「やる前提」で舵を取ること。変化は受け入れるべきなんだけど、水は低きに流れちゃうのよね・・・。
仕様の決定とはどういうことかを再考する
僕はひとりで会社で内製してるけど、振り返ってみてオーナーである社長から「こーゆーのが欲しい」って言われて鵜呑みで作ったものは例外無く全部ゴミだった。あんたの言う通り作ったのにって思ったけど、言ってることと求めていることは全く違う。言われたことを鵜呑みにしても、良い仕様はまず生まれない。
補足すると、社長は誰よりも業務が見えているが故に、自分にしか分からないようなショートカット的な機能を仕様として提示してきた。「この業務の次はこうなるってことが当然わかっているだろ」という暗黙の了解が強すぎた。で、自分にしかわからないものは誰も使わなくなる。その機能を元に誰も仕事をしないので、欲した本人すら使わない。それがゴミになった原因でした。なんて日だ！！！！！
「ユーザーが言っていること」➡「なんでそんなことを言っているのか」➡「何に困っているのか」➡「それをソフトウェアで解決するためには何が必要なのか」➡「必要なものを揃えるにはどんな方法/技術/機能が必要なのか」➡「最もROIに合う解決策は何か」という所までプログラマが全部用意した上でオーナーと議論をしないと、使い手と作り手のあいだで仕様の妥当性を判断することは難しい。ソフトウェアのプロが素人のオーナーにファシリテートしないと。プロが素人の先に行かないでどーすんの？
優れた仕様が決定できないのは、業務アプリだとシステム化したい業務プロセスを誰も一気通貫で見ている人がいないから「何が業務上の問題なのかを認識していない」のが主因なことが多いと感じる。自分の仕事をIPOに整理して説明できる方って多くはいない。社長に聞いてもわからん、営業マンに聞いてもこうなったらいいなは出てくるけれど、具体的な手順までは落ちてこない。何が欲しいんですかって言っても問題意識が無いんだから、ユーザーに聞いても仕様を決めることなんか出来ない。取っ掛かりとして「こんな苦労しなくても良いんですよ」って所から僕は話をすることが多い。社内ですらこれだ。もっと優れたやり方があることを知らないのは当たり前なんだから、そこはプロが提案していかないと。
コードが書けて業務が設計できるってことは、その会社のインフラを握っているのと同じ。これってとんでもない存在感だと思うんですけど、あんま同意されない。ソフトウェアを導入して得ることが出来る効用が自社にとって何の役に立つのかを、会社の事業を運営する視点から体系立てて整理できるプログラマになれば色んな所で居場所が作れるはずなのだが・・・。
何にせよ、プログラマは優れた仕様を決める訓練を積むべきなのは間違いない。優れた仕様を決める一番手っ取り早い方法は、自分がコード書いてそれで他人の仕事を回してあげること。Excelマクロでも何でも良い。作り手は使ってる人がシステムから得られた情報を元に何を判断して次のアクションを決定しているのかを知る機会が不足しがち。それを知ることが出来ないと、そのソフトウエアが抱えている欠陥をプログラマが欠陥だと認識できない。そこで止まると優れた仕様が何だったのかを考える機会を失う。もったいないなぁ、と。
時間が無いから出来ないけど、いつか「Excelで業務を回している会社を救う、イケてるソフトウェア設計者と共通言語を持てるための本」が書けたら良いなって思う。
たぶんそこから、色んな価値が生まれてくるはずだから。
