ものづくりのチーム開発を攻略しよう① リーダーが気をつけるべきこと
この記事はWMMC Advent Cakendar 2021 25日目の記事です．
今までの記事も是非↑をクリックして読んでください！
今日の記事の目次と概要↓ 適宜飛んでください！
はじめに
あらすじ
こんばんは，まんぼーです．
1年ぶり(昨年のAdvent Calendarぶり)の更新です．
私を知らないWMMCメンバーも多くなってきたかと思います．学内でしか伝わらなそうな表現で自己紹介しておくと，S0UK1のM2で，所属はT研です．
コロナが流行してからサークルに顔を出す手続きが面倒になり，サークル活動が緩和されてからは中々行く時間がとれなくなってしまいました．卒業までに顔を出さねば…
昨日の記事はalminum君による「CADをクラウド管理してみた」でした(まだ公開されてないみたい。記事みたら再度編集します)．
最近は様々なものがクラウド化していて，便利ですよね．
たまにネットワーク障害で機能しなくなることもあるので，クラウドに頼りすぎると痛い目を見ることがあります．臨機応変に対応したいところです．
さて，今年のカレンダーは書く余裕ないなぁとか思って放置してましたが，J●君とs●phia君に沢山脅迫されたので，書くことにしました．
技術のことを書こうかと思ったのですが，簡単なものは先人のすごい人たちのおかげで山ほど転がっていますし，話したい分野は大体研究絡みで機密性が高くて、ブログに出すためにはモデルを作り直さなければならないしそこまでの時間はない... マウスは先人の方々の尽力のおかげでオープンになってきているので，技術を学びたい人には良い材料だなぁ，とつくづく実感しています．
そんな中何を書こうか迷っていたのですが，私は今年結構大きめの研究プロジェクトをリーダーとして回してきました．多分ドクターがやるべきことなのですが，残念ながら自分の研究班には研究を主導してくれるドクターがいなかったため，チーム開発について悩んだり気をつけなければいけないことが多い1年でした．また，学部の頃にやっていたロボコンでもチーム開発について考えさせられることが多くありました．
そこで，チームでものづくりをする時にリーダーやメンバーが気を付けるべきことや，重要だと感じたことについて書き連ねたいと思います．長くなってしまったので，分割して公開したいと思います(書くのが間に合っていないなんてそんなことないよ！！！汗)．
この記事では，リーダーとして自分が常に注意していることや，失敗から得た知見を少しでも共有できればと思います．
読むとためになる人
- チームをリーダーとして率いる必要がある人
- チームリーダーをやって失敗したことがある人
- チームで仕事を奪いがちな人
- チームでの開発経験がない人
- これから研究をするB1~B3の人
(そのうち公開する「メンバーが気を付けるべきこと」を読むと良いです)
- 未来の自分
そもそもチーム開発をするメリットとは？
マイクロマウスをやっている人はチーム開発の経験がない人もいると思います．また，チーム開発をしていても１人のほうが進むと感じている人も多いと思います．自分が優秀すぎる人は，足を引っ張られた経験からチーム開発を嫌う傾向にあるような印象があります．
では，なぜわざわざそんなチーム開発をするのでしょうか．
答えは，以下に尽きると思います．
引用元: わかめ on Twitter: "世界のことわざの中で群を抜いて好き。… "
1人では必ず限界があります．その限界を突破するためにはチームでやらなければなりません．
もちろん，小さなプロジェクトなら1人で回せるかもしれませんが，大きなプロジェクトの開発，マウスより大きなロボットの開発では，分担をした上で各々がその分担におけるスペシャリストになることによって，1人での開発では到底届かないレベルにもっていくことができるのではないか，と思います．もちろん，大きなロボットの設計から制御まで全部1人でやってしまう化物級の逸材もいますが... そんな人でも，やっぱりチームを組んで開発していることが多いですよね．
それは，チームを作り技術を繋いでいくことにより，開発を始めた最初にはできなかったことができるようになっていくからだと思います．
リーダーが気をつけるべきこと
リーダーが常に考えるべきことは「チーム全体を見て目標に対してうまくいっているか」を意識することです．私が挙げることが全てではないと思いますが，これを実現するために重要なことをいくつか挙げ，細分化して見てみたいと思います．
1. チーム内全員に目標・方針を誤解なく共有する
大事なことは全員に共通の目標を誤解なく持たせることです．後輩の指導をしたことがある人はわかると思いますが，誤解なく，というのが非常に難しいものです．メンバーが少しでもリーダーの思っている理想の方針と違う解釈をすると，誤解に気づくまで少し違う目標に向かって進み始めます．これは大幅なタイムロスです．
例えば，後輩を指導していて「自分が言ったことと違うことをやってきたな…」と思ったことありませんか？私も指導をする側になった頃にしばしば感じたことがあり，「ちゃんと言ったのにな…」と思うことがありました．
これによるタイムロスは基本的にリーダーの責任だと思っています．
いや，指導を受ける側がちゃんと理解しないのが悪いでしょ！と感じる人はまずはじめに自分の指導の仕方を見返すべきです．
タイムロスが起きる理由は主に2つあります．
1つめの要因は「自分の思っていることを正確に伝えられていない」ことです．
これにもいくつか種類があると思いますが，「言葉足らずで大事な部分が抜けている」か，「話がまとまっていないため要点が掴めない」のどちらかが多いのではないでしょうか．
その人が誰に対しても当たり前だと勘違いして一部の内容を省いているか，頭の中にふわっと浮かんでいる主張を言語化しきれていないことが原因であると思います．
日頃から言語化する練習を行い，数日後の自分が見返して理解できる文章を作る訓練をしましょう．私も口下手な方なので，まず言語化できるまで考え抜き，PCやスマホなどで文章化して伝わりやすい文章かどうかを考えるようにしています．
言語化がうまくできるようになるまでは，本当に自分の言ったことを理解しているか，意図が伝わっているかを確認しながら，何か違うと思ったらその時点で考えが合致するまで説明を丁寧に行う他ないと思います．
自分は丁寧に教えてるけど…と思うなら，2つめの要因として挙げられることは，「リーダーの思考と自分の解釈が同じかどうかを常に考えさせ，気になったら必ず相談するように初期の頃に指導していないこと」です．この指導を初めのうちにやっておかないと，相談せずにとりあえず進めることに慣れてしまうため，修正が利きにくくなり，いつまで経っても同じことが起き続けます．もちろん指導しなくても自ら相談しに来てくれる人もいますが，相談することにすら抵抗を感じる人もいます(自分は割とそうです)．個々の性格をうまく汲み取り，相談しにくい人が相談してくれるような環境づくりを最初に行うことが大事です．
2.方針・方向性の是正
チームを組み始めて間もない頃は方針を定めるために頻繁にミーティングをすると思います．しかし，方向性が固まってくるとミーティングの頻度が少なくなり，気づいたら自分の思っていた理想と離れた方向になっていることがあります．
また，時間が経つにつれて方針や方向性を変更しなければいけないことが出てくることもしばしばあります．
これらの変化にいち早く気づき，必要に応じて是正を行うこともリーダーの役目です．
3. 進捗管理とタスクの分担量の調整
複数人で開発するからには，進みの速い人もいれば遅い人もいます．また，そのスピードはタスクの重さによっても変わります．各人の進み度合いや性格などを見ながら仕事の振る量を見極め，タスクをうまく分担することが重要です．進度が早い人に，仕事を分散させることにより，効率的に進めるべきです．リーダーがある程度手伝ってあげることも選択肢の一つです(ただし，項目6・7に気をつけましょう)．
また，進捗管理をする際，タスクには必ず優先度をつけるようにしましょう．同時にやることが多いと，どうしても簡単なものから取り組んでしまいがちです．必ずプロジェクトにおいて最も効果的に効いてくるタスクから取り組ませましょう．
4. メンバーの人数が適切かを考える
これはメンバーを取る前の話になりますが，プロジェクトに応じて適切な人数を取るべきです．多い方が分担できて楽でしょ！と思うかもしれませんが，ものづくりにおいてはそうとは限りません．
例えばボールを投げる1m立法くらいのロボット1台を作って動かしたいとしましょう．あなたがチームリーダーをするとして，何人ほしいですか？
開発期間とチームメンバーのやる気度合い・熟練度合いによって変わるとは思いますが，開発期間は1年，やる気は全員あるものとします(もしくは卒修論や給料が出るためやらざるを得ない状況だとします)．大体メカで2~3人，ソフトウェアに3~4人，回路で2人くらいではないでしょうか．もちろんあくまで参考人数です．メンバーの熟練度合いによってはこれより少なくてもいいと思います．
メカは足回りに1人，アームに1人，統合やなんやかんやする人でもう1人(要らない？)．
ソフトウェアは足回りのモータ制御に１人，動作計画に1~2人(動作計画の程度による)，アームの制御に1人．
回路はソフトウェアの人数を多く取る場合にはその中の1人にもやってもらい，合計で2人．
メンバー過多のチームではタスクが被る人が出てきて，うまく分担できない・タスクの取り合いが発生する状況に陥ります．
漠然と「うーん，なんとなく4人ほしい！」みたいに考えるのではなく，どのように分担させるかを考えた上でメンバー数を決定しましょう．
5. 必要に応じて決定権を行使する
これはポスドクに言われて学んだことです．今年は何回もこれに助けられました．
方針決めや何等かの取捨選択をする際，中々決まらずグダグダになることがあります．普通物事の取捨選択をする際には，いくつかの物事に対して比較項目を並べ，根拠を探したり試作をいくつかした上で感覚に頼らずに比較する，ということを行うことが大事です．これは研究を始めたばかりに言われることだと思います．
根拠を探すことなら比較的短期間で終わらせられますが，ものづくりにおいてはただ根拠を探すだけでは取捨選択できず，試作をしなければいけないことも多いです．特にプロジェクトの開発期間等が短い場合，「試作をしないとわからない」という時間は非常にもったいなく，最終的に間に合わなずうまくいかなかった，といった結果になる可能性が出てきます．
これを防ぐためには，重大な場面においてリーダーが決定権を行使することが重要です．自らの経験を踏まえ，「これならうまくいく可能性が高い」という選択を行い，「これは多分無理だ」という選択肢を捨てることが必要となります．1つに絞ることは無理だとしても，比較項目を経験からいくつかに絞ることにより，時間のコストを削減することができます．ある意味博打です．博打が原因でうまくいかなかったら反省するしかないですが，そうならないように経験を踏まえた判断ができるよう，普段から判断力と即決力を鍛えましょう．すぐに身につくものでもないので，リーダーになる前から取捨選択を正しく行う習慣をつけるべきです．
決定権を行使しすぎると他人の考えた案を潰す場合があります．絶対無理だろうという案を潰すのは良いと思うのですが，良い案を潰さないように気をつけましょう．潰すときは，必ず論理的な理由をつけ相手を理解させるよう心掛けましょう．そうでないとただの理不尽になります．
6. メンバーをフォローする
7. メンバーを信頼する
6,7についてまとめて説明します．
チームでリーダーになる人はソフトウェア開発からハードウェア設計，回路設計まで，色々な事が出来る人が多いと思います．なんでもできるからと言って分担したはずの作業を取ったりしてしまうと，メンバーが成長していきません．作業を取るのではなく，成長を手助けすることがリーダーの役割だと思います．メンバーを信頼し，物事を主体的に取り組まることにより次第に自分が手助けをする頻度が減り，開発効率が上がっていきます．
8. 消えない
色々書きましたが，これが最も大事だと思います．今までチームをまとめていた人が突如いなくなると，チームは大混乱です．大規模かつ忙しいプロジェクトではありがちだと思いますが，消えないようにしましょう．
メンタル面で消える可能性がある人は，いつ消えても仮のリーダーを立てられるよう，日頃からチーム全体に関する相談をしたり，自分の考え方を共有できるメンバーを作っておきたいところです．リーダーを務められる人が何人かいる場合は，メンタルの強い人にリーダーを任せた方が良いと思います．
ボスではなくリーダーになろう
これまで，ものづくりにおいてリーダーが気をつけるべきことを書いてきましたが，リーダーになる人には必ず知っておいてほしい言葉があります．それは「ボスになるな」という言葉です．イギリスの起業家であるハリー・ゴットン・セルフリッジの言葉が有名です．
以下，セルフリッジが表現した「リーダーとボス」の違いです．
・ボスは部下を追い立てる
↔リーダーは人を導く
・ボスは権威に頼る
↔リーダーは志、善意に頼る
・ボスは恐怖を吹き込む
↔リーダーは熱意を吹き込む
・ボスは私という
↔リーダーはわれわれという
・ボスは時間通りに来いと言う
↔リーダーは時間前にやってくる
・ボスは失敗の責任を追わせる
↔リーダーは黙って失敗を処理する
・ボスはやり方を胸に秘める
↔リーダーはやり方を具体的に教える
・ボスは仕事を苦役に変える
↔リーダーは仕事をゲームに変える
・ボスはやれと言う
↔リーダーはやろうと言う
皆さんはボスとリーダーのどちらのほうが良いと思いますか？価値観によって変わると思いますが，私はリーダーの方が有用だと思いますし，このようなリーダーになりたいと思っています．
詳しく気になる人は，私が説明するよりも下の記事を読むと良いと思います．トヨタの経営の話ですが，根本はものづくりのチーム開発においても同じだと思っています．
おわりに
いかがでしたでしょうか．この記事を書きながらも，自分がまだうまくできていないな，と感じるものがたくさんありました．全部できる人になりたいですね...
少しでもチーム開発の参考になると幸いです．
また，ここに書いていない内容で，自分はこういうことに気をつけてるよ，ということがある人は是非コメントなどで教えてください．
修論が落ち着いたら，
・メンバーが気をつけるべきこと
・数年計画の開発で気をつけるべきこと
についても書いて公開したいと思います．
WMMCのAdvent Calendar2021はこの記事で終了です．
卒業された先輩方の記事を見れるこの企画は結構良いですよね．後輩の誰か，来年も是非企画してやってください！
それでは良いクリスマス・良いお年を！
