この記事は何
何かなっていうと、とあるプログラミングコンテストでプロジェクトを立ち上げて開発をしていく中で、私自身に対する問題や、メンバー側の問題などに直面してしまい、かなり開発が滞ってしまうようになってしまいました。
この場を借りて、チームメンバーには謝罪させていただきます。申し訳ありませんでした...。
本記事で、チーム開発をする上での問題点や解決策などを挙げていき、私自身のリーダー能力の向上及び、チーム開発で留意するべき点などを今一度理解をして、今後のチーム開発に役立てていこうという次第であります。
以下の構成で行きます。
- リーダー側
- メンバー側
リーダー側
仕様書が雑
仕様書が壊滅的なものはメンバー側も「何がしたいの？」となってしまいます。
また、タスク管理をする場合にも仕様書の詳細な部分まで掘り詰めておくとタスク割り当てやタスク管理がしやすく、進捗管理もしやすいです。
仕様書は言わば開発の要です。
仕様書は以下の作成をメンバーと一緒に進めることが重要です。
- 企画書
- 外部設計
- 画面設計書
- 画面遷移図
- シーケンス図
- 内部設計
- ER図
- データベース設計
- システム構成図
- プログラム設計書
他にも必要なものはあると思いますが、少人数設計の場合、この程度があれば開発はできます。このテキストデータをチームで共有して、プロジェクトを進めるようにしましょう。
仕様書は詳細までしっかりと！
チームのミーティング不足
私がチームで開発をするとき、ほとんどのメンバーがミュート、或いはテキストチャットでの反応でしたが、リーダーをやっていた私にとって、声が聞こえないというのは不安でしかありませんでした...。
また、メンバーに対しての私の配慮があまり足りず、結果的になぁなぁなミーティングになってしまいました。
こうなってしまうとメンバーは
- ミーティングをする意味がないと感じてしまう
- プロジェクトのモチベーションがなくなってしまう
といった問題を抱えてしまいます。
こうならないためにもミーティングは適度に行うべきですが、ミーティングがただの進捗確認だけで終わらせてしまうと、また良くない状態になります。
解決策
1on1ミーティングを行う
1on1ミーティングはその名の通り、メンバーとの一対一のコミュニケーションを取り、プロジェクトの理解度に加え、メンバーに対する理解を得るための場でもあります。
以下の効果があります
- メンバーの理解を得られる
- メンバーのモチベーションの向上
- メンバーの能力の管理と向上
ミーティングでは話すことを考える。
これはないと思っていますが、私自身、ミーティングをあまり行ったことが無く、ミーティングで話すことが無くて、結果的に単なる進捗報告会みたいになってしまいました。本当に良くないです。
この状態では「ミーティング意味ないな」ってなってしまいます。
メンバー側のモチベーションを向上させるためにも、ミーティングに意味を持たせて、意見を言ってもらったり、課題点や問題点などを挙げて解決をする有意義な時間としてするためにも
- 現状の問題点の確認
- メンバー側にもしっかりと発言させる
これらが重要になると思います。
メンバーがミーティングという神聖な場で「何も話さない」というのは非常に問題です。よくある例が
リーダー「なにか意見や抱えている問題などは在りますか？」
メンバー「特にありません」
という会話です。何にも生産性が無いですしこの時間が非常にもったいないです。リーダー側は「問題意識を持たせる」という努力をするべきだなと思いました。
ミーティングはチーム開発において重要な時間。
メンバーとのコミュニケーションとプロジェクトに対するモチベーションを持たせるためにも、有意義なミーティングを行うことを心がける。
メンバー側
プロジェクトに対する理解努力や問題意識
これは仕様書の出来にもよると思いますが、チームリーダーが仕様書を書くのが下手くそ苦手な場合もあるので、プロジェクトの仕様書をしっかりと読む努力や、わからないところや修正するべきところは修正して、テキストデータのバージョンを変更していく必要があります。
仕様書などのテキストデータはGithubなどに挙げておくのも良いですし、NotionやGoogle Driveなどを使ってグループで共有する方法なども考えられます。
また以下のような努力もする必要があります。
- プロジェクトの企画に自身の意見を挙げていくことも非常に重要
- 問題点や改善点などは、チームリーダーに遠慮なく発言する
このような、「主体的な行動」をすることもメンバー側では重要です。
必要な技術スタックを身に着ける努力
こればっかりはどうしようもないですが、チームで開発するならば特に重要なものだと思います。
これは、プロジェクトの外部設計段階で、どのような技術スタックが、どれに必要になるのかなどをリストアップしておき、予め技術の習得と知識共有をしておく必要があります。
「WebUSB...？なにそれ！わからないからできない！」
「AWS...？きいたことあるけど、わからない！」
こういわれてしまうと、かなりできること、やれることが減ってしまい、メンバーの中では「使い物にならない」という立ち位置になってしまいます。
チーム開発という場は、プロジェクトの完成のみならず、自分自身の技術スタックの育成も範囲のうちです。
プロジェクトで必要な知識は自分が知らなくてもやれるようにしっかりと学習していくことが重要であるといえます。
最後に
以上で終了します。
最近、新しいキーボードを購入して、文字を打つ練習がてらこの記事を書きました。
私は実際、リーダー経験が雀の涙のようになく、プロジェクト開発ではかなりメンバーの足を引っ張りました。
また、そのせいかメンバーの行動がよくわかっておらず、自分自身でも「あの人何やってんだ？？」って思っちゃう人もいました。(本当に申し訳ない)
今でも新しいプロジェクトを立てて開発をしていますが、そちらではチームメンバーの技術スタックの問題による開発の難しさから、何回かプロジェクトの仕様を変更する羽目になりました。
チーム開発というのは非常に難しいなと感じており、ましてや「自分勝手にやってやろう！」なんて考えると、チーム開発でもなくなってしまいます。
チームである以上、メンバー側からも、リーダー側からもコミュニケーションを取り、プロジェクトをより良いものにしていこうとする姿勢が重要であるといえます。
最後ですが、私はおそらく、リーダー向きではないなって自虐しておきます。私は、コミュニケーション能力はある方だと自負していますが、如何せん、
「中身がない」
って言われます。中身のある会話をする努力はしていますが...。よくわからず結局あやふやな会話になります。
今後リーダーになる場合では、特に以上のことを気を付けようと思います。
メンバーの皆様、本当に申し訳ありませんでした。