いま実装してるの?」エンジニア「すぐ欲しいって言うからすぐ実装しないと」...ん?これがなんでアンチパターン?と思う人もいるかもしれませんね。言うことを、よく聞いている真面目なエンジニアなので、良さそうにも見えるかもです。確かに、できないできないしか言わない人よりは良いかも!?解決方法を探れるのはエンジニアこないだのブログがちょっとヒントです。実装すべきだった!そんなことがよくあります。その辺の意識が求められるでしょうが...事業会社では、ビジネスサイドもエンジニアも、「サービスを開発する人」という意味で一心同体で、たまたま役割分担をしているだけで、受発注の関係はないですから、そこで他人の責任にしてもお金は入りません。サービス運用がスムーズになる機能を実装したら初めてお金が入るのです。言い当てるのは難しいもの。ビジネスの専門家であって、システムの専門家ではないから。実現方法の専門家ではないから。サービス開発の「なんの機能を実装をしよう?」というのは、みんなで知恵を出して考えないとなかなか難しいものです。エンジニアは、実現方法も知っていて、システム全体のバランスのことも知っていて、その実現にかかるコストもわかっています。いったところまで考慮した上で解決方法を探れるのは、(少し大げさですが)エンジニアだけとも言えます。そのエンジニアがアドバイスをしないでどうする?サービス開発のエンジニアは、それが求められていますし、それができるエンジニアはとても価値の高いエンジニアです。サービス開発は優先度がいのちこんどは...「Dという機能はやっぱり必要だ」としましょう。実装しよう...いやいやいや。欲しいって言われたからすぐに実装する?開発リソースが無限にあるわけではありません。他にやることたくさんあるわけです。気持ち的には、すぐに欲しいと言うのですぐに欲しいのでしょうが、でも本当にすぐに必要か?それはそれで分析が必要でしょう。全体像を把握できるのです。そのエンジニアがアドバイスをしないでどうする?...さらに、Dの機能のすべてがいま必要か?Dの機能にも細かく内訳があるはずです。いう単位で考えるのも大きすぎる。細かく優先度を付けて、Dをスリム化させて、他の優先度の高い機能にも早く着手したいのです。D1だけは明日にでも必要かもしれない。Dをまるごと作ってリリースが一週間後じゃ遅いかも。あればD1だけすぐ実装して使ってもらいながら、後追いでD4やD2を五月雨で出していく方がいいかも。その細かい分析が得意なのも、実現と全体を把握しているエンジニアです。そのエンジニアがアドバイスをしないでどうする?専門のエンジニアがいると思ってる?エンジニア「個々の機能実装をするディベロッパーには関係ない話で、ビジネスサイドとやり取りをする専門のエンジニアがいるでしょ?そもそもディベロッパーが直接ビジネスサイドとやり取りすること自体がおかしくない?」おそらく事業会社のエンジニアに向いてないと言われるでしょう。ある程度は、エンジニアの中で、そういった役割分担もするでしょうが、あまりに縦割りな感じになると、社内にエンジニアを雇っている意義が薄れてしまいます。重要な意義の一つです。縦割り組織によるコミュニケーションコスト増幅は、スピードが求められるサービス運用の足かせになります。(これほんと最悪)という事業会社のジレンマをもろに食らう組織的な問題も発生します。...「それぞれのディベロッパーが、ビジネスサイドの人と直接やり取りをして開発していく」ある程度の役割分担をするにしても...「それぞれのディベロッパーが、ビジネスや運用のことを考えてアドバイスしながら開発していく」これがほとんどの事業会社で求められる意識でしょう。完璧じゃなくてもいいから、三割でもいいから、そういった意識を持って判断と行動をしていく。事業会社のエンジニアが社内SIer化したときから、互いにlose-loseな関係になっていくでしょう。全体を把握しようとする」が求められているのです。SIのクセが抜けないとSIでは、お客さんが欲しいと言ったものを実装することで、直接お金がもらえました。そこが商売の本質とも言えます。ビジネスサイドの方々は仲間であって、(会員サイトなら)会員がお客さんです。なんだかんだ、SIerから事業会社に来る人は多いです。SIのときの感覚が抜けないと、ついつい、「言われたものを作る」という判断をしてしまいがちです。機能がいまや紛らわしい機能...なんてことも。やらなければならなくなるのが...サービス業務自体の大規模リファクタリング。仕様的負債をたんまり分析して作り直さなきゃ。エンジニアから見れば...「また作る仕事増えていいじゃん!?」と思うでしょうか?会社からすれば損失なので、エンジニアの給料下がるかもしれませんよ。一歩だけでも...ねもちろん完璧は難しい。実際は、ある程度の役割分担はします。サービス全体での視点を持った判断を、みんなで議論しないと事業会社は成り立たないから、みんな「一歩」だけでも踏み込むとだいぶ違うのです。実はオープンソースの運用でも同じこの感覚、実はオープンソースプロダクトの運用でも全く同じです。ユーザーは確かにお客さんですが、解決したい問題を抱えているプロジェクトはその先です。言われたものをそのまま作って、結果的にあまり良い結果にならなければ、責任はないにしてもlose-loseであることには変わりません。なったら、他のユーザー、将来のユーザーにとっても、良いことではありません。いつも...その要望している機能で解決したい問題は?というやり取りをさせてもらっているのです。既存のシステムがあるとします。再開したディズニーシーにはてなブログをはじめよう!jfluteさんは、はてなブログを使っています。ブログを報告するスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。