LIFE STORY WEBエンジニア

開発チームビルディングでやったこと【前編】

※本サイトはPR表記を含みます。

 

こんにちは。ふわふわしょうちゃんです。

 

今回は、初めてチームビルディングで行ったこと、そして、成果について書き記しておきたいと思います。

開発チームのリーダ-になり、人をまとめる役目になった方に、職場環境が違えど、どこか参考になる所があれば幸いです。

 

 

開発チームの現状と問題点

大まかな問題点としては、以下の3つがありました。

  • 開発部での目標の実行と継続性が持てない
  • チームをけん引するリーダーが不在
  • 現状、CTOの負荷が高すぎる。役員の仕事に集中させたい

組織として、強固なものにするために、開発部のリーダーとして期待され、JOINさせていただきました。(エーようにゆーてるだけ。)

今から実行してきた項目をお話しますが、結果としては、僕自身の将来を考えた時、仕事に対しての「楽しさ・やりがい」という根幹的な部分を見出すことができませんでした。

また、育児との合間に挟まれ、プロジェクト進行の問題などにも、フルコミットしきれずに辞めることになったことは、本当に難しい判断でした。

 

期待していただいていた分、申し訳なく思う反面、自分としては、今でも後悔はしていません。

 

Backlogタスクアサイン

まず、一つ目の役割が「タスクアサイン業務」です。

 

タスク管理ツールとして、Backlogを使用していました。

ちなみに、この組織に就く前は、Backlogは使用したことがありませんでした。

 

Backlogは、たくさんの機能があって、タスク管理のほかにWiki・Gitバージョン管理・スケジュールなども管理できます。

今では、どの企業でも取り入れるべきではないかと思えるほど、タスクの明確化ができます。

そして、一番大切な、問題の共有もできます。

 

各メンバー毎に、新規開発案件をアサインするのですが、保守契約を結んでいる企業様の保守作業も単発で発生します。

僕が入る以前は、営業の方がChatwork上で、各メンバーに直接お願いしていたようですが、「誰にお願いすればよいのか、また、手が空いているのか」ということが明確でなく、困る場面が多々ありました。

 

それを、一旦、僕が窓口となり、保守作業や、見積もり、調査などのタスクを全て受け取り、各メンバーのタスクの重さを把握し、誰にお願いすれば良いかの判断を担いました。

そして、個人スケジュールに記載し、タスクが完了すれば、営業に返すという流れです。

 

時に、溢れんばかりのタスクの量になることが多く、気が遠くなることもありました。

そして、メンバーに均等に割り振れるようになれるまで、メンバーに不快な思いもさせていた時もあるだろうと思います。ゴメンネ。

ただ、営業側としては、フローがシンプルになったことで、余計な思考をせずに済むようになったことは良かったと思います。

 

保守案件の主担当・副担当の明確化

タスクアサインに関連し、保守案件の主担当と、副担当が不明確な問題を解決する必要がありました。

そもそも、タスクが流れてきても、その案件のシステム内容や、背景、開発環境がなければ、作業できるべくもなく、お願いしようがありません。

 

「誰がその案件を把握しているのか?」ということが曖昧で、属人性が強く、それを脱却するために、ほぼ、引き継ぎがない状態で(かなりキツかった)、トライする必要がありました。

ですが、決めていかなければ、何も前に進みません

 

開発MTG毎に、各メンバーに案件をどれだけ知っているのか、また、知れそうなのか。ということを事前に良く聞かせてもらいながら、徐々に主担当と、副担当を決定していきました。

ここでも、各メンバーに均等に割り振りせねばならず、中々、バランスをとるのが難しかったです。

快くかどうかはわかりませんが、メンバーが文句も言わずに協力してくれていたのは有難かったです。

 

役員が手が回らない程、のしかかっていた問題を少しずつ緩和できたことは良かったです。

 

ドキュメントの整備

属人性を排除するためにも、沢山存在するプロジェクトを、皆で共有していかなければなりません。

そのためには、最低限のドキュメントが必要になります。

 

詳細設計などの不要なドキュメントは、すぐに腐敗するので論外ですが、Backlog上のプロジェクトwikiに開発環境の構築の仕方であったり、システム構成であったり、落とし穴の共有が必要です

そして、なるべく統一されたフォーマットで記述していく必要がありました。

 

そこで、開発メンバーと共に相談し合いながら、ドキュメントフォーマットを決めました。

そして、開発案件の合間を縫って、まずは保守案件を中心に、主担当者にwikiの追加をお願いしていきました。

 

この辺りも、取り組み初めてから、半年もすれば、稼働している案件については、開発環境の明示・必要な情報の記述・フォーマットの統一もなされ、初めて保守案件のタスクに取り組む人がいたとしても、幾分入りやすくなりました。

 

1on1

僕的には、チームの結束力を強くするために、一番必要だと感じる、「1on1」です。

そして、僕は、1on1が一番得意だと勝手に思っています。もともと話が好きなんですよね。

 

あと、話題作りも得意です。なので、楽しい。楽しいから、メンバーも楽しんでくれる。

良い循環が回って、皆、信頼してくれていたように思います。

 

僕の立場は、中間ですから、役員に言いずらいことだったり、そして、メンバーのことだったり、相談しやすい存在でないといけません

対人ですから、最初から心を開いてくれるメンバーもいれば、少し時間がかかって、徐々に心を開いてくれるメンバーもいました。

 

一番大事なことは、「自分から心を開いていく」ということだと思います。それと、フラットな目を持つこと。

各個人との信頼関係が出来ていると、結果的にチームの結束力は強くなります

 

個人が集まってチームになるのですから、当然と言えば当然です。

最近、面談で良く「マネジメントで一番大切にされているものは何ですか?」と聞かれ、「信頼関係です」と答えるのですが、いつも響きませんね。

 

多分、始めてあった人に、「信頼」と言われても、そもそも信頼もなにもない人と初めて話しているのですから、違和感があるのかなと思います。

「お前に何がわかんねん」的な。

 

かといって、信条としていることですから、ウソをつくわけにはいきませんし、難しい所です。結構ガチで悩んでます。

 

信頼は、人とのコミュニケーションの土台です。質問してくる方々は、何をマネジメントに重きをおいているんですかね。

逆に聞いてみたいです。

 

開発MTGの共有事項と進行

業務中、常にアンテナを張っておくことで、開発チームとしての課題が見える時があります。

それをBacklog上に残しておき、月1の開発部ミーティング時に共有し、改善を試みます。

 

たった、一か月の間でも、結構、課題って見つかるものなんですよね。

常にベストを追い求める姿勢が、課題を見つけさせてくれるのだろうと思います。

 

最初から全て改善できるわけではありませんが、チームメンバーに常に周知しておくことで、少しずつ意識の中に埋め込んでいくことが大切です。

問題に主体性を持って、取り組むことができれば、組織としても強くなりますし、なにより、本人の努力によっての評価も上がります

リーダーは、メンバーの努力を漏らさず汲み取るべきです。

 

「主体的に問題に取り組むことによって、皆にもメリットがあるんだよ。」

ということを、MTG時に、皆に語りかけることを意識して行っていました。

 

最後に

一つの記事にしようかと考えていましたが、読むのが大変になるので、記事を分けることにしました。

振り返ると、結構な課題に取り組んできたと思います。

 

皆さんがチームビルディングを行っていく際に、参考に出来る箇所もあるはずです。

職場環境は、それぞれ違い、臨機応変に対応することが難しいですが、引き出しは一つでも多ければよいでしょう。

 

続きはコチラ。

-LIFE, STORY, WEBエンジニア
-