これからチーム開発を始める方々へ
うちの大学では、PBLを通じたチーム開発ってのをやるんよ。
要件定義から開発までの一連の流れを、チーム開発を通じて1年間学ぶのね。
ただ当時の自分は、文章力、読解力、課題発見、ファシリテーション、プレゼン、開発手法、UI/UX、フロントエンド、サーバ、ネットワーク、データベース等々のスキルは全く持ち合わせていなかったし、学んでいこうという姿勢もほとんどなかった。
そのくせプライドが高く自己中心的で、毎回自分の意見を前面に押し出していた。
そんな奴がチーム内にいるとどうなるだろうか
当然崩壊する
本記事を公開する目的は、私の1年間の挫折と後悔の日々から得た学びを、これからチーム開発を始められる方々に共有することにある。
ここに書かれていることはもしかしたら、至極当然のことなのかもしれない。
少なくとも当時の自分がこの記事を読んでいたならば、
「いや、そりゃそうでしょ」
と、間違いなく鼻で笑っていたであろう。
そんな自分では、いざ実践の場になると何一つ満足に成し遂げることができなかった。
- このプロジェクトの目的って何?
- メンバー全員を尊重する
- 共通認識なんて言葉は存在しない
- 話すときの口調
- 意見の賛成部分にリアクションする
- それは個人的な感情?一般論?それとも科学的根拠に基づいた事実?
- スケジュールを明確に
- 会議で話す議題を選定する
- 私のクソアジェンダ
- タスクの期間と完了の定義を明確に
- タスクを振るのは重労働
- アイデアやUIはできる限り可視化
- アイデアは没になっても、そこに至るまでのプロセスまで没にしないで
- 終わりに
このプロジェクトの目的って何?
プロジェクトを始めるうえで、メンバー全員にこの質問をするのは本当に大切なことなんだ。特にプロジェクト自体が大学講義の一環なのだとしたら尚更だ。
単位が欲しい、プレゼンスキルを上げたい、デザインレイアウトを学びたい、開発スキルを上げたい、チームでの開発に慣れたい、顧客に良いソフトウェアを届けたい
どれが正しいとか間違っているとかっていう話じゃないんだ。多分どれも正解なんだ。
ただメンバー全員が同じ目的または自分の目的を理解してもらえていると勝手に思っていると、後々とんでもないことになるんだ。
だから、まずはその勝手な思い込みを取っ払わなきゃいけないんだ。
プロジェクトの目的等を整理するうえで、インセプションデッキというドキュメントは非常に役に立つ。ぜひ参考にしてみてほしい。
メンバー全員を尊重する
チーム開発において、私はこれが最も大切な要素だと思っている。
私のようにメンバーを尊重できない人間は、チームとしてより良い成果物を出すことを徹底的に阻害してしまうんだ。
くだらないメンバー間の人間関係で、大切なプロジェクト期間を食い潰してしまう。
私は赤ちゃんよりもはるかに言語習得能力が低いし、児童期の子供よりもはるかに知的好奇心が劣っている。
自分の完全下位互換の人間なんているわけないんだ。
だからチームとして必要なのは自分の有用性を示すことなんかじゃなく、各メンバーが最大のパフォーマンスを発揮できるように協力し合うことなんだ。
共通認識なんて言葉は存在しない
「言わなくても理解してもらえる」
そんなことは絶対にありえないんだ。他人を理解することなんてできないんだ。
正直これは凄く難しい問題なんだ。チームで活動すればするほど、一般論と言わなければ伝わらないことの境界がとても曖昧だということに気づかされるんだ。
でもこれだけはメンバー全員が意識しなきゃいけない。
共通認識なんて言葉は存在しない
相手のことが理解できない。何でも言わなければ伝わらない。
それは腹立たしいことでも、恐いことでもないんだ。
それぞれの人生を歩んできた人々が協力し合ってモノづくりをする。それこそが、チーム開発における一番の価値や強みだと思うんだ。
話すときの口調
「だってそれは〇〇じゃん」「いやだから〇〇でしょ」
当時の自分が頻繁に使っていた口調だった。
この口調だと、自分にその気がなかったとしても相手に圧迫感を与えてしまう。
「私はあなたと口論したいのではなく、あなたと議論することでよりよいモノをつくりたいと思っています」
これを伝えるためにはどうしたらいいだろうか。直接この言葉を伝えるのもありかもしれない。でもそれだとまだ足りないんだ。
「お金は今度返すから」と同じくらい説得力がないんだ。
だからこそ、相手に自分の意見を伝えるときの口調はとても大切なんだ。
相手を尊重していることを日々の話し方で伝えていく必要があると思うんだ。
意見の賛成部分にリアクションする
ある意見に対しどういう問題や困難な点があるかを伝えることは必要だと思う。
でもそれ以上にずっとずっと、その意見のどの部分に賛成しているのか、どういった発展性があるのかを伝えることは大切だと思うんだ。
自分が出す意見に対して毎回反対意見しか出てこないと誰だって嫌になる。
チームの空気が死んでしまうんだ。
そんなチームに良いアイデアが出てくるわけないんだ。
人間、というよりも動物は、どうしてもポジティブな内容よりもネガティブな内容を探すのが得意なものなんだ。生存確率を上げるための当然の特性なんだ。
だからこそ、ポジティブなリアクションをチーム全体で心掛けていくべきだと思うんだ。
それは個人的な感情?一般論?それとも科学的根拠に基づいた事実?
「私は赤色が好きです」 これは個人的な感情
「人を殺してはいけません」 これは一般論
「fortranに比べ、C言語はライプニッツの公式の計算速度が1.44秒速かった。」 これは根拠に基づいた事実
話している内容がこの3つのどれに当てはまるのかは、常に意識する必要があるんだ。
個人的な感情同士をぶつけ合ってもしょうがないんだ。時間の無駄なんだ。
個人的な感情を減らし、生産性のある意見を出すためには知識量を増やすしかないんだ。
私の場合はほとんど個人的な感情で意見を出していた。
そんな奴は自分の知見の無さを自らさらけ出しているようなものなんだ。バカ丸出しという言葉がお似合いだ。
スケジュールを明確に
スケジュールは必ず、ある程度でもいいから立てるんだ。
スケジュールがないと、アジェンダの議題の選定やメンバーの士気の意地が困難になってしまうんだ。
プロジェクト終了までにどんなマイルストーンがあり、各マイルストーンに必要な準備物は何か、各マイルストーンまでにどこまでの進捗を出すつもりなのかは最低限決めるべきだと思うんだ。
進捗やゴールが見えないマラソンほどつらいものはないんだ。
スケジュールを立てるのはめんどくさいと思うかもしれないけど、各マイルストーンに対する目標を定めたほうが、はるかに作業効率は上がるんだ。
会議で話す議題を選定する
会議というのはメンバー全員が顔面引き合わせて話し合えるとてもとても貴重な機会なんだ。その時間を無駄にしちゃいけない。
会議内で話し合う議題は慎重に決めるんだ。常にメンバー全員が集まって話し合う価値があるかを意識するんだ。slack上で終わる議題なら、集まる必要は無いんだ。
私のクソアジェンダ
私のアジェンダは本当にクソだった。
たいてい話し合う議題と時間のみ。たまにその議題の到達目標が書かれているくらい。
これじゃあ全然足りないんだ。
よほど洗礼されたチームでない限り、これはアジェンダとすら呼べないんだ。
各議題に対しその目的と、どこまで話し合い
どこからは話し合わないか
を全メンバーが理解できるようなアジェンダにすべきなんだ。
めんどくさい?
これをやらずに話し合いがあっちゃこっちゃ行くほうがずっとめんどくさいと私は思う。
タスクの期間と完了の定義を明確に
タスクをメンバーに割り振る際は、
- いつまでにやるのか
- 完了の定義(誰が見ても客観的に判断できるレベル)
最低でもこの2つは決めておくべきだと思うんだ。
期限を決めておかないと誰だってずるずるとそのタスクを後回しにしてしまうんだ。
またあらゆるタスクに期限をつけることによって、その人がどれくらいのタスク量を、どれくらいの期間で達成できるかも見えやすくなるんだ。
完了の定義については「共通認識なんて言葉は存在しない」にも通ずることろがあるけど、人によってそのタスクの完了の定義は思っている以上にバラバラなんだ。
だから誰が見ても客観的に判断できるくらいにタスクの完了を定義しないと、いざ終わったタスクを見た時に、oh... ってなっちゃう可能性が爆増しちゃうんだ。
タスクを振るのは重労働
タスクを振るなんてクソ簡単。
私も最初はそう思っていたんだ。でも本当はとても重労働なタスクなんだ。
自分の頭の中にある構想を文章化or言語化して相手に伝えるってのは想像以上に大変なことなんだ。
「タスクを振る」というタスクをなめちゃいけない。
タスクの中に「タスクを振る」というタスクも考慮しないと、どんどんスケジュールがボロボロになってしまうんだ。
アイデアやUIはできる限り可視化
自分の頭の中にある構想を伝えるのに、言語や文章だけでは限界があるんだ。
というか、余程言語能力に長けた人でもない限り伝わるわけない。
モックアップを作るまで行けなくても、紙に書いて可視化するだけでもいいんだ。伝わり方が全然違う。
紙に書けない場合は、類似した既存のコンテンツを見せるでもいい。
メンバー全員の頭の中にある構想を可視化しないままプロジェクトが進んでしまうと、最後に待っているのはとんでもない ちゃぶ台返し なんだ。
アイデアは没になっても、そこに至るまでのプロセスまで没にしないで
そりゃアイデアは没になることもあるよ。
一瞬でいいアイデアが出まくって、要件定義が完璧なら誰も苦労してない。
アイデアが没になるのはしょうがない。でもそのアイデアにたどり着くまでに至ったプロセスまで一緒に捨てる必要は全くないんだ。
採用したプロセスのどこまではよくて、どこからか問題だったのかをチーム内で検討していくことで、どんどんアイデア出しが洗練されていくんだ。
毎度毎度採用したプロセスを捨てていたら、チームとしての成長率がガタ落ちしてしまうんだ。
終わりに
ここまで書いておいてなんだけど、全部私の個人的な反省を文章化しただけだから、割と間違っていることだらけかも。
ただこの記事を読んで、「こいつよりはましにチーム開発やってやるわ」って思える人が一人でも増えてくれると嬉しい。