サービス開発でのアンチパターン
ビジネスサイド「D という機能が欲しいです」
エンジニア「じゃあ実装します」
(その後...)
通りすがり「なんで D を実装してるの？」
エンジニア「"ビジネスサイドさん" が欲しいって言ったから」
通りすがり「なんで D をいま実装してるの？」
エンジニア「すぐ欲しいって言うからすぐ実装しないと」
...
ん？これがなんでアンチパターン？と思う人もいるかもしれませんね。
"ビジネスサイドさん" の言うことを、よく聞いている真面目なエンジニアなので、良さそうにも見えるかもです。まあ確かに、できないできないしか言わない人よりは良いかも!?
解決方法を探れるのはエンジニア
こないだのブログがちょっとヒントです。
// 質問のコツその一: なんでその質問してるのか？も伝えよう
http://d.hatena.ne.jp/jflute/20170611/askingway1
Dという機能は、なんで必要なのでしょう？
C という問題があって、それは B という機能で対応できないことが原因で...でもってそもそも A という問題があって...
実は、Dという機能じゃなく、"Aを解決する機能" を実装すべきだった！
そんなことがよくあります。
...
エンジニア
「"ビジネスサイドさん" がそこを加味して要望を出さなきゃ！後からDを実装して違うよ、って言われても俺のせいじゃないよ」
もちろん "ビジネスサイドさん" も、その辺の意識が求められるでしょうが...
事業会社では、ビジネスサイドもエンジニアも、「サービスを開発する人」という意味で一心同体で、たまたま役割分担をしているだけで、受発注の関係はないですから、そこで他人の責任にしてもお金は入りません。
例えば、会員サイトであれば...
o 会員が喜んでくれる機能
o サービス運用がスムーズになる機能
を実装したら初めてお金が入るのです。
それを満たす機能はいったい何なのか？"ビジネスサイドさん" だって言い当てるのは難しいもの。なぜなら、"ビジネスサイドさん" はビジネスの専門家であって、システムの専門家ではないから。実現方法の専門家ではないから。
サービス開発の「なんの機能を実装をしよう？」というのは、みんなで知恵を出して考えないとなかなか難しいものです。
エンジニアは、実現方法も知っていて、システム全体のバランスのことも知っていて、その実現にかかるコストもわかっています。そういったところまで考慮した上で解決方法を探れるのは、(少し大げさですが)エンジニアだけとも言えます。そのエンジニアがアドバイスをしないでどうする？
サービス開発のエンジニアは、それが求められていますし、それができるエンジニアはとても価値の高いエンジニアです。
サービス開発は優先度がいのち
こんどは...
「Dという機能はやっぱり必要だ」
としましょう。
じゃあ、実装しよう...いやいやいや。
いつ実装する？
"ビジネスサイドさん" にすぐ欲しいって言われたからすぐに実装する？
開発リソースが無限にあるわけではありません。他にやることたくさんあるわけです。極端な話、10人の "ビジネスサイドさん" から、それぞれ別の "すぐ欲しい" を同時に言われたら、
どうしましょう？
その "ビジネスサイドさん" の気持ち的には、すぐに欲しいと言うのですぐに欲しいのでしょうが、でも本当にすぐに必要か？それはそれで分析が必要でしょう。
o しばらくは別の方法で回避できるかもしれない！
o "すぐ" のニュアンスが人によって違うかもしれない！
様々な "ビジネスサイドさん" の要望が、エンジニアのところに集約されているわけで、つまり、エンジニアこそが、"すぐ欲しい" の全体像を把握できるのです。そのエンジニアがアドバイスをしないでどうする？
...
さらに、
Dの機能のすべてがいま必要か？
Dの機能にも細かく内訳があるはずです。
D1: ちょーすぐ必要
D2: その二週間後でもOK
D3: 半年後くらいでOK
D4: D1の後、一週間後に必要
D5: まあ最悪なくてもOK
実は D という単位で考えるのも大きすぎる。もっと細かく優先度を付けて、Dをスリム化させて、他の優先度の高い機能にも早く着手したいのです。
もしくは、D1だけは明日にでも必要かもしれない。Dをまるごと作ってリリースが一週間後じゃ遅いかも。であればD1だけすぐ実装して使ってもらいながら、後追いでD4やD2を五月雨で出していく方がいいかも。
その細かい分析が得意なのも、実現と全体を把握しているエンジニアです。そのエンジニアがアドバイスをしないでどうする？
専門のエンジニアがいると思ってる？
エンジニア
「個々の機能実装をするディベロッパーには関係ない話で、ビジネスサイドとやり取りをする専門のエンジニアがいるでしょ？そもそもディベロッパーが直接ビジネスサイドとやり取りすること自体がおかしくない？」
おそらく事業会社のエンジニアに向いてないと言われるでしょう。
ある程度は、エンジニアの中で、そういった役割分担もするでしょうが、あまりに縦割りな感じになると、社内にエンジニアを雇っている意義が薄れてしまいます。
そもそもなぜアウトソースせずに、自社でサービスを実装するのか？"開発フットワークの軽さ" というのもありますが、"エンジニアの視点をサービス運用に反映する" のも重要な意義の一つです。
縦割り組織によるコミュニケーションコスト増幅は、スピードが求められるサービス運用の足かせになります。
また...
o 社員が設計、パートナーが実装、社員が辞めるののデフレ
o その分の人員コストとコミュニケーションコストで給料下がる
o 責任のなすりつけ合い (これほんと最悪)
という事業会社のジレンマをもろに食らう組織的な問題も発生します。
だから...
「それぞれのディベロッパーが、ビジネスサイドの人と直接やり取りをして開発していく」
ある程度の役割分担をするにしても...
「それぞれのディベロッパーが、ビジネスや運用のことを考えてアドバイスしながら開発していく」
これがほとんどの事業会社で求められる意識でしょう。完璧じゃなくてもいいから、三割でもいいから、そういった意識を持って判断と行動をしていく。
事業会社のエンジニアが社内SIer化したときから、互いにlose-loseな関係になっていくでしょう。
// 任せられるディベロッパー、七つの姿勢
http://d.hatena.ne.jp/jflute/20170405/reliableseven
の、
「その三: 三割でもビジネスに突っ込む」
「その四: 全体を把握しようとする」
が求められているのです。
SIのクセが抜けないと
SIでは、お客さんが欲しいと言ったものを実装することで、直接お金がもらえました。そこが商売の本質とも言えます。
サービス開発において、お客さんは "ビジネスサイド" ではありません。ビジネスサイドの方々は仲間であって、(会員サイトなら)会員がお客さんです。
なんだかんだ、SIerから事業会社に来る人は多いです。SIのときの感覚が抜けないと、ついつい、「言われたものを作る」という判断をしてしまいがちです。
// SIとスタートアップの違いを知ろう
http://d.hatena.ne.jp/jflute/20151007/sista
プログラムを書いたからお金がもらえるのではなく、書いたプログラムが価値を出したからお金がもらえる
アンチパターンの先には
アンチパターンを繰り返したサービスの行く末は...
行き当たりばったりの機能が積み上がったシステム
最初は良かった D の機能がいまや紛らわしい機能...なんてことも。
そして、やらなければならなくなるのが...サービス業務自体の大規模リファクタリング。仕様的負債をたんまり分析して作り直さなきゃ。
エンジニアから見れば...「また作る仕事増えていいじゃん!?」と思うでしょうか？会社からすれば損失なので、エンジニアの給料下がるかもしれませんよ。
一歩だけでも...ね
もちろん完璧は難しい。だから実際は、ある程度の役割分担はします。
でも、サービス全体での視点を持った判断を、みんなで議論しないと事業会社は成り立たないから、
みんな「一歩」だけでも踏み込む
とだいぶ違うのです。
実はオープンソースの運用でも同じ
この感覚、実はオープンソースプロダクトの運用でも全く同じです。ユーザーは確かにお客さんですが、解決したい問題を抱えているプロジェクトはその先です。
ただ "欲しい" と言われたものをそのまま作って、結果的にあまり良い結果にならなければ、責任はないにしてもlose-loseであることには変わりません。
DBFluteを使ったプロジェクトが良い結果にならなければ、jfluteにとっても良いことではありませんし、DBFluteの "かたち" が "いびつ" になったら、他のユーザー、将来のユーザーにとっても、良いことではありません。
なのでいつも...
その要望している機能で解決したい問題は？
というやり取りをさせてもらっているのです。
