LIFE STORY WEBエンジニア 上級者

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

 

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

 

前回に引き続き、僕が開発チームビルディングで行ってきたことを書いていきます。

前回の記事が気になる方は、コチラを参考にしてください。

 

 

メンバーのスケジュールと工数管理

会社組織として、一番の問題といっても過言でなかったのが、「工数管理」です。

最終的には、工数可視化ツールを導入し、プロジェクト管理をする流れになりました。

 

開発部で、工数を意識しながら、開発を行っているメンバーが少なく、最終的な消化率が100%を越え、すなわち、赤字状態が続いていました

ですが、元々、見積もり精度が甘く、無茶なスケジュールの案件もありました。個人的には、一番解決するのが難しかった課題です。

 

結果的に、完全な解決には至りませんでした。

 

各メンバーに責任感を持ってもらうために、見積もりについての対策案などを促しました。

そして、全体で対策案を共有しながら、評価制度のランクによって「どれぐらいの工数消化率であればよいか」を具体的な数値目標として表すことで、明確なゴールが見えるように対策していきました。

 

「見積り自体は、実作業する人が見積もりも行う。」という方法が、自身で考えた見積もり案なので、責任感も生まれやすい。

結果、上手くいかない場合でも、納得しやすいでしょう。

会社としては、プロジェクトが赤字になるのは困るんですが。

 

ですが、開発業務を行いながら、並行して、見積もりを行っていくというのも、時に難しいのが現実です

 

精度を上げるために、見積りレビューをしても、人的リソースが掛かってしまいます。

非常に悩ましい問題でした。

 

成果としては、各メンバーに問題定義を促すことで、以前よりも、工数に対する意識は確実に上がりました。

システム開発は複雑であるがゆえ、見積りを見落とす問題もあり、ウォーターフォール工程の限界を感じる結果になりました

 

部署間の相談役

会社組織には以下、3つの部隊がありました。

  • 営業チーム
  • 開発チーム
  • テストチーム

 

組織は人の集まりである以上、やはり、人間関係を避けることはできません。

プロジェクトを進行していく過程で、必ず「伝えたことが違う」という問題が発生します。

 

相手が求めていることと、自分が理解していることの差異は、どの業務でも起こり得る問題ですが、システム開発の場合、手戻りが激しくなる場合があり、結果として工数超過に陥り、プロジェクト失敗になり得ます。なので、早い段階での、軌道修正が必要です。

 

基本的なコミュニケーションツールは、ChatWorkを使用していました。

プロジェクトの案件毎にやり取りを確認し、少しでも「やりとりが上手くいってなさそうだな」と感じた場合、間に入るようにしていました。特に別途、個人に向けて声をかける。

 

僕が、大切にしていたのは、ChatWork上でのやりとりよりも、別途、MTGで個室の時間をとり、「関係者同士 + 僕」という形で、コミュニケーションをとるようにしていました

なぜなら、チャット上だけでは、感情などの表現が伝わりにくく、曖昧さを汲み取ることも難しいと考えています。

なので、そこは第三者も交えて、伝わりにくいことを理解しにいく。という形でアクションを起こしていました。

 

そのようにしていると、自然と、こちらがアクションを起こす前に、他のチームからも相談してもらえるようになりました

 

人から頼られるのは、嬉しいもの。

そして、「寄り添ってくれる」と、メンバーから評価をいただいたことは、とても嬉しかったです。

 

全体MTGの進行とまとめ

月1で全体ミーティングがありました。そこで、基本的に以下の報告をします。

  • プロジェクト毎の開発状況と工数消化率
  • 障害共有と改善策
  • 開発チームの目標の進行度
  • 全体に周知すべきお知らせ

全体ミーティングの2週間程前から、工数消化率をはじき出し、プロジェクト毎の開発状況と、障害があった際の共有、開発チームの目標をどれだけ実効したか、そして、MTGなどを通して、全体に周知しておくべきことがあるかの資料を作成し、進行をしていました。

 

プロジェクト管理ツールを導入してから、無駄に資料を作ることがなくなり、かなり楽になりました。

全体MTGについては、引き継いだままの流れに沿って、ある程度行うようにしていましたが、もっと効率良く、端的にできたのではないかと思います。

 

プルリクエスト体制の構築

要は「コードレビュー」をしましょう。ということです。実際に、実施してから実感したことですが、コードレビューは本当に大切だなと思います。

なぜなら、ある程度、皆が同じようなコードの書き方になるので、コードの品質を保つことが可能になります。それと、小さなバグを事前に見つけることも可能です。

 

他にもありますが、「それだけでも十分効果がある」ということです。

 

コードレビューをする前は、各々がコードを書いて、好きなタイミングでコミットして、マージしていました。

コードレビューという観点から考えると、ある意味、無法地帯ですね。w

 

コードレビュー体制を導入するのも、「変化」が必要なので、やはり腰が重い意見も多く、納期が押している案件などでは、「いちいちプルリクをしていられない。」という意見もありました。

ごもっともだと思います。なんせ、受託開発は納期が最優先な所ありますから

 

なので、あくまでも「クリティカルな負荷がかからないこと」を前提に、実行することを重きにおき、アクションを起こしていきました。

特に、最低限のコードレビューとして、

  • インデントが無視されていないか
  • ネストが深くなり過ぎていないか
  • わかりにくいネーミングになり過ぎていないか

この3点だけでも、効果はあります。

 

人間は、何にでも慣れていく生き物です。

最初はコードレビューを強制させられている感が強く空気に出ていました。

ですが、段々と慣れ始め、当たり前のようにコードレビューができるようになったのは良かったです。

 

また、口述する勉強会の中で、15分程、時間をとって、チームメンバー全員でコードを見ながら、議論をすることで、コードに対する共通認識を促していきました。

 

勉強会の実施

週1ペースで勉強会の実施を行いました。

まず、AWSクラウドプラクティショナー試験に受かるために、勉強会を開く日程を作っていきました。

ただ、僕がチームリーダーとして、皆とのコミュニケートが満足にできない状況だったので、参加する人も少なく、結果として、3人でやる状況になってしまいました。

 

その後、継続していく中で、全メンバーが参加してくれようになりました。

やはり、人間関係の構築は、ある程度時間が掛かります。

 

次に、題材にした本は、「リーダブルコード」でした。オライリーのベストセラーになっています。

リーダブルコード ―より良いコードを書くためのシンプルで実践的なテクニック (Theory in practice) (日本語) 単行本(ソフトカバー) – 2012/6/23

なぜ、リーダブルコードなのか?は、プログラマー達に圧倒的に読まれている本だからです。

コードの基準を大多数に合わせることは重要です。

 

コードスタイルは様々な分、その自由の中から、一定のコーディングルールに従うことは、交通整理が上手く出来ているのと同じです。

 

コードの可読性が良くなるので、他の人の手が加えやすくなるというのは、非常に大きなメリットです。

スタンダードになりえる本を勉強会で学んでいくことで、同じようなコードの書き方が期待できます。

 

勉強会の問題としては、中々、業務で時間が取れない状況が多々ありました。

でも、業務のせいにして、勉強会が出来ないというのは、簡単なことです。

 

なので、半ば強制的に実施していくことで、どうしても参加できなかったメンバーには宿題として、タスクを与え、もちろん評価にも直結させる必要がありました。心苦しい部分もありましたが。

あくまでも、「全員参加型でいく」というのは、念頭においていました。

 

皆、積極的に参加してくれていたことは、とても嬉しく思います。

 

メンバー評価制度の構築

「メンバー評価制度の導入する。」ということで、従業員に明確なランク付けと、「そのランクに到達するためには、何をクリアしておかなければいけないのか?」ということを明確にする必要がありました。

評価制度の外注をしていたようで、メンターみたいな人が月1ぺースで来社し、評価制度を構築していく中で、色々と状況を話すことがありました。

 

ランクに必要なIT資格であったり、どんな技術を使えて、どのようなアクションを起こせるか。ということ明確に考えていきました。

自分でも思っていた以上に、明確に判断基準を考えることができ、CTOにも、違和感なく受け入れてもらったようで、(単に忙しかっただけ説)そこは良かったなと思っています。

 

また、評価制度に携われたこと自体が良かったです。

 

評価制度をしっかりと取り入れている中小企業は少ないですし、どこかで、また、この経験が活かせるようにできればよいと考えています。

評価基準については、結論からいうと、技術も大事ですが、組織に属している以上、コミュニケーション能力は、それ以上に大切だ。ということです。

 

最後に

前編と後編に分けて、開発チームビルディングで行ってきたことを書き記しました。

 

記事の目的として、これからチームビルディングに携わる人の参考になれば。というはもちろんですですが、「マネジメントや、チームビルディングの具体的な成果ってどう伝えればいいの?」

という自分自身への疑問から、答えを導き出すためでもありました。

 

難しいのは、これらを面談で、長くても2分以内で収めるということです。

 

面談時に、話が長い人は、「要点をまとめられない人」という判断がなされます。

また、話す内容に、その組織が求めている成果がなければ、「それはウチでは既にやってます」と、あしらわれます。そういう問題じゃないと思うんですが・・ちゃんと人みて

 

実際、はっきりとした答えは出ていません。

前向きに、どこかで、こうした状況に苦しむ方に、また、アドバイスできる自分になれるだろうという風に考えています。

 

今となっては、組織に就くことは、結婚と同じようなもんなので、いちいち気にしてもしゃーないですけど。

同じような状況、打破された方、悩んでいる方、ツイッターでも何でもいいので、話しましょー

 

では、今回はこんな所で。

 

-LIFE, STORY, WEBエンジニア, 上級者
-

© 2021 FuwaFuwaShoChan BLOG