はじめに
この記事は CrowdWorks Advent Calendar 2016 18日目の記事です。1
やすにしと申します。世間一般的に言う、ジャーマネ的なことをやらせていただいております。組織というのはナマモノでして、常に変化し、課題の種のようなものを見過ごすと、後々大変なことになることが多くあります。とはいえ、うまくいっても空気のように当たり前となりますし、うまくいかないと批判の的になるというなんとも世知辛い役割ですね。
我々も、5人ほどのエンジニアだった組織が、9ヶ月ほどで30人を超え、大きな変化を迎えました。人数が多くなるということは、課題が変容し複雑になるということ。当然ながらその複雑な課題に対して対処するわけですが、そこで多くの会社は「マネジメント」をしようとします。ただ、そのマネジメントもやり方を間違えると、活力や改善や変革をする芽を奪ってしまい、一気に硬直化し、数人だった頃の活力が失われてしまうことがあります。
そこで、一見いいやり方のように見え、かつ短期的には安定化しそうでも実はデメリットがあるよという意味で「イケイケなベンチャーの開発チームが、大企業的な開発チームになってしまう5つの兆候」と盛ったタイトルで紹介しようと思います。偉そうなことを言いつつ、我々ができているかというと難しい部分があるのですが、こういう兆しが出てきたら危ないなと考え、改善することにしています。
では早速参りましょう。
①考える人（非エンジニア）と実装する人（エンジニア）のチームを分けてしまう
起こること：どうにもこうにも埋められない距離感…
ディレクター（非エンジニア）とプロジェクトマネージャーとエンジニアのように、企画する人、プロマネする人、作る人のように別れている状態です。例えば、このような相違が起こります。
- ディレクター/PM「開発が遅すぎる、納期を守らなすぎる」
- エンジニア「これ何のために作るのかわからない」
こうなると、多くの場合は数字的成果に近いディレクターの意見が採用され、「開発効率が悪い」ということになり、とにかく「何のために」みたいなことを考える余地も無く、生産することに最適化されるようになります。そして、非エンジニアが無駄に偉そうな状態になり、エンジニアは顔をしかめることになります。
その結果、コミュニケーションコストが増え、かつエンジニアが理解しておらずに作るゆえに使われない機能が量産されていきます。もちろん、エンジニアのモチベーションは下がりますし、プロダクトや会社のために課題を解決しようという動きも出てきません。改善もトップダウンでしか行われなくなり、変化量が減ってしまいます。
無駄に偉そうな、と書きましたが、重要なのは上下関係ではなく「何が正しいか」です。本当に効率が悪ければ改善すればいいし、他に原因があればその原因を改善する。誰が言ったかを重視するのではなく、本質的な課題に向き合い、改善できる状態にすることが大切です。
対処：全員フラットで同じチームで開発する（目的別のチーム）
複数の役割の人でチームになり、同じ目的に向けて開発します。企画をする人が偉いというわけではなく、全員がフラットに目的とチームのために活動します。朝会やふりかえりなどを行うことで、全員で本質的な課題に向き合い、日々の改善をチーム自身で行うようにし、変化量を増やしていきます。計画や見積もチームで行い、報告のためではなくチームのために行います。
②生産性を数値化しろという司令ががが
起こること：意味がない数値が誕生し、独り歩きする茶番が始まる
人数が増えると、全体を把握することが難しくなります。非エンジニアのマネージャー層は疑問に思います。本当にエンジニアがちゃんと働いてくれてるんだろうか、成果に向かえてるんだろうかと。そこで考えるのが「生産性の数値化」です。全てリアルタイムに数値化すれば、状況は一目瞭然です。そうしたくなる気持ちもわかります。
ただ、開発の現場はそうカンタンではありません。なぜなら、そんなに単純なものではないからです。そもそも生産性の定義から曖昧です。エンジニアのアウトプットの定義も曖昧です。ユーザに目に触れないけども、価値があるものも多くあります。それをどう数値化するのか。基準の一つのなるはずの見積りも、仕様によって大きく変わります。リリース日を優先したいのであれば、作るものを減らし、効果を最大化するという選択肢もあります。効果を基準にすると生産性とはどう定義すればいいのでしょうか。
定義が難しい生産性をとりあえず数値化すると、社内で独り歩きが始まります。その数値を守らないと色々言われたり、叱られたりします。エンジニアは何の意味もないのに、と感じつつ、適当に数値を達成することにします。なんだこの茶番は。
数値化というのはつまり物事の単純化です。開発の現場は複雑で単純化しにくく、数値化したとしても解釈によって操作できてしまう（現実の一部しか表さない）ということです。そして数値化したところで、多くはエンジニアにとってメリットは何もありません。数値の変化での生産性マネジメントではなく、日々目の前にある数々の課題やプロダクトの価値をチームが自分で考え、臨機応変に対処していったほうが、変化量を多くし、結果的に生産性を上げることができます。
対処：チームのための見える化
数値化するとしても、会社のためではなくチームのために行うべきです。やるかどうかもやり方もチームに任せます。数値化の目的はチームやメンバーのための見える化とし、チーム外の人が管理をするためにしないことが重要です。数値に多くを求めるのではなく、改善を行うためのきっかけにするにとどめておくことが大切だと思います。
③ルールが増えまくる
起こること：ルールを守るためのルールとかもうがんじがらめ
問題が起こった場合、組織的に行う対処の一つとして「ルールを作る」という方法を取られます。ルールというのは、何かが起こったときに、もしくは起こらないように、守っておけばその目的などを深く考えなくても対処できます。うまく使えば効率的です。
ただ、ルールにばかり頼るとどうなるかというと、ルールを守ることが目的になってしまいます。ルールを守ることに集中し、目的を達成するためのはずが、作業を処理するばかりになってしまいます。組織は変化し、問題も変化します。変化するとルールも陳腐化してしまいます。陳腐化するルールを守ることほど無駄なことはありません。古い大企業（私も以前おりましたが）は、ルールにがんじがらめになり、挑戦したり発想を変えた改善をしにくい環境になってしまいます。
ルールを守るためのルールみたいな再帰的なルールが生まれ、自分が何をやってるのかよくわからない一瞬が生まれます。結果的にルールが活力や改善や変革をする芽を奪ってしまいます。
対処：ルールを捨てる勇気
ルールを捨てる勇気が重要です。意味がなくなればやめる。できるだけ必要でかつ最小限のルールにし、チームや個人の工夫が生まれる環境を維持することが必要です。でも、これって意外に難しいんですよね…。
④数値目標バンザイ！！！
起こること：数値から遠い重要なことが評価されず実行されなくなる（泣）
数値目標は重要です。目標が明確になりますし、達成したかどうかもわかります。成果の定義ともなりますし、絶対に必要です。
ただ、開発の現場は数値では表現できない複雑な課題に対峙している人もおり、大きな価値があったとしても、必ずしも数値目標に直結するわけではありません。数値のみ重視した組織の場合、数字に近い人達がインパクトを出しやすいので評価されることになります。逆に、例えばUXやインフラやアーキテクチャやリファクタリングなど、全体に影響するにもかかわらず見えにくいものの優先順位が下がります。
繰り返しですが、数値目標は重要です。ただ、直接数値に現れにくい仕事も、同じように重要です。
対処：数値以外戦略（プロダクト、UX、技術戦略など）の明確化
数値を追うことは当然として、その他の戦略を明確化し、会社として前に進めることが重要です。いかにその重要性と効果を共有し、理解できるか。続けられた場合明確に効果が出るので、その共有も含めて行っていきます。数値化できる目標と共に、数値化しにくい戦略をバランス良く全体戦略として設計し、前に進める必要があります。
⑤手段が目的化する施策がトップダウンで降ってくる
起こること：やっただけで無かったことになる
手段が目的化する極みです。トップダウンでプロセスや技術や手法を導入しようと言ったところで、その目的と実感（体験）と成長がセットでないと効果は出ません。多くのプロセスは、決められたことをやるだけでは効果が出ません。目的を理解し、自分たちの環境やスキルや考え方に合わせて変化させ適応させる必要があります。
多くの場合がやっただけで終わり、無駄な時間を過ごして終わってしまいます。
対処：目的を明確にし、小さなチームで始める
いきなり全体として導入するのではなく、小さなチームで始めます。まずその目的を明確化し、しっかり学習する時間を作り、成果が出なくても試して変えてというプロセスを経られる環境で試行錯誤します。上手くいった場合は、他のチームへ伝播させ、上手く行かなかった場合は小さな影響のうちに止めます。
まとめ
- 考える人（非エンジニア）と実装する人（エンジニア）のチームを分けてしまう
- 生産性を数値化しろという司令ががが
- ルールが増えまくる
- 数値目標バンザイ！！！
- 手段が目的化する施策がトップダウンで降ってくる
私はもともと大きな企業にいたのですが、残念なことにこれらすべての事象に遭遇していました。こんなことをやっても意味ないのになぁと思いつつ、ではどうすればいいかという話は結構難しい課題です。発想を変えて考え続けなければならず、結構大変です。ただ、これらを、プロダクト開発のように「答えが見えづらく」「複雑である」という課題に対峙する際は、常に考えながらやり方を変えていく必要があり、最近の変化が激しい世の中では必須なのかなぁと思っています。
日々答えのない問いに追われ続けて苦しい部分もありますが、それを楽しんで頑張って行きたいと思います。
明日は開発担当取締役の@shinichinomuraによる「「複雑さ」と「普遍性」とエンジニアのキャリアについて最近考えていること」です。