2019年01月20日
MITへの留学中、Engineering Systems Designという授業を受けていました。 海洋上で、電離層の観測装置(Ionosonde)を搭載した無人船(IonosondeとRobotの造語で、Ionobotという呼称がついています)を、13人の学生（学部生11人、院生2人）のチームで設計しました。 これを活用すれば、船舶のGPSの精度を向上できることが期待されています。 他にも、電離層での電波の反射を活用したラジオ通信やレーダーの性能を向上させることもできます。 その授業で大人数のチームで一つの設計を作り上げる上で、体験したこと、思ったことについて書きました。
これはMITの学部生にとって必修であるCI(Communication Intensive)に指定されている授業の一つで、チームを組んだ上で工学的な課題を解決する、というプロジェクト授業です。 その中でもこのEngineering Systems Designは実際の外部のスポンサーからシステムの開発を委託されるところが特徴で、実世界で動くことになるシステムを一から設計することができます。 Ionobotのスポンサーは、リンカーン研究所というMITの研究所です。 このリンカーン研究所はアメリカ国防省に出資を受けていて、自国防衛に関わる技術を主に研究しています。 このような研究所の要請で実施されるプロジェクト、ということで（私も含め）懸念をもつ生徒も多くいましたが、リンカーン研究所では攻撃に使われる技術は決して研究しないので、Ionobotを開発する上で倫理的には何も問題はない、と何度も強調されました。
この授業で扱うのはDesign、つまり設計までですが、次の学期に開講されるEngineering Systems Developmentの授業ではDesignの方で決まった設計を元に、実機の製作を行います。 私の留学は一学期間なので残念ながらその授業は受けられませんが、それでも次のチームがスムーズに製作に入れるように、適切に引き継ぎをする必要があります。
その役割を担うのが、こちらのWhite paperです。日本語で「白書」というと政府が発行する報告書としての意味合いが強いので、この記事ではホワイトペーパーと呼びます。
主任講師のDougは、「その分野の工学的知識がある人なら、ホワイトペーパーを読んだだけで製作ができるような情報が載っている必要がある」と何度も言っていました。 その為には、成果物はHackではなくDesignでないといけない、とのことです。 Hackというのは、付け焼き刃的な作り方、本来は正しくない作り方のことを指します。 ハッカソンのHackと言えば何となく分かると思います。 例えば、「電池にこのモーターを繋いだら回った！完成だ！」のようなものはHackで、Designに昇華させるためには、例えば
のように、全ての部品を工学的に正しく使う必要があります。 Hackだと一日限りのデモで動いてくれても、意図された使い方をされていない以上、いつ壊れるか分かりません。 また、部品一つ一つの型番やそれを選んだ理由、繋げ方なども解説しないと、赤の他人が製作することは難しくなります。
他人ではなく自分が作るのだとしても、他人が読むことを想定した書類を作っておくことが良いと思います。 半年も経てば、なぜそんな設計にしたのか、どう組み合わせるのかなどの細かい話は忘れていってしまうでしょう。 そんな時にこのような書類があれば、考えを追って再び理解することができます。
また、Technical Memoというものもたくさん書かされました。 自分で調査・解析した内容をまとめて、他のメンバーに紹介するための技術的なメモです。 私は発電チームに所属していたので、ソーラーパネルによる発電システムについて調べて、必要なパネルの面積やシステム構成などについてのメモを書いていました。 このメモをもとに意思決定がなされていくので、分かりやすく書くことは非常に重要です。
その時に実践すべき文章構成の順番として、これらの３つの言葉を紹介されました。 また、結論は先に書くことも強調していました。 結論はもっとも重要な情報なので、はっきりと書かれている必要があります。 また、スキミング（概略を理解するためにざっと読み通すこと）でも重要な情報を得られるために、分かりやすい場所に書いておかないといけません。
学期中に３回、Design Reviewというプレゼンテーションの機会がありました。 外部や内部のメンバーに対して現時点での設計を紹介します。 これにはいくつかの意義があって、
NASAのジェット推進研究所(JPL)でインターンをしたこともあるTAが、「この授業のDesign ReviewではJPLの時よりずっと強烈だ」などと言っていました。 実際、Design Reviewで散々に設計の弱点を指摘され、それをもとに何度も全体の設計を見直していきました。
たくさんあるので、ここからはどんどん並べていきます。
Ionobotの13人のグループ内で更に各サブシステムを担当するチームに分けられていたのですが、私は学期途中で各チームのメンバーを入れ替えていた頃に突然、発電チームのリーダーに任命されました。 あまりリーダーをするつもりはなかったのですが、この際やってみるか…と思い、ソーラーパネルでの発電や鉛蓄電池への充電あたりのシステムをまとめていました。 その際、ちゃんとメンバー間で情報共有する必要性を痛感しました。 私が発電チームにもっとも長く属していたので、それまでの議論はよく分かっていたのですが、他のチームメイトは現状は理解していてもその判断の場にいなかったので（その時は他のチームに所属していたので）理由まではあまり分かっていませんでした。 そこで、今に至る過程や、一つ一つの決定の裏にある理由についてちゃんと説明しておけばよかったと思っています。 「全員が同じページにいる」状態にしないと、適切に活動ができません。 私はどうしてもミーティングなどをあまりに簡潔にまとめてしまう傾向があったため、必要な情報を伝えきれていなかったと反省しています。 必要な情報を全て伝えるのは、意外と難しい気がします。 自分自身が話題について深く理解した上で、どの情報が必要なのか、どう説明するのが分かりやすいかを考えながら伝えないといけません。 これについてはまだまだ経験も能力も足りないので、これから模索していこうと思います。
私はともすれば勢いで突っ走り、全部自分の手でやらないと気が済まない凝り性です。
他の人に依頼したタスクが完成すると、「自分だったらこうしたのに…」とか思ってしまいます。
しかし、一人では成し遂げられないことももちろんあるので、人にタスクを割り振る必要は必ずでてきます。
どこまでタスクを指定すべきかも、悩ましいところです。
大雑把に指示する方法もあれば、逐一細かく説明する方法もあるでしょう。
割り振られる人の能力（あまり専門分野でなかったら、細かく説明した方がいいかも）やタスクの内容に応じるでしょう。
私がタスクを与えられる場合、あまりに細かく指定されすぎると、自由度が減ってモチベーションが減ってしまうこともあるので、やる気の維持も考慮すべきでしょう。
これも、今後模索しないといけないところです。（むしろこれが完璧にできれば優秀すぎるマネージャーになれる）
大きなグループになっていくと、アイデアを提案する時は「そもそも良いアイデアか」だけではなく、「いかにメンバーを説得するか」も大事になってくることを実感しました。
その結果、みんながアイデアを出し合い、これらの３つのアイデアからどれを選ぼうか議論を繰り返していました。
一番上は、個人的に一番面白いと思ったのですが、クルクル回る浮きに太陽光パネルを貼り付けたものを大量に用意し、船がひっくり返ることがあっても太陽光パネルは常に上を向く設計になっていました。 真ん中は、flapping foilという部品をつけるアイデア。Flapping foilは波により船体が上下運動を受けると、そのエネルギーを前進運動に変換することができます。省エネルギーで推進することができると期待されていました。 一番下は、双胴船からさらに胴を一つ増やした、三胴船のアイデアです。真ん中の胴体を重くして、水中に沈ませることで、安定性を確保できます。
最終的には一番下のアイデアが選ばれました。船がひっくり返ることはないことを、浮力の計算を通して定量的に証明したり、可動部品が少なくて作りやすいし、壊れにくい点がよかったのだと思いますが、それに加えて提案者のJohnの提案の仕方が上手だったこともあると感じました。 自分の案に対して自信を持って提案して、色んな質問に対して的確に答えられ、必要であればアイデアを微調整しながら、みんなを説得することに成功しました。
説得に成功するために必要なキーワードとして、Ethos, Pathos, Logosがあります。LogosはLogicの語源で、論理的な議論であることを意味します。Pathosは『残酷な天使のテーゼ』の歌詞に「ほとばしる熱いパトス」とありますよね。自分自身が提案に対して情熱を感じている必要がある、ということです。
Ethosは、他の2つに比べてあまり意識されることがありません。 「議論をするに値する人物か」という、話者に対して聴衆が与える価値です。例えばその道の「権威」とされる先生の発言には大きなEthosがあります。 話者の見た目に左右されることもあります。ダラダラの服装を着ている人より、ピシッと正装をしている人の意見の方が聞く価値がある、と感じてしまう、ということです。さらに、身体的特徴も影響を与えることが分かってきていて、「背が高く、声が低く、鍛えている」人の方がリーダーとしてふさわしい、と感じてしまうバイアスがあるようです。 主に男性に対して帰属づけられる特徴なので、この無意識的なバイアスのせいで女性がトップに立ちにくい、ということが起きていると思います。 この無意識的なバイアスとしてのEthosは、議論の優劣に無関係であるべきです。そんな身体的特徴に基づいて良いアイデアが出てくるわけでもありません。 聴衆としてはこのようなEthosを取り除いた上でプレゼンを聞くべきだと思いますが、それでもある程度影響されてしまうかもしれません。
長くなりましたが、自分のアイデアをプレゼンする時は、情熱を持って、真っ当な論理を組み立て、ちょっと良い格好をした上で望もう、ということです。
仲間に自分の作業を検証してもらうというステップ、つまりいわゆるピアレビュー、を踏まないと、時に信じられないほど間抜けなミスをすることがある、と痛感しました。
例えばソーラーパネルの選定。 Datamaranという無人船で使われていたSolbianというブランドのパネルを使うつもりでいて、それのスペックや扱い方などを集中的に調べていました。 しかしTAのJeanと話している中でパネルの話になった時、このパネルの商品ページを見せると「1枚10万円は相当に高級なパネルだ。Amazonで売っている、その1/10の価格のパネルで十分なはずだ」と言われました。 実際、そこまで性能に違いはないパネルが、1枚1,2万円ほどでたくさんあります。 Jeanは以前、別のプロジェクトでソーラーパネルを扱ったことがあったので、それに対する肌感覚を持っていたので、他にも色々と（影ができると出力が相当落ちること、意外と頑丈でデータシートの値より大きく曲げてもすぐに壊れることはない、など）調べていてもすぐには分からない情報を教えてくれました。
他には、ソーラーパネルと電池などをつなぐ、チャージコントローラーと言われる部品の最大電流容量を超えていることを指摘されたりしました。逆に私が、同じチームのメンバーの作業に対して、本人が気がついていなかった見落としを指摘したこともあります。
一人で作業していると、たまにこのような見落としが生まれるのは当然のことです。 それが早めに気がつけた方が、すぐに直せて後への影響もずっと減ります。 自分の調査したり研究した過程は、メモなどにはっきりと残して、たまにお互いの作業を確認することが大事です。
また、ネット検索で何でも調べられそうな今でも、その分野に対する「肌感覚」がないとどう調べていいか分からず行き詰まる、ということもたくさん経験しました。プログラミングやっている人なら特に分かると思いますが、プログラミングする上でも半分以上は検索能力の問題になってきますよね。
その道に詳しい人に早めに相談して、その肌感覚を共有してもらう、という過程を踏むことで、調べるべき方向性も明らかになるし、その後行き詰まった時の相談相手にもなってくれるでしょう。 私が結構苦手とすることですが、新しいことを始める時には大事なステップだな、と思います。 相談する前にある程度は自分で調べておかないと、前提知識が全くない状態で相談することになり失礼だと思うので、ちょっとは勉強してから、ね。
単に技術力があるだけでは大人数が関わる複雑なプロジェクトに関わることはできないなあ、と思いました。 人と関わる能力みたいなところが大事になってきます。
□
IPv6だとSoftEther/SSTPでVPNを経由して接続してくれなかった問題への対処
【ライブレポート】Ado 世界ツアー「Wish」ヨーロッパ最終公演(ドイツ・デュッセルドルフ)に行ってきた
日本の未来は明るい、気がする
進撃の巨人のモデルの街、ネルトリンゲン