競技で勝てる良いロボットを作るためには、チームの技術力とマネジメント力がそれぞれ求められ、どちらが欠けても思うような成果は出せなくなります。 チームの技術的な改善は、たくさん作り込みながら自分たちで鍛えていける部分も多いのですが、チームマネジメントは何を参考にしたら良いのか分からず、改善の見通しが立てづらい部分だと思います。 この記事ではマネジメントの技術に注目し、私の率いた2018年RoboCup Rescue RMRC競技の世界大会優勝チーム”TUPAC”を例に、チームマネジメントの具体的な取り組み方について紹介します。

単一ワークフローでの開発とその問題点

図1はロボットのHW/SW(ハードウェア/ソフトウェア)開発を単一のワークフローとして取り組む場合の例です。 この図は「ガントチャート」という、横軸に時間、縦軸に作業内容を配した一覧表で、ロボットの開発などのプロジェクトを進めるのに必要なタスクや時間の管理方法の一つです。

大会に始めて参加する選手の多くは、部品調達からHW(ハードウェア)開発、SW(ソフトウェア)開発までを1つのワークフローとして順番にこなそうとします。 しかし、このような取り組み方は、手持ち無沙汰になるメンバーを発生させたり、問題を早期に発見してそれを改善するためのサイクルが回しにくいなど、多くの問題があります。 この記事を読む選手の多くが、現在このような流れで開発をしているか、過去にこうした方法で取り組んでその問題点を経験したことがあるかもしれません。

この取り組み方における問題は次のようなものです。

1. SW開発担当がHWの完成を待つ時間が発生する
単一ワークフローでは、SW担当者がロボットの実機の完成を待つ時間が発生してしまいます。ロボットを作ってから出ないとソフトウェアは書けないように思いがちですが、工夫すればもっと早い段階でSW開発をスタートすることができます。次項の「テーブルトップを活用したロボットシステム開発」で詳しく説明します。
2. SW的な問題をHWへフィードバックする機会がない
自律ロボットの製作には、SW的にロボットを動かしてからでないと発見できない問題がたくさんあります。HWの完成を待ってからSWの開発を開始してしまうと、その時点でもう改善する時間が残されていない事が多々あります。
3. ロボットの仕様についてメカ/エレキ/ソフト間で連携をする機会がない
ロボットの仕様がメカ/エレキ/ソフト全員に共有されるタイミングが非常に遅いため、HWが完成してからSWがそれを引き継ぐときに、SW担当はまずHWの仕様をゼロから理解するところから始めなくてはいけません。これには時間がかかりますし、問題に気がついたとしても改善する時間が残されていない事が多々あります。

チームを運営する上で、誰かが手持ち無沙汰になる状況は避けなければなりません。 ここがマネジメントにおいて最も重要で、チームの成果に大きく影響し、かつ最も難しい部分でもあります。 最悪のシナリオは、手持ち無沙汰を感じたメンバーが、チームに貢献するモチベーションを失ってしまうことです。 自分自身も、初めてJuniorに参加した時に同じ失敗をしました。

では、取り組み方の改善について次のセクションで見ていきます。

ワークフローの改善

図2は、私のチームが2018世界大会優勝した年に、実際に取り入れたワークフローです。 最初のものと比較すると開発アイテムの数自体が増えていて、開発コストはむしろ増しているように感じられると思いますが、これはこれまで引き出せていなかったタスクを引き出せたことによるもので、同じ時間あたりのアウトプットは図1と比較して非常に大きくすることができます。

ここで重要視していることは以下の3つです。

1. SW担当者がロボットの完全なHW完成を待たずに作業を開始できるようにする
稼働率を高く保つ上でまず重要なことは、SW担当者がHWの完成を待つ時間をなるべく少なくすることです。 TUPACでは、SW担当へ引き渡す最初のHWである「テーブルトップ」を作成し、SW担当がHWの完成を待たずに、早い段階からロボットのソフトウェア開発を開始できるようにしています。
2. SW担当者が早期にHWの基幹設計に関与できるようにする
RoboCupは自律ロボットの競技ですので、HWはSWからの要求を満たすように設計されなければならず、そのためにはHW設計が決まるよりも前に、SWがロボットのシステムをテストする時間が必要です。 TUPACでは、まずテーブルトップを最優先で作成し、SW担当者がロボットのシステムをテストする時間を確保しました。その上で、HW設計とSWテストを同時並行で進めながら、SWテスト中に見つけたシステムの問題点をHWの設計がFixする前にシステムに反映し、それらの変更はその都度システムダイアグラムに反映してメンバー全員に展開するようにしました。
3. システムダイアグラムを早期に作成し、メカ/エレキ/ソフトの連携資料とする
システムダイアグラムは、どの部品はどのコンピュータのどのポートにいくつ繋がっていて、それらがソフトウェア的にどう見えるかどうかが明確にわかる、非常に強力な可視化方法です。 TUPACでは、ロボットの実機が完成するよりも前に、システムダイアグラムを作成してメンバー全員に展開しています。加えて、テーブルトップのテスト中にシステムに変更があった場合には、すぐにそれをシステムダイアグラムに反映して、都度メンバーに展開するようにしています。 これによって、ロボットが完成した時点で、メカ/エレキ/ソフトに関わるメンバー全員がロボットのシステムを理解した状態を作ることが出来るため、連携に必要な時間が大幅に短縮できます。

この改善の根幹を成すのが、テーブルトップの作成と活用です。 具体的にどう作り、どう活用するかについて、次のセクションで解説します。

テーブルトップによるロボットシステム開発

テーブルトップは、いわば「ロボットと回路的に全く同じものを、最小工数で作ったもの」になります。 作り方は簡単で、ロボットに実際に搭載するモータ、モータドライバ、センサ、マイコン、PCなどを一式購入した上で、それらをロボットとまったく同じ回路になるように机の上でつなぎ合わせます。 重要なのは、モータやセンサの個数、マイコンのどのピンにつなぐかまで、完全にロボットの回路とピッタリ同じになるようにつなぎ合わせることです。

上手くいくと、テーブルトップで動いたソフトウェアに1行も変更を加えることなく、そのまま完成したロボットを動かすことができるようになります。 つまり、テーブルトップを作れば、SW担当者はHWの完成を待たずにロボットで動作可能なSWを書くことができるようになります。 テーブルトップ作成は部品調達の次に着手できる序盤の作業でありながら、最終的なロボットに搭載できる低レイヤーのソフトウェア開発に着手できる最初のタイミングでもあるため、これの作成はロボットの開発効率と技術的な成熟度を大きく左右すると考えています。

図3はテーブルトップの完成イメージです。 ロボットと同じ構成のデバイスを実際のロボットと同じ構成になるようにつなぎ合わせ、それを机の上に並べてテストできる状態を作ります。 可能であれば、大きめにベニヤ板などの上にテープで固定して、それごと移動できるようにしておくと撤収がしやすいです。机を長い時間使えない場合にも、同じような方法を取ります。

さて、テーブルトップはSW開発を早い段階から開始できるようにするために重要なアイテムですが、他にも回路設計やシステム設計を改善するために非常に有効な活用方法があります。 以下はその一例です。

1. 電気開発において、デバッグを容易にする
ロボットが組み立てられた後は、基板や配線へのプロービング（テスター等の電極を当てて測定すること）が難しくなります。 回路やシステムが未成熟のときには、テーブルトップの状態で様々な箇所をプロービングしながらデバッグをしたほうが、効率が圧倒的に良くなります。 ロボットが完成した後も、テーブルトップとの差分を考慮することで、電気的な問題を発見しやすくすることができます。
2. システム開発において、SW担当者がHWの基幹設計に関与できるようにする
テーブルトップを使ってSWを開発しながら発見した問題、特に搭載する市販品の選定の変更などのメカ設計に影響する部分を、早い段階で発見して設計中のHWに反映することができます。 HWの設計がまだ進んでいない早い段階でテーブルトップを作成すると、このようなフィードバックを無理なく反映できるようになります。
3. 資料作成において、正確なシステムダイアグラムを作成できる
テーブルトップとシステムダイアグラムは、ほぼ完全に1対1のコピーとなる資料です。 チームの全員がシステムを正確に把握しながら開発を進められるように、システムダイアグラムはテーブルトップと常に正確に紐づけながら、最新の状態に更新し続けるようにします。 こうすることで、メカ/エレキ/ソフトの間で議論をする際に、いつもシステムダイアグラムが全員の共通の理解として機能するようになります。

特に1.の電気開発におけるテーブルトップの活用は、メカ/エレキ/ソフト相互に複雑な条件が絡み合う自律ロボットを作成する上では、欠かすことのできない重要な要素だと思います。 テーブルトップをうまく活用すると、ロボットの実機が組み立つよりも前に、おおよその電気的な問題を事前に発見するか、この条件であれば動いていたという「チェックポイント」を作ることができるため、実機が完成した後の電気的なデバッグが大幅に簡素化されます。 では、電気デバッグにおけるテーブルトップの活用について、次で詳しく説明します。

電気デバッグにおけるテーブルトップの活用

一般に、ロボットが組み立てられた後は基板や配線へのプロービング（測定のために測定器の電極などを当てること）が難しくなります。 もしロボットを組み立てた後に電気系のトラブルが起こったとき、それが配線の問題なのかシステムの問題なのか、ソフトウェアの問題なのかを切り分けるのは非常に困難です。

もちろん、各電気コンポーネントや基板の設計や評価の過程で、基板やデバイス単体での動作確認を行わないことは稀でしょう。 しかし、移動ロボットの電気システムとして構成していく過程では、複数デバイスの競合などの統合してからでないと発生しないバグや、熱や振動などのロボットの状態でしか起こり得ない問題などが必ず発生します。 そのとき「テーブルトップでは動いていた」というチェックポイントがあると、その時点との差分から問題の切り分けと特定ができるようになります。

例を挙げるなら、あるデバイスとの通信ができないか不安定なとき、それがロボットに初めて組み込まれる回路であれば考えられる原因は数え切れないほど出てきます。 もしその構成がテーブルトップでは動いていたのであれば、テーブルトップの状態からロボットに組み込んだ状態になるまでの間に付与された条件のうちどれかに原因があると考えることができるため、問題の原因はおよそ以下のようなものに集中してきます。

• ロボット用に新規で作成したハーネスの不良、カシメ、ハンダ等
• ハーネスがロボット内部に通されたことで起こる問題、クロストークノイズ、フレームへの漏電、コモンモードノイズ等
• デバイスをロボットのシャーシ内に組み込んだ事によるデバイスの熱落ち
• その他考えられるテーブルトップと実機の差分、典型的にはバッテリと安定化電源の差分など

このとき更に「ソフトウェアに的にはテーブルトップと一切差分がない」状態にできると、問題をハードウェアのみに限定できて理想的です。 先述したようにテーブルトップをロボットと全く同一の接続で構成しておけば、多くの場合でこれは達成することができます。

開発のタイムラインとチェックポイント

これまでの解説を踏まえて、具体的にどのような進め方で開発に取り組むかを、全体を網羅するかたちで改めて整理してみます。 理解しやすいように、上から順番に取り組むようなかたちに書き起こすと、次のようになります。

部品選定と調達

ロボットを作り始めるにあたって、まず部品選定と調達がないと始まりません。 ここが遅れると、テーブルトップも作り始められないため、すべてが遅れます。 ここに時間がかかっているチームは、まずは危機感を持って、ここを改善しないといけません。

重要なこととしては、センサやマイコンなどの選定、調達、動作テストの段階においては、多少の部品は使わずに捨てられるかもしれないことを覚悟すべき、ということです。 特に経験の少ないチームでは、それだけ無駄になる部品も多くなるので、なおさら部品を買うことに躊躇してはいけません。 組み合わせ次第で動かなかったり、ソフトウェアライブラリの出来が悪かったりして、ロボットに採用しにくいという事は本当によくあることです。 選手だけでなくメンターやサポータも、まずは部品選定と調達がスムーズに進むように協力しないといけません。

テーブルトップの作成

先にも述べたとおり、テーブルトップの作成は部品調達の次に着手できる序盤の作業でありながら、最終的なロボットに搭載できる低レイヤーのソフトウェア開発に着手できる最初のタイミングです。 これの達成は、SW担当者をいかに早くから動かせるかに関わるため、優先して取り組みます。

ハードウェアの担当者（メカやエレキを担当するメンバーを含めたなるべく多くの人）は、電気系のタスクが超苦手か、エレキ担当者が存在しないというケースを除いて、メカのCAD設計などを開始するよりも前に、手作業でのテーブルトップ完成をまず優先すべきと考えます。

システムダイアグラムの作成

テーブルトップが完成した時点で、もうシステムダイアグラムを作成しておくのが良いです。 ロボットの部位ごとにグループ分けされたシステムダイアグラムを作成しておくと、メカ・エレキの設計者が部品の位置や配線の取り回しを把握するのにも役立ちます。

加えて、システムダイアグラムはプレゼンテーションポスターやTeam Description Materialに必ずと言っていいほど掲載される資料なので、早い段階で外部に見せられるクオリティに仕上げておきます。 参考として、図4はTUPACロボットのシステムダイアグラムです。 これはPower Pointで作成しましたが、他にもFigJam, draw.ioのようなオンラインで複数人で共同編集できるツールも有効です。

テーブルトップでのSW開発の開始とフィードバック

テーブルトップが完成したら、SW担当者はテーブルトップにPCを繋いでソフトウェアの開発を開始することができます。 SW担当者は、テーブルトップの上でセンサを読んだりモータを回したりする上で、例えばあるセンサがある条件で複数同時に制御できない事を見つけたり、あるデバイスのソフトウェアライブラリが想定していたよりも使いづらい事を発見したりします。

もし部品の選び直しや繋ぎ変えが必要になる場合には、SW担当者が責任を持ってHW担当者に変更のリクエストをします。 テーブルトップが早い段階で立ち上がっていれば、メカや基板の設計はまだそう大きくは進んでないはずですから、部品の変更やつなぎ直しは適用可能であることが多いです。 ひとつ工夫があるとすれば、メカ設計者はテーブルトップでのテストが完了するまでは、部品の固定や配線などの変更が入る可能性のある部品には触らず、たとえば我々のチームであればクローラのメカなど、メカ的に独立した設計部分などから着手するようにします。

システムFIX、システムダイアグラムFIX、HW詳細設計の開始

テーブルトップが完成し、すべてのデバイスに対してセンサの読み書きやモータの正逆転等が行えることが確認できたら、その時点で「部品選定を確定させた」とメカ設計担当に伝えます。 これを「システムFIX」と呼んでいて「メカ設計者と電気設計者が全てのコンポーネントの詳細設計を開始してOK」という重要なチェックポイントになります。 メカやエレキの設計者は、この時点からデバイスの3Dモデルをロボットに入れ込んだり、配線経路を考えたり、基板外形やコネクタレイアウトを決定したりと、より詳細な設計や議論を開始できます。

システムFix後も、テーブルトップ本体はソフトウェア担当者が引き続き活用します。 モータやセンサ等の入出力デバイスの抽象化が終わったら、センサの条件によってモータを回転させたりという上位のソフトウェアのテストも、可能であれば進めていきます。

さいごに

タスクやスケジュールの管理スキルを習得するのは簡単ではありません。 開発にそもそもどんなプロセスがあって、それぞれがどれくらい時間がかかるのかは、開発をいくつか回した経験がないと分からないからです。

これまで解説した方法は、メカ/エレキ/ソフトがそれぞれ複雑にタスクを同時並行で進めていて、突然取り組むにはそれなりに難易度の高いものです。 私のチームも最初からこの方法にたどり着いた訳ではなく、プロの現場で学んだプロジェクト管理手法などを取り入れて、ようやく確立した手法です。 全体を網羅的に見て、適切に人をアサインしてマネージメントするのには、経験が要ります。

ここまで書いておきながらですが、個人的には、コンテストにはコンテストの取り組み方があり、いわゆる仕事のやり方としてのプロジェクト管理をRoboCupましてやJuniorに適用するのに対しては、かなり懐疑的な立場です。

ただ、ロボットを作るのに機械や電気の知識が必要なのと同じように、複数が協力してものづくりをするためにも、タスク管理の技術が存在します。 まずはその取っ掛かりとして、これからコンテストに参加するチームや、現在参加しているチームが、いい形でこの記事の内容を取り込んでもらえると嬉しいです。