[組織マネジメント] 優秀な開発チームに見られるある特性

毎日同じ作業を数分かけてやるのって、とてもめんどくさいと考える、ユゲタです。 インターネットのとあるサイト運営者が、毎日決まった時間に、自分の運営しているWebサイトの管理画面に入って、ボタンを1回押すという仕事をしているという話を聞いて、 もし自分がこんな仕事を依頼されたら、簡単なcronバッチを作って、バッチ実行した結果をメールやら何やらで自分の端末に通知するようにしますね。 そして、毎日その送られてくる通知を確認して終わりという、基本0秒になるようにして、確認通知がこなかった時に原因究明をするようにすることで、仕事ってどんどん楽になっていくはずです。 その人に、「何故、バッチ処理をしないのか？」と聞いたら、毎日数秒程度の作業なので、全く苦にならないのだそうです。 まあその人がそれで良いと言うのであれば、それ以上提案するのも無駄に感じて、そっとしておくことにしましたが、実はその人は、とあるWebサービスを展開するCTOの人だったので、 改めて、優秀な開発チームと、そうでないチームの特徴が現れていると感じられました。 ちなみに、今回のブログは、特定の開発チームを否定するモノではなく、ユゲタがこれまでたくさんの開発チームを見させてもらって、優秀であると感じた開発チームと、 何かしら問題を抱えて、四苦八苦している開発チームを思い出した時の特徴を書き出したモノです。

優秀なエンジニアがいても優秀な開発チームとは限らない

どの会社でも、社内開発部門がある場合、その中にひとりぐらいは「優秀な開発員」というのがいると思います。 いわゆる、その人が会社を辞めてしまうと、会社の業績にも大きく響くし経営的に困ってしまうというような人ですね。 IT会社の場合、その人がいるから成り立っていると言っても良いかもしれません。 でも、どんなに優秀な開発員がいても、その会社の開発チームが優秀であるという事はイコールではありません。 その優秀な開発員が、アグラをかいているような場合、経営者もその開発員の扱いに困って、経営的なデメリットを感じているケースもあれば、 開発マネジメントをする人が、いわゆる管理者ではない場合、「開発のことをよくわからない人」という管理者としてチーム内で不協和音が広がってしまうような、ギスギスとした開発チームになってしまうケースもあります。 ようするに、チーム活動として捉えた時に、誰か一人のエンジニアが突出したような状態よりは、チームの平均、チームの最低スキルの人、これらの目が言っている開発チームが、優秀なチームと育っていく可能性があるのと、ユゲタは考えています。

社内勉強会が行われている開発チームは優秀

残念ながら、「人員が十分に足りている」という開発チームは、日本にはほぼ無いのではないでしょうか？ どの会社も、「人手が足りていない」、「優秀なエンジニアが足りていない」という風に言っていて、毎日のようにそのセリフを聞きます。 中には、既存にいる開発チームメンバーがどんどん辞めていくという会社もあれば、人はずっと数年来変わっていないという開発チームもあります。 人は出入りして当たり前という風に考えたほうが健全なので、辞めていくからダメなチームというわけではないですが、新しい人が入ったりすることを大前提に、 優秀な開発チームには、チーム内のメンバーが、他のメンバーに何かしらを教えるという事をOJTではなく教えているスタイルが見られます。 これまで何度かブログでも書いてきましたが、いわゆる「社内勉強会」というのが開催されているのがその指標です。 OJTとして業務で仕事を覚えるというのは、単なるルールを覚えていく作業になりますが、プログラミングやIT技術のコアや基本技術について学習することは、 開発という仕事をすることにとってもメリットはあるし、なによりその人のスキルアップに繋がります。 チーム内の全体のスキルアップを目指しているチームが優秀という事になりますね。

社内ツールを自分たちで作っている開発チームは優秀

色んな会社の開発チームの話を聞いていると、実際にたくさんの便利そうなツールを使って会社サービスを運営している話もよく聞きます。 また、開発チームの人たちも、他の会社がチーム内でどんなツールを使っているかが、気になる人が多いようで、 そういう話で一喜一憂している風景もよく見ます。 そして、さらによく聞くのが、「このツールはココがイケてて、ココがイケていない」という評価をしているという事で、 例えば、会社内でドキュメント管理をしようとした時に、GoogleDriveを使って社内共有や、ドキュメント内の検索なども問題ないとしていたところ、 外部の開発会社に開発をお願いする際に、社内ドライブは、社外に共有できないということで、使えないと判断したり、 Githubのwikiに書けばいいじゃないかとしていたところ、Githubのwikiは検索機能が、ページタイトルしかヒットしないという事で断念したり、 でも、いろんな箇所にドキュメントが点在しているのが、今現在とにかくめんどくさく、管理はしたいけど、良いツールが無くて困っているという開発チームがありました。 こんな感じで、実際こうした開発チームはどうやってドキュメント管理を行えば良いんでしょうか？ ユゲタの知っている会社では、そんな時に自分たちで使うツールを自分たちで便利に作って、それを運用管理している開発チームがありましたが、 「なんて面倒くさい事をしているんだ！」とか、「車輪の再発明は無駄」という意見を言う人もいますが、そのチームではもはやそのツールをいろいろな機能バージョンアップさせて 業務ツールとして発展させて、便利に使っているということで、無駄にいろいろなツールを導入して、その機能に一喜一憂するということは無くなっています。 このツールを実際に見せてもらうと、とても優秀なツールで、このツールをWebサービスとして販売もできるレベルであるとも考えてしまいました。 そのツールを作ることでのエンジニアスキルアップや、外部サービスではないので、社内申請もなければ、何も気負うことのないシステムで、実運用ができているという気楽さがあり、 エンジニアの学びの手法としてとてもいい傾向であるとも感じました。

問題を予測する思考をしている開発チームは優秀

Webサービスを運用していると、サーバートラブルや、ネットワークトラブル、アップロードした際の不具合、などなど、何かしらのトラブルに見舞われることがあります。 webサービスを運営する側からすると、ものすごい不手際なわけで、トラブルは無いに越したことがありません。 でも、実際に問題は起きてみないとわからないため、問題発生してから対応に追われている開発チームも多いと思いますが、 優秀な開発チームは、問題が発生する恐れがあることを事前にリストアップしています。 そして、想定しているトラブルが合った時に原因究明はすぐにできるし、そもそも、想定しているので、トラブルを発生させない仕組みを十分にとっています。 さらに、想定していないトラブルが合った場合に、その原因究明ができたら、それまで自分たちの思考で何が抜けていたかを学習し、それに付随してトラブル予測の精度もどんどん上がっていきます。 誰が聞いても、こんな運用ができたら、優秀なチームだろうなと思いますが、多くの開発チームでは、こういう運用をするイメージを持てていないという事実もあります。 優秀な開発チームというのは、チーム内で、みんなが同時にスキルアップを行っていく事ができるということを改めてブログを書いて理解することができました。 このブログを読んだ開発チームの属している人、何かしら考えた事があるはずです、それをユゲタまで教えて下さい。