【チーム開発】チーム開発でチームというと開発だけで考えがちだが、経営層や営業や運用も含めた全体だよって話
はじめに
対象
- チーム開発が上手くいかない原因を、経営層や営業や運用に求めてしまう人向け。
チームの境目はどこにある？
開発チームだけ？
チームという単位が曖昧で困っています。チームとはどこまでがチームなんでしょうか。
普通にチーム開発といえば、開発者だけの集団を指すことが多いように思います。それは技術書を読めば、大抵は開発者向けのことが書いてあるのもそうだし。スプリントミーティングや朝会・夕会などの打ち合わせで集まるメンバーもそうだし。
でも開発中に起きる多くの問題は、その外側とのやり取りで起きていて。
「外側？」
経営層や営業や運用は果たして外側なんでしょうか。
プロジェクトの意思決定に関わる全ての人々
よくよく考えてみると、外側だと無意識的に思っているだけなのではないでしょうか。多くの場合、プロジェクトにおけるチームとは、意思決定とその結果を共有する集団です。
つまりプロジェクトの企画やスケジュール管理を行う経営層も、お客さんとの窓口になって仕様を確認して開発にパスする営業も、製品の導入支援やログ監視を行う運用も。全員が全員、実は内側とみるべき相手なのではないでしょうか。
企業の中で利害関係が発生していて、「開発 VS 営業」バトルが日常茶飯事だとして、同じチームという意識を持つのは難しいです。経営層との距離がとても離れていて、上の意思決定＝命令だから現場が意見を挟む余地がないというような状況も。
そもそも同じチームか、あるいはその延長という意識があれば、今までの問題も少しはマシな結果になったのではないでしょうか。
失敗事例と解決への糸口
経営層編：アサインミスと手遅れリカバリー
納期前に間に合わない状態になってから、IT傭兵として参画することはよくある話ですが、コードを見たら脆弱性と不具合の嵐ということもよくある話。リリース日を遅らせることを打診しましたが、残念ながら覆ることはありませんでした。
開発として提出した優先順位は、以下です。
- 脆弱性対応・認証系の修正
- 全くない文字数バリデーションの設定
- 仕様不備
- デザイン周り
しかし実際は4.3.2.という順番で対応することになりました。最優先の1.は結局対応されませんでした。この辺りの温度感は経営層にあまり伝わってなかったようです。主にやり取りをするのは営業メンバーなのですが、開発者が伝えた話が全く伝わっていないか、3倍希釈くらいされてから伝わってる感じでした。
このケースでは経営層と開発者が間接的にやり取りするのではなく、直接説明する機会を設けるべきだったと考えています。経営戦略上、どうしてもリリース日の変更ができないなら、せめて最低限の脆弱性と認証系の修正だけ優先的に潰し、段階リリースにするという判断もできた筈です。
それをしなかった・できなかったのは、やはり営業や経営層は外側で、何なら敵ですらあるという意識が強かったのではないでしょうか。もう少しチームとしての現状共有と温度感を伝えることができれば、多少は違ったのではないかと思います。
営業編：曖昧な仕様のまま開発に丸投げ
営業なら自分が売る製品について詳細を把握しているものと思いますが、実際のところ売るための知識は持っていても、開発にバトンタッチするための知識を持っていないのが辛いところです。それでもデキる営業の方は、開発の確認したいポイントを押さえて持ってきてくれるのですが。
開発あるあるな作業として、
- 開発「A案とB案どちらか確認して欲しい。どちらかの案を実行した後で、他の案に修正するのはできないか、できても膨大なコストがかかる」
- 営業「A案で（軽率に）」
- 開発「対応終わりました」
- 客「ちょっとちょっと！ B案でないと困るんだけど」
- 営業「やっぱB案で」
ということは、よく起こります。
このケースも営業から見て開発が他人事、つまり外側の存在なのではないかと考えています。もし自分でこの作業を行うのであれば、二度手間になることを防ぐため、事前にもっときちんと確認する筈です。
この構造を変えるため、まず私がしたことは見える化でした。チケットに営業とのやり取りを全て残し、追加工数がかかった場合はその原因も記載する。それまでは一部のメンバーが他案件の工数を削ったり、スキマ時間を使って追加工数なしで対応していたのだとか。
見える化の結果、責任の所在が明確になり、どこでタスクが止まっているのかがハッキリしました。営業を外側の存在にせず内側へと引き込むことで、自分事としてタスクに向き合ってもらえるようになりました。
運用編：バグ技的な運用で仕様が変更できない
開発側の説明不足も多分にあったのだろうと思いますが、本来想定している使い方と異なる使い方をされると、仕様変更が難しくなることがあります。いわゆるバグ技的な運用をしているケースです。
Minecraftの水流エレベーターのように「バグ技を使っているのが悪い」で思い切って修正してしまえればよいのですが、toBのアプリだと最悪業務が止まるので慎重にならざるを得ません。加えて運用メンバーが公式に回答してしまっている使い方では特に。
運用メンバーを内側に巻き込むために、やはり仕様書や仕様説明は欠かせないと思います。単なる機能の説明だけでなく、その機能の目的や役割・何を想定したものかなど。そして用途外の運用をする前に相談してもらえるような関係性を構築しておくことです。
伝え聞いた話では、運用メンバーと開発メンバーの席が隣だと、距離的に近いので直ぐに聞けるという利点があるそうです。確かにその場でモニターの画面を指差して、直ぐ質問できるというのは大きいかもしれません。まだまだ工夫の余地はありそうです。
おわりに
勝手に外側・内側を決めつけて、情報や対応にフィルターをかけているのは、実は開発メンバー本人達なのかもしれません。私もそのうちの一人です。誰もが意思決定を行うチームの一員なのに、つい自分達とは別のチームだと思い込んでしまう。
経営層や営業や運用にしてみれば、開発が外側という見方もできます。こちらがあちらの内側に飛び込んでいくことも、時には必要かもしれません。この点については、また知見が溜まり次第共有していきたいと思います。
Discussion