こんにちは。ふわふわしょうちゃんです。
前回に引き続き、僕が開発チームビルディングで行ってきたことを書いていきます。
前回の記事が気になる方は、コチラを参考にしてください。
メンバーのスケジュールと工数管理
会社組織として、一番の問題といっても過言でなかったのが、「工数管理」です。
最終的には、工数可視化ツールを導入し、プロジェクト管理をする流れになりました。
開発部で、工数を意識しながら、開発を行っているメンバーが少なく、最終的な消化率が100%を越え、すなわち、赤字状態が続いていました。
ですが、元々、見積もり精度が甘く、無茶なスケジュールの案件もありました。個人的には、一番解決するのが難しかった課題です。
結果的に、完全な解決には至りませんでした。
各メンバーに責任感を持ってもらうために、見積もりについての対策案などを促しました。
そして、全体で対策案を共有しながら、評価制度のランクによって「どれぐらいの工数消化率であればよいか」を具体的な数値目標として表すことで、明確なゴールが見えるように対策していきました。
「見積り自体は、実作業する人が見積もりも行う。」という方法が、自身で考えた見積もり案なので、責任感も生まれやすい。
結果、上手くいかない場合でも、納得しやすいでしょう。
※会社としては、プロジェクトが赤字になるのは困るんですが。
ですが、開発業務を行いながら、並行して、見積もりを行っていくというのも、時に難しいのが現実です。
精度を上げるために、見積りレビューをしても、人的リソースが掛かってしまいます。
非常に悩ましい問題でした。
成果としては、各メンバーに問題定義を促すことで、以前よりも、工数に対する意識は確実に上がりました。
システム開発は複雑であるがゆえ、見積りを見落とす問題もあり、ウォーターフォール工程の限界を感じる結果になりました。
部署間の相談役
会社組織には以下、3つの部隊がありました。
- 営業チーム
- 開発チーム
- テストチーム
組織は人の集まりである以上、やはり、人間関係を避けることはできません。
プロジェクトを進行していく過程で、必ず「伝えたことが違う」という問題が発生します。
相手が求めていることと、自分が理解していることの差異は、どの業務でも起こり得る問題ですが、システム開発の場合、手戻りが激しくなる場合があり、結果として工数超過に陥り、プロジェクト失敗になり得ます。なので、早い段階での、軌道修正が必要です。
基本的なコミュニケーションツールは、ChatWorkを使用していました。
プロジェクトの案件毎にやり取りを確認し、少しでも「やりとりが上手くいってなさそうだな」と感じた場合、間に入るようにしていました。※特に別途、個人に向けて声をかける。
僕が、大切にしていたのは、ChatWork上でのやりとりよりも、別途、MTGで個室の時間をとり、「関係者同士 + 僕」という形で、コミュニケーションをとるようにしていました。
なぜなら、チャット上だけでは、感情などの表現が伝わりにくく、曖昧さを汲み取ることも難しいと考えています。
なので、そこは第三者も交えて、伝わりにくいことを理解しにいく。という形でアクションを起こしていました。
そのようにしていると、自然と、こちらがアクションを起こす前に、他のチームからも相談してもらえるようになりました。
人から頼られるのは、嬉しいもの。
そして、「寄り添ってくれる」と、メンバーから評価をいただいたことは、とても嬉しかったです。
全体MTGの進行とまとめ
月1で全体ミーティングがありました。そこで、基本的に以下の報告をします。
- プロジェクト毎の開発状況と工数消化率
- 障害共有と改善策
- 開発チームの目標の進行度
- 全体に周知すべきお知らせ
全体ミーティングの2週間程前から、工数消化率をはじき出し、プロジェクト毎の開発状況と、障害があった際の共有、開発チームの目標をどれだけ実効したか、そして、MTGなどを通して、全体に周知しておくべきことがあるかの資料を作成し、進行をしていました。
プロジェクト管理ツールを導入してから、無駄に資料を作ることがなくなり、かなり楽になりました。
全体MTGについては、引き継いだままの流れに沿って、ある程度行うようにしていましたが、もっと効率良く、端的にできたのではないかと思います。
プルリクエスト体制の構築
要は「コードレビュー」をしましょう。ということです。実際に、実施してから実感したことですが、コードレビューは本当に大切だなと思います。
なぜなら、ある程度、皆が同じようなコードの書き方になるので、コードの品質を保つことが可能になります。それと、小さなバグを事前に見つけることも可能です。
他にもありますが、「それだけでも十分効果がある」ということです。
コードレビューをする前は、各々がコードを書いて、好きなタイミングでコミットして、マージしていました。
コードレビューという観点から考えると、ある意味、無法地帯ですね。ｗ
コードレビュー体制を導入するのも、「変化」が必要なので、やはり腰が重い意見も多く、納期が押している案件などでは、「いちいちプルリクをしていられない。」という意見もありました。
ごもっともだと思います。なんせ、受託開発は納期が最優先な所ありますから。
なので、あくまでも「クリティカルな負荷がかからないこと」を前提に、実行することを重きにおき、アクションを起こしていきました。
特に、最低限のコードレビューとして、
- インデントが無視されていないか
- ネストが深くなり過ぎていないか
- わかりにくいネーミングになり過ぎていないか
この3点だけでも、効果はあります。
人間は、何にでも慣れていく生き物です。
最初はコードレビューを強制させられている感が強く空気に出ていました。
ですが、段々と慣れ始め、当たり前のようにコードレビューができるようになったのは良かったです。
また、口述する勉強会の中で、15分程、時間をとって、チームメンバー全員でコードを見ながら、議論をすることで、コードに対する共通認識を促していきました。
勉強会の実施
週1ペースで勉強会の実施を行いました。
まず、AWSクラウドプラクティショナー試験に受かるために、勉強会を開く日程を作っていきました。
ただ、僕がチームリーダーとして、皆とのコミュニケートが満足にできない状況だったので、参加する人も少なく、結果として、3人でやる状況になってしまいました。
その後、継続していく中で、全メンバーが参加してくれようになりました。
やはり、人間関係の構築は、ある程度時間が掛かります。
次に、題材にした本は、「リーダブルコード」でした。オライリーのベストセラーになっています。
リーダブルコード ―より良いコードを書くためのシンプルで実践的なテクニック (Theory in practice) (日本語) 単行本（ソフトカバー） – 2012/6/23
なぜ、リーダブルコードなのか？は、プログラマー達に圧倒的に読まれている本だからです。
コードの基準を大多数に合わせることは重要です。
コードスタイルは様々な分、その自由の中から、一定のコーディングルールに従うことは、交通整理が上手く出来ているのと同じです。
コードの可読性が良くなるので、他の人の手が加えやすくなるというのは、非常に大きなメリットです。
スタンダードになりえる本を勉強会で学んでいくことで、同じようなコードの書き方が期待できます。
勉強会の問題としては、中々、業務で時間が取れない状況が多々ありました。
でも、業務のせいにして、勉強会が出来ないというのは、簡単なことです。
なので、半ば強制的に実施していくことで、どうしても参加できなかったメンバーには宿題として、タスクを与え、もちろん評価にも直結させる必要がありました。※心苦しい部分もありましたが。
あくまでも、「全員参加型でいく」というのは、念頭においていました。
皆、積極的に参加してくれていたことは、とても嬉しく思います。
メンバー評価制度の構築
「メンバー評価制度の導入する。」ということで、従業員に明確なランク付けと、「そのランクに到達するためには、何をクリアしておかなければいけないのか？」ということを明確にする必要がありました。
評価制度の外注をしていたようで、メンターみたいな人が月1ぺースで来社し、評価制度を構築していく中で、色々と状況を話すことがありました。
ランクに必要なIT資格であったり、どんな技術を使えて、どのようなアクションを起こせるか。ということ明確に考えていきました。
自分でも思っていた以上に、明確に判断基準を考えることができ、CTOにも、違和感なく受け入れてもらったようで、(※単に忙しかっただけ説)そこは良かったなと思っています。
また、評価制度に携われたこと自体が良かったです。
評価制度をしっかりと取り入れている中小企業は少ないですし、どこかで、また、この経験が活かせるようにできればよいと考えています。
評価基準については、結論からいうと、技術も大事ですが、組織に属している以上、コミュニケーション能力は、それ以上に大切だ。ということです。
最後に
前編と後編に分けて、開発チームビルディングで行ってきたことを書き記しました。
記事の目的として、これからチームビルディングに携わる人の参考になれば。というはもちろんですですが、「マネジメントや、チームビルディングの具体的な成果ってどう伝えればいいの？」
という自分自身への疑問から、答えを導き出すためでもありました。
難しいのは、これらを面談で、長くても2分以内で収めるということです。
面談時に、話が長い人は、「要点をまとめられない人」という判断がなされます。
また、話す内容に、その組織が求めている成果がなければ、「それはウチでは既にやってます」と、あしらわれます。※そういう問題じゃないと思うんですが・・ちゃんと人みて
実際、はっきりとした答えは出ていません。
前向きに、どこかで、こうした状況に苦しむ方に、また、アドバイスできる自分になれるだろうという風に考えています。
今となっては、組織に就くことは、結婚と同じようなもんなので、いちいち気にしてもしゃーないですけど。
同じような状況、打破された方、悩んでいる方、ツイッターでも何でもいいので、話しましょー
では、今回はこんな所で。