こんにちは。ふわふわしょうちゃんです。
今回は、初めてチームビルディングで行ったこと、そして、成果について書き記しておきたいと思います。
開発チームのリーダ－になり、人をまとめる役目になった方に、職場環境が違えど、どこか参考になる所があれば幸いです。
開発チームの現状と問題点
大まかな問題点としては、以下の3つがありました。
- 開発部での目標の実行と継続性が持てない
- チームをけん引するリーダーが不在
- 現状、CTOの負荷が高すぎる。役員の仕事に集中させたい
組織として、強固なものにするために、開発部のリーダーとして期待され、JOINさせていただきました。（エーようにゆーてるだけ。）
今から実行してきた項目をお話しますが、結果としては、僕自身の将来を考えた時、仕事に対しての「楽しさ・やりがい」という根幹的な部分を見出すことができませんでした。
また、育児との合間に挟まれ、プロジェクト進行の問題などにも、フルコミットしきれずに辞めることになったことは、本当に難しい判断でした。
期待していただいていた分、申し訳なく思う反面、自分としては、今でも後悔はしていません。
Backlogタスクアサイン
まず、一つ目の役割が「タスクアサイン業務」です。
タスク管理ツールとして、Backlogを使用していました。
ちなみに、この組織に就く前は、Backlogは使用したことがありませんでした。
Backlogは、たくさんの機能があって、タスク管理のほかにWiki・Gitバージョン管理・スケジュールなども管理できます。
今では、どの企業でも取り入れるべきではないかと思えるほど、タスクの明確化ができます。
そして、一番大切な、問題の共有もできます。
各メンバー毎に、新規開発案件をアサインするのですが、保守契約を結んでいる企業様の保守作業も単発で発生します。
僕が入る以前は、営業の方がChatwork上で、各メンバーに直接お願いしていたようですが、「誰にお願いすればよいのか、また、手が空いているのか」ということが明確でなく、困る場面が多々ありました。
それを、一旦、僕が窓口となり、保守作業や、見積もり、調査などのタスクを全て受け取り、各メンバーのタスクの重さを把握し、誰にお願いすれば良いかの判断を担いました。
そして、個人スケジュールに記載し、タスクが完了すれば、営業に返すという流れです。
時に、溢れんばかりのタスクの量になることが多く、気が遠くなることもありました。
そして、メンバーに均等に割り振れるようになれるまで、メンバーに不快な思いもさせていた時もあるだろうと思います。ゴメンネ。
ただ、営業側としては、フローがシンプルになったことで、余計な思考をせずに済むようになったことは良かったと思います。
保守案件の主担当・副担当の明確化
タスクアサインに関連し、保守案件の主担当と、副担当が不明確な問題を解決する必要がありました。
そもそも、タスクが流れてきても、その案件のシステム内容や、背景、開発環境がなければ、作業できるべくもなく、お願いしようがありません。
「誰がその案件を把握しているのか？」ということが曖昧で、属人性が強く、それを脱却するために、ほぼ、引き継ぎがない状態で（かなりキツかった）、トライする必要がありました。
ですが、決めていかなければ、何も前に進みません。
開発MTG毎に、各メンバーに案件をどれだけ知っているのか、また、知れそうなのか。ということを事前に良く聞かせてもらいながら、徐々に主担当と、副担当を決定していきました。
ここでも、各メンバーに均等に割り振りせねばならず、中々、バランスをとるのが難しかったです。
快くかどうかはわかりませんが、メンバーが文句も言わずに協力してくれていたのは有難かったです。
役員が手が回らない程、のしかかっていた問題を少しずつ緩和できたことは良かったです。
ドキュメントの整備
属人性を排除するためにも、沢山存在するプロジェクトを、皆で共有していかなければなりません。
そのためには、最低限のドキュメントが必要になります。
詳細設計などの不要なドキュメントは、すぐに腐敗するので論外ですが、Backlog上のプロジェクトwikiに開発環境の構築の仕方であったり、システム構成であったり、落とし穴の共有が必要です。
そして、なるべく統一されたフォーマットで記述していく必要がありました。
そこで、開発メンバーと共に相談し合いながら、ドキュメントフォーマットを決めました。
そして、開発案件の合間を縫って、まずは保守案件を中心に、主担当者にwikiの追加をお願いしていきました。
この辺りも、取り組み初めてから、半年もすれば、稼働している案件については、開発環境の明示・必要な情報の記述・フォーマットの統一もなされ、初めて保守案件のタスクに取り組む人がいたとしても、幾分入りやすくなりました。
1on1
僕的には、チームの結束力を強くするために、一番必要だと感じる、「1on1」です。
そして、僕は、1on1が一番得意だと勝手に思っています。もともと話が好きなんですよね。
あと、話題作りも得意です。なので、楽しい。楽しいから、メンバーも楽しんでくれる。
良い循環が回って、皆、信頼してくれていたように思います。
僕の立場は、中間ですから、役員に言いずらいことだったり、そして、メンバーのことだったり、相談しやすい存在でないといけません。
対人ですから、最初から心を開いてくれるメンバーもいれば、少し時間がかかって、徐々に心を開いてくれるメンバーもいました。
一番大事なことは、「自分から心を開いていく」ということだと思います。それと、フラットな目を持つこと。
各個人との信頼関係が出来ていると、結果的にチームの結束力は強くなります。
個人が集まってチームになるのですから、当然と言えば当然です。
最近、面談で良く「マネジメントで一番大切にされているものは何ですか？」と聞かれ、「信頼関係です」と答えるのですが、いつも響きませんね。
多分、始めてあった人に、「信頼」と言われても、そもそも信頼もなにもない人と初めて話しているのですから、違和感があるのかなと思います。
「お前に何がわかんねん」的な。
かといって、信条としていることですから、ウソをつくわけにはいきませんし、難しい所です。※結構ガチで悩んでます。
信頼は、人とのコミュニケーションの土台です。質問してくる方々は、何をマネジメントに重きをおいているんですかね。
逆に聞いてみたいです。
開発MTGの共有事項と進行
業務中、常にアンテナを張っておくことで、開発チームとしての課題が見える時があります。
それをBacklog上に残しておき、月1の開発部ミーティング時に共有し、改善を試みます。
たった、一か月の間でも、結構、課題って見つかるものなんですよね。
常にベストを追い求める姿勢が、課題を見つけさせてくれるのだろうと思います。
最初から全て改善できるわけではありませんが、チームメンバーに常に周知しておくことで、少しずつ意識の中に埋め込んでいくことが大切です。
問題に主体性を持って、取り組むことができれば、組織としても強くなりますし、なにより、本人の努力によっての評価も上がります。
リーダーは、メンバーの努力を漏らさず汲み取るべきです。
「主体的に問題に取り組むことによって、皆にもメリットがあるんだよ。」
ということを、MTG時に、皆に語りかけることを意識して行っていました。
最後に
一つの記事にしようかと考えていましたが、読むのが大変になるので、記事を分けることにしました。
振り返ると、結構な課題に取り組んできたと思います。
皆さんがチームビルディングを行っていく際に、参考に出来る箇所もあるはずです。
職場環境は、それぞれ違い、臨機応変に対応することが難しいですが、引き出しは一つでも多ければよいでしょう。
続きはコチラ。
