はじめに
本ドキュメントは、MIRS1805における開発完了報告書について記述したものである。
完成した機体を以下に示す。
全体の実現度の評価
| 機能 | 評価 | 完成度[%] |
|---|---|---|
| スケジュール | 編集も読み上げもできた。 | 100 |
| 会話 | 0 | |
| 学外からの授業参加 | ライブ配信はできたが、遠隔操作はできなかった。 | 30 |
| 首の伸縮 | 高さの把握ができなかった。 | 70 |
| 登下校 | 移動とあいさつがともにできた。 | 100 |
| 呼ばれた座席への移動 | 移動した先の微妙な位置調整ができなかった。 | 80 |
発表会、展示会の振り返り
発表会結果
| 班番号 | プロジェクト | 得票数 | 得票率 | 順位 |
|---|---|---|---|---|
| MIRS1801 | LibNAVI | 25 | 14.4％ | 3位 |
| MIRS1802 | HERO | 39 | 22.4％ | 2位 |
| MIRS1803 | SCOPE | 22 | 12.6％ | 4位 |
| MIRS1804 | NEWGYM員 | 74 | 42.5％ | 1位 |
| MIRS1805 | ロボメイト | 14 | 8.0％ | 5位 |
発表会の結果（技術賞）を以下に示す。
| 班番号 | Ａ：コンセプト | Ｂ：機能 | Ｃ：ユーザ | Ｄ：ニーズ | Ｅ：実現度 | 合計 | 順位 |
|---|---|---|---|---|---|---|---|
| MIRS1801 | 80.0％ | 77.5％ | 80.0％ | 77.5％ | 78.8％ | 78.8％ | 4位 |
| MIRS1802 | 87.5％ | 77.5％ | 82.5％ | 80.0％ | 88.8％ | 84.2％ | 2位 |
| MIRS1803 | 85.0％ | 80.0％ | 80.0％ | 82.5％ | 82.5％ | 82.1％ | 3位 |
| MIRS1804 | 85.0％ | 95.0％ | 85.0％ | 92.5％ | 92.5％ | 90.4％ | 1位 |
| MIRS1805 | 75.0％ | 77.5％ | 80.0％ | 67.5％ | 72.5％ | 74.2％ | 5位 |
発表会振り返り
発表会で用いたプレゼン資料をMIRS1805 MIRS発表会用プレゼンに示す。
発表会ではプレゼンや展示スペースで何のデモを見せるかについての準備不足が結果に直結してしまい、先生や来場者からの評価を得ることができなかった。
機能では他の班と比べての遜色ないはずであったのに、見せ方の違いでこんなにも差が出てしまうというのがとてもいい教訓になった。
どんな人にどんな機能があるロボットかという部分をもっと押し出さなくてはいけないと感じた。
展示スペースにおいては、スムーズに説明ができず一部の人"だけ"がじっくりとした説明を受ける５０分になり、たくさんの人に説明を行えなかったということを感じた。
役割分担を班でしっかりと行い流れるような展示スペースになると来場者も飽きずに説明を受けられると思うのでこの教訓を来年度以降生かしてほしいと思った。
展示会振り返り
良かった点としてはライブ配信をしながら首の伸縮をして実際に高さが変わることを実感してもらえた。
悪かった点としては各パートの開発が予定より遅れたり、プレゼン用の動画撮影やプレゼンを作成するのに時間をとられたりして展示会まで頭が回らなかった。
その結果ブースの配置や当日の見せ方が前日まで決まっておらず、本番で人をうまく捌けなかった。
さらにスケジュールの変更を実際にやってもらうと変更内容を話す、という機能を見せたところ、周りの雑音のことを想定しておらず耳を近づけないと音声が聞こえなかった。
fig.3よりコンセプト、ニーズに対する評価が低いのは、発表会、展示会ともに実際の現場である学生や先生の意見を聞くのはしたが、あまり取り入れていなかったからだと考えられる。
例えばインフルエンザが治ってから学校に行けない期間にライブ配信を見て助かる、といったようなことを効果的に説明に加えていれば評価が変わってきたように感じる。
スケジュール分析
予定スケジュール表と、実際のスケジュールを以下に示す。
fig.3 予定のスケジュール
fig.4 実際のスケジュール
メカ
予定していたスケジュールと異なり、設計に時間がかかり、全体的に遅れるような形になってしまった。
また可能な作業から行った為順番の入れ替わりが多かった。
エレキ
詳細設計をつめるのが遅くなり、全体的に遅れる形になった。
使用する機器などを変更することもあった為、完成するのは、本番の寸前となってしまった。
ソフト
詳細設計が早く終わりいいスタートを切れたが、どのプログラムも当初の予定である11月以内に終わることができなかった。
走行プログラムは12月以内にできたが、まっすぐ進んで90度曲がってというのを繰り返していたのを時間短縮のために斜めに移動するようにしたため1月までかかってしまった。
首の伸縮プログラムはメカやエレキの製作が終わっておらず、実機での調整が出来なかったので完成が1月になった。
開発における作業時間分析
各班員の作業時間を円グラフとしたものを図として以下に示し、個人については工数分析も合わせて示す。
fig.5 佐々木謙人（エレキ、広報）
全体で最も作業時間が少なく班へなかなか貢献できなかった。その他が１４%をしめ、明確な目的をもって取り組めていなかった時間が長いことが分かる。
実際に、エレキの作業量はメカ、ソフトに比べると少なく何をすればいいのか分からないことがあった。もっと積極的にチームメイトとコミュニケーションをとり、自分にできる仕事を探すべきだった。
fig.6 佐野元康（ソフト、DM）
ドキュメント関連が23%（69時間）、標準機も含めた開発関連が46%（138時間）を占めていた。
DMだったこともあり、班で一番ドキュメントに関わることが多かった。開発も全体の半分近くを占めていたので、班に貢献できたかなと感じる。
fig.7 杉山矢紘（ソフト）
標準機製作23%(69h)、ドキュメント整備・レビュー19%(57h)、発表会準備19%(57h)、開発ソフト15%(45h)となり、ドキュメントレビューの時間が57hと多いことがわかる。
これはコンセプトがぶれソフト開発の仕様が変わったたびに、ドキュメントを書き直したため他の班員より多くなったのが原因と考えられる。
この時間をソフト開発に割り振れれば開発時間が全体の半分以上を占める理想的な形になったと考えられる。
fig.8 鈴木文隆（エレキ）
標準機製作15%、基本設計7%、詳細設計エレキ16%、開発エレキ17%、発表準備13%、その他11%となり、実装する機能がたびたび変更にはなったが、
そもそも実装する機能が少なかったため、エレキの作業のほかにメカの作業を手伝うこともあった。そのためその他の時間や発表準備の時間が多くなったと考えられる。
この時間配分から、エレキの作業時間を基盤の新規作成や、機能拡張に割かなてもよかったと考えられる。
fig.9 長野俊平（メカ、PM）
メカ開発20%、詳細設計メカ13%で、メカとしての活動は全体の3割ほどを占めていて、よかったと思う。
しかし、PMとしての仕事であるミーティングなどの割合が7％と少なかったので、もっと班員との意思疎通を図るために行動すべきだった。
fig.10 増田大勢（メカ）
メカの開発30%(87.9時間)、メカの詳細設計14%(41時間)、基本設計10%(29.3時間)で合計54%(158時間)と全体の50%以上メカの仕事をしており、
メカとして理想的な時間配分で開発が行えた。またその他の5%(14.7時間)が多いように見えるが、その他のうち8時間は発表会当日であり特に問題ないと思う。
fig.11 宮林宏行（メカ、TL）
ドキュメント関連が27%（約81時間）、標準機開発が20%（約60時間）といった開発以外（開発とその他を除く）の割合が73%（約219時間）を占めていた。
逆に開発関連は21%（約63時間）しかない。TLなら開発の時間が50%に近い値のほうが理想的な円グラフだと思われる。
なので、私はどちらかというと、PMに向いているのではないかと考えられる。
fig.12 渡邊昌浩（ソフト）
開発ソフトがほぼ半数を占めており、次に多いのが詳細設計ソフトなので割合としてはよかったと思う。しかし、会話機能と撮影機能の共存ができなかったので、まだまだ開発ソフトに割り当てる時間が多くあってもよかったかもしれない。
また、開発ソフトは主にスケジュール編集機能の作成だったので、音声認識の向上にもうすこし時間を使うべきだったと思う。
fig.13 全体作業時間
fig.14 メカ作業時間
fig.15 エレキ作業時間
fig.16 ソフト作業時間
fig.17 個人別作業時間
上記のグラフから考察できることを以下に示す。
全体の作業割合
fig.17より班全体での作業時間の平均は250時間ほどになった。ただ、佐々木、鈴木、渡邊の3人が平均時間より明らかに少ない事がわかる。これより全体としては仕事の配分が不十分であった、個人としては自発的に開発に参加していなかったと考えられる。
作業割合で見てみるとfig.13より標準機の製作や試験に１番時間をかけていて、その次にドキュメント関連、発表会準備、メカとソフトの開発と続いている。
標準機に時間がかかったのはモーターや基板の不具合が多発し、その度に試験を繰り返しやらなければならなかったからである。
これとグラフからは分からないがシステム提案や基本設計、本番、といったレビューや発表がある度にコンセプトがぶれたこと、さらに班全員で集まって意思疎通を図る機会が少なかったことから
市場調査やプレゼン作成に時間を取られてしまい、本来時間をかけるべき開発や発表会での見せ方について考えることに時間を割けなかった。
時間だけで見ると、1人が1日に8時間仕事をするとして平均250時間なので31日かかることになり、休みの日を考慮すると1ヶ月半で完成したということになる。もう一度初めからやり直せと言われたら、かなり時間を削れると思うので、工数で見ると多いように感じる。
1つ1つでみると標準機は1/4と程よい時間のとり方で、設計や開発は各パートのを全て合わせると1/3を超えているのでこれもよかったといえる。
ただ、ドキュメント、発表会準備、市場調査、システム提案が多かったことに問題を感じた。その他も多いがこれは発表会当日も含まれているので多くなった。ドキュメント、発表準備が多いのはミーティングで話を詰め切れておらず、効率悪く作業することになったからであり、これらの時間を社会実装やミーティングに当てられていたら作業効率や内容が大きく変わったと考えられる。
メカ作業割合
fig.14より、メカ開発に最も時間を費やしたことが分かる。その次に標準機開発とドキュメント関連が多い。
メカでは、顔のパーツなどSolidWorksで設計した部品を3Dプリンタで印刷する作業には時間がかかるため、このような結果となったことが分かる。
エレキ作業割合
fig.15より、標準機開発に最も時間を費やしたことが分かる。その次にエレキ開発、市場調査が多い。
標準機開発や市場調査にかかった時間は他のパートと大差ないので、エレキとしての開発があまりなかったことが分かる。
ソフト作業割合
fig.16より、ソフト開発に最も時間を費やしたことが分かる。その次にドキュメント関連と標準機開発が多い。
ドキュメント作成にかかる時間が多かったのは、全体の作業割合でも述べたようにコンセプトのずれによりドキュメントの内容の変更があったためである。
ソフト開発では、もともとの知識が乏しく学ぶために時間がかかったこと、会話機能の作成が難しかったことによりこのような結果になった。
総括
メカ
我々が作ったMIRS(キリン)はクラスメイトという設定のためデザインにこだわった。
そのため本体完成が発表会間近になってしまい、社会実装まで出来なかったのは真に残念だった。
ただキリンの目玉機構のひとつである首の伸縮機構は完成し、発表会でもスムーズに動作してよかった。
またそれぞれ役割分担がしっかり行えた事で、作業がスムーズに進んだ点も良かった。
エレキ
電源基板に接続する非常停止スイッチやスピーカーや超音波センサーなど、使用する予定だった機器や素子を変更する事になった。
そのため製作期間が終盤にまでもつれ込んでしまった。
また、作成の途中で不具合を起こし進行に遅れを生んでしまったこともその一因だと考えられる。
このような不具合は作成過程で付きまとうものであるため、これを加味したスケジュールを立てるべきであった。
しかし実装する機能は搭載することが出来たので良かった。
ソフト
python（スケジュールや撮影機能）を渡邊、杉山が、C言語（走行）を佐野が担当する予定だったがpythonについての理解が間に合わずpythonを渡邊1人に任せてしまうことになった。
機能の変更やメカ、エレキの製作の都合によりどのプログラムも1月に完成になった。
さらにプログラムができて実行しても動かないことがありその原因が回路にあることが何度かあったのも完成が遅れた理由のひとつである。
mirsの呼び出しを専用のサイトから行うことや遠隔ログインをすることなど実装できなかったこともあったが最低限のことは出来たので良かった。
感想・反省
佐々木謙人
一年間を通してMIRSに取り組み、ものづくりを体験的に学ぶことが出来ました。V字フローは実際に企業でも用いられることが多く、企業での開発をリアルに感じられました。
作業の効率化は生産力を上げるのにとても大切になると思いますが、私はなかなか効率的に作業を進めることが出来ませんでした。
チームメイトの仕事の進捗状況を知り、作業に取り組むことはとても大切なことだと知りました。開発はチームプレーです。それを念頭に入れて、今後に生かしたいと思います。また、今回のMIRSで自身の知識不足、能力不足を強く感じました。
高専生活も残り一年になってしまいました。残された時間で少しでも多くのことを吸収したいと思います。
佐野元康
この１年を振り返ってみると前期は標準機の不具合の連続、後期はC言語の知識が乏しい状態からの走行プログラムの開発、１年を通して期日に追われるといったようなスペックの低さを身にしみて実感した。
特に走行プログラム開発では完成した今ではこれしかできなかったのか、という量だがやっている当時は毎日夜まで書いて消してを繰り返し、班の内外かまわず多くの人に聞いて、という状態だった。
その反面ものを１から作ることの楽しさやグループでの協力することの重要性を知ったこと、苦手だったC言語への耐性がついたことなど得たものも多かった。
最終結果は残念すぎたがこの経験を活かして実技の上達や人との関わり、ものづくりへの意欲を大切にしていきたい。
杉山矢紘
一年間を通して自分一人ではなくチームで何か一つの製品を作り上げるということの大変さを思い知りました。
MIRSでは私はソフト班に立候補しました。
その理由はメカ、エレキ、ソフトの中で一番ソフトが苦手だったからです。
MIRSを作るうえでC言語の知識は授業でやったのである程度はありましたが、Pythonの知識は皆無でした。そのため最初はPythonの勉強をするというところから始めました。
ですが、実用ベースの能力にならず私は走行方面を手伝い、GUI方面を渡邊君に任せてしまったのが申し訳なかったです。
私はMIRSという授業を通して授業内の知識だけで満足せず、自分から新たな言語や知識を吸収することの大切さを学びました。
これからは自発的に学ぶための行動をおこして、自身のスキルアップを目指したいと思います。
P.S. 私の馬鹿ウケ間違いなしの深夜テンションで二徹して作った動画が失笑で終わったのは、心に深い傷を残しました。
鈴木文隆
私はこのMIRSを通じて、企業体系におけるものづくりや開発の困難さを身にしみて実感いたしました。
発案から統合にいたるまですべてにエラーが付きまとい、それらを克服するためにそれまでの製作をすべて見返すこともそう少なくはありませんでした。
またそれ以上に仲間との連携をしっかりと行うことが重要だとも思いました。製作を分担するということは作業を効率化させるだけではなく、作業の食い違いを起こすこともあります。自分が、仲間がどこまで作業を行ったのかしっかり把握していなければ決して間誠意にいたることはなかったと思います。
今回のMIRSではそれを怠ってしまいうまく動作しなかった部分もあった為、この失敗からまたひとつ成長し次なる制作活動に生かしてゆきたい所存です。
最後に、苦楽をともにしたMIRS1805のメンバー、製作にアドバイスを下さったりして導いてくださった先生方。本当にありがとうございました。
長野俊平
私は、MIRSの授業を通じてチーム開発におけるマネジメント役としての仕事の難しさをとても感じた一年間でした。そんな中でも班員は私についてきてくれて感謝しかないです。またTLとして班員の鏡のように働いてくれた宮林には感謝しきれません。
私は１年間を通してプレゼンの難しさ、や私の一年間のマネジメントの反省点は班員の仕事量に大きな偏りができ、働いていない人に仕事をやるように促すのではなく、働いている人と共に働かない人の分の作業をカバーするという、チーム開発であってはならないようなマネジメントをしてしまったことです。
そんな中で、私はチーム開発の１連のプロセスを学ぶことができ、また自分のプレゼン能力の無さなどを気付くことができとてもためになりました。
とにかく我々は、計画性がなく、期日の前日にオールでSNSを用いてグループ通話をしながらプレゼンを作ったりすることはとっても楽しかった。我々の計画のなさにも進化が起きるわけでLINE通話からSkypeに変えることで画面共有をしながらプレゼンを作れることを知ったときの感動は忘れない。
増田大勢
今回MIRSを設計する際、こだわって設計したつもりだったが加工する穴のサイズを間違えるなどの設計ミスがあった。ただなんとか完成したのはよかった。また顔のデザインには特にこだわり、誰でも親しみを持ってもらえるようにがんばった。
ただ自分がかわいいと思って作った顔が、思ってたより評価が良くなかったのは残念だ。また顔を作る際、骨格パーツを3Dプリンターで作りそれ以外をダンボールなどで軽量化&エコを目指したが、結局3Dプリンタで作成してもらったパーツだけで約1kgもあった。
さらに自分が塗装したパーツが失敗してしうなどの災難に見舞われた。また期待してくれた人もいたが、結果は最下位だった。ここに遺憾の意を表する。
宮林宏行
私はこの1年間を通して、たくさんのことを学びました。特に感じたことはリーダーが全体をまとめないと班の中で意見が食い違ってしまうことが多いということです。
私たちはプロジェクトテーマを一度変更しました。そして、報告会を行うたびにコンセプトも変更しました。このことが起こった原因としては、私が上手にまとめられなかったことと、大事なミーティングを行うときに全員が集まらないことが挙げられます。
もう少し詳しく班員に意見を聞けていれば、もう少し早めに取り組めるように班員を呼びかけていれば、といった後悔があります。
私たちの班は何かのイベントがあるごとに2日前、もしくは前日から始めていたので他の班よりも出来が悪い仕上がりになっていると思います。
ですが、夜通しで通話をしながら班員たちと行っていたので、私たちの班の心のつながりはとても強くなっていると思われます。
最初のほうから残業が続いていたので、後半が特別辛いと感じることはありませんでした。
班員の皆さんにはこの1年間迷惑をかけっぱなしだったと思います。こんな私についてきてくれてありがとうございました。この1年間で私はリーダーに向いていないと思いました。
私自身、このような面が知れたので、今後の進路に役立てたいなと思いました。
渡邊昌浩
この一年間MIRSを制作するにあたって、いくつか学ぶことがあった。その中で最も重要であると感じたことが一つある。
それは、技術、知識、実現可能性、実用性を考慮した上で仕様を決定することだ。MIRS1805班では、特に意味もなくキリンというデザインに決定し、授業配信、会話機能等のすでに世の中にある、または不必要な機能を盛り込んだ。
結果、来場した方にSkypeでいいのではないか、Googleカレンダーでいいのではないか、といった意見に答えることができなかった。そして、指定時間に自動で起動するシステムであったがために、発表会当日に見せるものを急遽考えなければならない自体になった。
そして、RaspberryPiの性能を考慮せずに授業配信をしようとした結果、フルHD画質のWebカメラを購入したにもかかわらずフルHDでの配信はできなかった。また、会話機能は音声認識が非実用的なレベルであった。
これらは、仕様決定の段階で事前に防げたと思う。今後、こういったグループでのものづくりをする際には、グループ全体が求めるレベルを無意味に高くしたり複雑にしたりせず、技術、知識、実現可能性、実用性を考慮した上で核となるものをシンプルに一つ決め、既存の製品にはないユーザーのことを考えたものづくりができればと思う。