名称 MIRS2005 開発完了報告書
番号 MIRS2005-REPT-0006

版数 最終更新日 作成 承認 改訂記事
A01 2020.2.12 村山慶将 初版
A01 2020.2.19 村山慶将 青木先生 第2版



目次


    1. 本ドキュメントについて

      本ドキュメントは、ソラシ♬プロジェクトの開発完了報告書について記述したものである。

    2. 発表会・展示会

      発表会・展示会における結果は以下の通りである。
        ・発表会3位
        ・技術評価2位
        ・一回目展示評価1位

      実際の評価を示す。

      fig.1 MIRS2005の評価


      fig.2 投票


      fig.3 全班の評価

      発表会の振り返り

      • 前日に発表会のリハーサルができなかったことが悔やまれる
      • 最低限OBSをスムーズに変更できて良かった
      • 聞き手を意識したラポール形成にしたのでコンセプトの評価が高くなったと思う
      • デモ動画でBGMを小さく流すことで興味を引けたと思う
      • 視聴者から動画の最中に声を挟まれると聞き取りずらかったという評価をいただき事前準備・リハーサルの重要性を感じた
      • 結果を見ると自分たちが伝えたかった最低限のことを伝えられた結果になったと思うので良かった


    3. 全体実現度の評価

      始めに各機能の実現度の評価をtab.1に示す。
      tab.1 各機能の実現度評価
      機能 評価 完成度(%)
      乗車機能 当初の目標っだった30[kg]を載せて走行することができる
      53[kg]の人が乗っっても問題なくコースを一周することができた
      耐荷重は問題ない
      トルクの問題には不安が残るもののバッテリーの充電が最大であれば問題ない
      この機能は目標通りのこと実現できたためが実現度は100%とする
      改善するならばバッテリーにフィードバックをかけると良いと思った
      100
      画像認識ライントレース機能 9割以上コースアウトなくライントレースをすることができる
      バッテリーの充電が少なくなるとコースアウトしやすくなってしまう
      重さの変動に対してゲインを変えることができないため現状30[kg]専用の設定となっている
      バッテリーにフィードバックをかければバッテリーによる問題は解決できると思う
      座席部分に圧力センサなどを用いれば重さの変動に対しても対応できると思う
      今回の動作シナリオでは30[kg]を乗せる場面しかない
      バッテリーがフル充電なら問題なく目標の機能を実現できている
      以上の理由から実現度は85%とする
      85
      緊急停止機能 緊急停止スイッチを押下することによって回路をモータの電源を落とすとともに、プログラムを完全に停止させルことができた
      物理的なスイッチとWebアプリのスイッチの両方で実現できた
      始めにあったスイッチを戻すと暴走してしまう問題も解決することができた
      当初目標としていた安全性が十分確保できたため実現度は100%とする
      100
      音声認識・発声機能 かなり良い精度で音声を認識することができた
      音量を大きくしすぎるとスピーカーの音をマイクが認識してしまう問題が残ってしまった
      この問題は認識する音量のしきい値を最大値に設定したためほとんど問題がないレベルにはすることができた
      この問題を根本的に解決するためには指向性のマイクを使用するか周波数解析を行い特定の言葉をカットすればよいと思う
      この機能は問題点が残ってしまったがほとんど問題がないレベルまで改善できたため実現度は90%とする
      90
      音楽再生機能 音楽の再生を行いながら音声を認識して曲や機能を切り替えるという難しい並列処理を実現できた
      この機能でもスピーカーの音をマイクが認識してしまうという問題が起こってしまった
      この問題に対してこの機能では曲によって音量を細かく設定することで問題がないレベルに改善することができた
      この機能は当初目標としていた動作をしっかりと実現できたため実現度は100%とする
      100
      遠隔操作機能 当初目標にしていたWebアプリからの動作切り替えが可能になった
      Bluetooth通信による動作モードの切り替えもほとんどタイムラグなくできるようになった
      ローカルでの実行だがこれで問題ないと判断し実現度は100%とする
      100
      衝突防止機能 超音波センサで周りの距離を読み取り前方50cm以下または横30cm以下のとき走行を停止するようにできた
      超音波センサの認識もよい
      この機能により走行時の安全性を確保することができるようになったため実現度は100%とする
      100


      次に、全体実現度の評価について、tab.2に技術賞の評価項目を元に全体実現度の評価をまとめたものを示す。
        
      tab.2 全体実現度評価
      評価項目 評価 審査員評価点
      コンセプト このプロジェクトのコンセプトは「注射から注意をそらす」である
      このことはコンセプトとして相手にわかりやすく、つたわりやすいと思う
      発表会でもコンセプトの意味や、なぜ「そらす」のかをしっかり伝えることができたと思う
      92.0
      機能 細かくはtab.1に述べた通りで機能はしっかり完成したといえる
      発表会でも見てもらいたい機能を見せることができた
      しかし、何故その機能を必要としたかを説明していなかった
      84.0
      ユーザー 想定ユーザは5~7歳で体重30[kg]の子ども達などとシステム提案書の段階で考えたものと変更していない
      このユーザの設定はインタビュー調査を行った結果でこれに基づいて機能を定めたので問題はなかったと思う
      しかし、これも発表会でほとんど説明をしていないため、視聴者にはほとんど伝わらなかったかもしれない
      84.0
      ニーズ 今現在新型コロナウイルスの予防接種が大きなニュースになっていることもあり、広く予防接種が広まればそれだけこのプロジェクトの需要は高まると考えられる
      インタビュー調査でも子どもの注射に対する対策には苦労がうかがえた
      社会的な情勢からも普段の苦労からもニーズは決して低くないと思う
      これらのことは発表会でも視聴者にしっかり伝えることができていたと思うが
      新型コロナウイルスの予防接種などもう少し未来を見据えた発表にできたら評価を上げれたと思う
      80.0
      実現度 機能面ではニーズに合わせた機能を高いレベルで実現できたと思う
      しかし、実際に人が乗っている様子を見せることができていないことや、この機能が本当に注射の役に立つのか現場の人から評価をいただいていないことが低評価の原因だと思う
      また、何故この機能を必要としたのかや、そもそものユーザをしっかり伝えていないことによって実現度が測れなかった恐れがあると思う
      自分たちの認識をしっかり伝えることができなかったことが結果的に実現度を示せなかったことにつながってしまいこの評価を下げる原因になってしまったのだと思う
      78.0
      総合評価 自分たちが当初目標としていたMIRSを作り上げることができたと思う
      発表会の場で視聴者に伝えきれなかったことが今回の審査員評価点の結果につながったのだと思う
      審査員の評価点を見てもMIRS発表のプレゼンテーションの最初は良かったと感じる
      最後に現場の方々から評価をいただくことなどをしていなかったことも良くなかったと思う
      プレゼンテーションの内容を見てもコンセプトと機能に重点を置いており、ユーザの詳細やユーザからの評価が少ないため、伝わらなかった部分の評価が低くなってしまったのだと考えられる
      83.6




    4. スケジュール比較

      以下に予定していた開発スケジュールと実際の開発スケジュールを示す。


      fig.4 予定していた開発スケジュール


      fig.5 実際の開発スケジュール


      この表を見ると、

      ①メカ・エレキ・ソフトともに前半の設計段階で予定より遅れが出ている

      ②メカの製作時間はほとんどが外装と設計に費やされている

      ③エレキは前半の基本設計に遅れが出ているもののその後は予定通りに製作できている

      ④ソフトはプログラム作成に全体的に時間がかかっている

      ⑤システム統合を始めてからも予定より多くの時間がかかっている

      ということがわかる。
      tab.3にこれらの反省点をまとめる。
      tab.3 開発工程の反省点
      番号 反省 改善案
      設計段階ではほとんど授業内でしか作業していなかった
      この段階で能力に個人差がありhtmlとCADをできる人が少なかった
      設計書の詰めが甘くレビューがスムーズに通らなかった
      ドキュメント作成などは残業をして行った方が良かった
      前期の時間がある中にhtmlとCADの最低限の技術をhtmlは全員がCADはメカの人全員がそれぞれ身に着けて置くべきだった
      しっかりとドキュメントのプレレビューを受けてからレビューを受け承認をスムーズに得るべきだった
      役割分担を「ドキュメント」「設計」「作成」「手仕上げ」のように分けてしまうと初期段階に遅れが出てしまう
      特に設計を一人にしてしまうとどうしても速さに限界がある
      外装の遅れ自体は開発完了に大きな影響を与えなかった
      メカの人はCADを使えるようにしておき一人が一つの部品の「設計」「作成」「手仕上げ」を全て担当するようにする
      これにあたり「ドキュメント」を担当する人がヘルプの要員として一人いると作業に遅れが出てしまった場合に有効かもしれない
      後半外装は手の空いた人から製作を進めていけば良いと思う
      この対策には全員の認識の共有が重要であると思う
      基本設計の段階で遅れが出てしまった
      詳細設計から製作までは予定通りに進行できた
      結果的に早期にエレキの製作を終わらせ各パートのヘルプとして入ることができたのが良かった
      エレキの詳細設計から開発では残業を少し行い早期の開発完了を目指した
      このプロジェクトではエレキの比重がメカやソフトに比べると低いことからエレキは開発が終了し次第ヘルプに回ることを決めていた
      このような比重が低いものの製作をを素早く終了させ他のパートのヘルプに回ることはMIRS製作に有効だと感じた
      ソフトは環境構築に時間がかかってしまったのが良くなかった
      Pythonなど今まで経験したことのない言語を学習するのに時間がかかってしまった
      webアプリの開発・音声認識・画像処理と今までに経験がないことをしなければいけなかったので時間がかかってしまった
      今回はソフトが2人でエレキからのヘルプが1人の体制で行ったがソフトは作成する機能の数だけ人数がいた方が良いと思った
      経験がないことをする場合は事前学習を授業外に行っておくべきだと思った
      環境構築は授業外に行っておくべきだった
      システムを統合してうまくいかなかった時に多くの時間がかかってしまった
      ねじのゆるみやバッテリーの消耗など根本的なことが原因であることが多かった
      ソフトの統合をしているはずが気が付いたらメカに不具合が出ていたことがあった
      同じことの統合を何回も繰り返し行ってしまった
      システムの統合は始める前にバッテリーやねじのゆるみなど根本的なことを確認してから行うべきだった
      一つのパートの統合をしているときでも他のパートの人を一人は対応できるようにしておくべきっだった
      一人システム統合に最初から最後まで立ち会う人がいると不具合が出たとき早期解決につながりやすくて良いかもしれないと思った

    5. 開発における作業時間分析

      MIRS2005の各班員作業割合

      各班員の作業割合を円グラフにし、以下に示す。


      fig.6 村山 fig.7 榊原
      fig.8 富桝 fig.9 和木
      fig.10 関野 fig.11 内山
      fig.12 菊池 fig.13 位田



      班全体の作業時間に対する各班員の作業時間の割合を円グラフで示す。



      fig.14 各班員の作業時間割合
      tab.4 各班員の工数分析
      工数[人時間] 工数[人日] 工数[人月]
      村山 208.5 26.0 1.3
      榊原 214.5 26.8 1.3
      富桝 133 16.6 0.8
      和木 151 18.9 0.9
      関野 147.5 18.4 0.9
      内山 133 16.6 0.8
      菊池 203.5 25.4 1.3
      位田 150.5 18.8 0.9

      考察

      想定ではPM(村山)、TL(榊原)そしてパートリーダー(内山、榊原、和木)の工数が他の四人に比べとても大きくなるのだが、比較的に差は生まれなかった。
      このことは他の四人がしっかりとサポートし、作業の役割分担をしっかりとした結果であるといえる。



      MIRS2005の作業割合

      各パートの作業割合を以下に示す。





      fig.15 メカの作業時間割合
      tab.6 メカの工数分析
      工数[人時間] 工数[人日] 工数[人月]
      20 21.5 2.7 0.1
      21 24.5 3.0 0.2
      22 60 7.5 0.4
      23 4 0.5 0
      30 91.5 11.4 0.6
      40 169.5 21.1 1.1





      fig.16 エレキの作業時間割合
      tab.7 エレキの工数分析
      工数[人時間] 工数[人日] 工数[人月]
      20 8 1 0
      21 16 2 0.1
      22 21.5 2.7 0.1
      23 1 0.1 0
      31 14.5 1.8 0.1
      41 13 1.6 0.1





      fig.17 ソフトの作業時間割合
      tab.8 ソフトの工数分析
      工数[人時間] 工数[人日] 工数[人月]
      20 5 0.6 0
      21 13.5 1.7 1
      22 34.5 4.3 0.2
      23 6.5 0.8 0
      32 112 14 0.7
      42 105.5 13.2 0.7





      fig.18 各パートの時間割合
      tab.5 各パートの工数分析
      工数[人時間] 工数[人日] 工数[人月]
      メカ 371 46.3 2.3
      エレキ 74 9.3 0.5
      ソフト 277 34.6 1.7

      考察

      このmirs2005ソラシプロジェクトの設計・製造は八人で一人当たり一日8時間行うと17日で終わるプロジェクトだとわかった。
      工数量はメカ > ソフト > エレキの順とわかる。想定と同じだったため良い工数管理ができたといえる。
      工数を分析してみると基本設計・詳細設計と製品作成に多くの時間を使っていることがわかる。
      今回の製作では、製品作成の工数を削減することは難しいと感じた。
      したがって、製品作成をスムーズに進めるには基本設計・詳細設計の工数をできる限り削減することが重要だと感じた。
      製品作成の工数をできる限り削減するにはtab.3で示したような改善案を試してみると良いと思う。
      次回ソラシの製作をするならば基本設計・詳細設計を素早く進め、tab.3の反省を活かして製作をしたいと思う。







    6. 総括

      メカ

      メカ担当として、30kgの重りを乗せて走行させるという目標を達成することが出来たので成功したといえる。 自分たちの班は、全体を試行錯誤をしながら良いものを作っていく方法を選んだので作り直しに思った以上に時間がかかってしまった。 全てのパーツを試行錯誤するのではなく、上段シャーシなどの加工しにくく中心となるようなパーツは一番最初に決めてしまって、 それから周りのパーツを試行錯誤して製作するべきだった。 メンテナンス性については、外装部を荷台にかぶせるような形にしたが、すぐに軽くメンテナンスできるようチャックのようなものをつければよかった。



      エレキ

      エレクトロニクスの製作物は迅速に作成を終え、ソフトウェアと共にテストを進めながら組み立てることができた。 特に配線でトラブルが起こることなく進めることができた。 反省点としては、今回予備の基板を全く作らなかったので、もし不具合が起きてしまった時迅速な対応ができなかっただろうと思う。もしものことを考えると予備の基板を作っていけばよかったと思う。



      ソフト

      詳細設計で作成することになっていた機能は完成度は低いが実現することができ、想定していた一連の動作を行うことができた。 走行時の安全性が低いこと、音声機能の音量が大きすぎることによる音声認識の誤認識などがあり、不安要素が多く実用化は難しい。

    7. 感想

      榊原

      チームリーダーとして一年間MIRSの開発をリードしてソラシ?プロジェクトを完成させることができました。特に、自分はエレクトロニクスの担当だったが、ソフトウェアやメカニクス、ドキュメント管理も把握しながら開発を進めることができたのが良かったと思います。全体的に把握できていたことで冬休み前に外装を完成させ、2週間前には開発を完了できたのだと思います。開発時間が取れない中、様々な指示を出しながら自分のしなければならないことを考えて行動できてよかったです。 この一年間で開発に必要なことを多く学ぶことができました。開発のリードから自分自身の力まで一年前と比べると自分ができることがとても多くなりました。



      村山

      MIRSを通してたくさんのことを学びました。技術的なことでは、3DCAD・三面図作成・ワイヤーカットプログラム・フライス盤・HTML・パワーポイントの応用・発表の知識(ラポールなど)・動画編集などを学びました。こんなたくさんのことを学べて本当に良かったです。HTMLや動画編集は今後もやっていこうと思いました。3Dプリンタなど初めて触れるものもあり、とてもいい経験になりました。PMとなりメンバーのモチベーション管理や空気づくり、作業量の管理などいろいろなことをリサーチし勉強しながら意識し努力しました。メンバーのモチベ&仕事量管理が大切だと知ることができました。関わったすべての方ありがとうございました。



      和木

      ソフトの開発やドキュメントの作成を取りまとめる役であったが、リーダーてきな責任感がなく。ほとんどの作業をりきにエレキのりき任せてしまったのが申し訳ないです。  ソフトとした仕事としてはソフト基本設計書の作成とライントレース機能の作成が一番印象に残っています。  レポート作成が大嫌いなのでソフトの基本設計書の作成はとてもしんどかったです。ここでの設計の段階では自分たちのプログラミングの技術力と時間の制限を考慮して実現が可能なレベルに設計したつもりが、完成はぎりぎりになってしまい、予定通りには進まないなと思いました。  ライントレース機能の作成ではPID制御値を試行錯誤法で設定したのでとても時間がかかりました。重りの有無で機体の重さが変化するのことにライントレースのプログラミングが対応できていないので対応できるようにしたかったです。  DMの仕事としてはオンライン会議の議事録をWebのドキュメントに移す作業が単純作業すぎてしんどかったです。



      関野

      コロナ禍の中での開発というイレギュラーな開発であったが形になり設計通りの動作をしたので一通りは満足出来た。しかし、遠隔操作用のアプリの仕様や言語が二転三転したのは私の知識不足であり、その変更に対応できなかった私の努力不足を今回の開発において実感した。自分のせいで機体の完成度を下げてしまったため申し訳なく感じ、今後の開発においてそのようなことが無いよう自身の知識を深めていきたい。



      位田

      はじめはオンラインでミーティングをしてなかなか話がまとまらなかったり進まなかったりした。またMIRSをやってる感じがなかったが、学校にくるようになってMIRSを触るようになってようやくやっていると思いとこれで間に合うのかという不安があった。しかし、無事に完成させることができてよかった。 機体を今回たくさんいじったが楽しさと難しさがあった。自分としてもっとここをやれば良かったという思いがあるが、それをこれからに活かして行ければいいと思う。



      富桝

      コロナ禍という特殊な環境の中始まったMIRSで、ロボットが完成しないのではないかという不安があったが最終的に完成させることができたのでよかった。 仕事の割り振りやスケジュール管理に反省が残るものの、早い段階で多くのアイデアを出せた点などは素晴らしい。 卒業研究では今年度以上に時間管理や、作業量が増えるだろうからMIRSで学んだことを活かして乗りきりたい。



      菊池

      あまり話したことがない人がたくさんの班でしたがこのMIRSを通して話すことが出来ました。 まだ仲良くなれたわけではないけれど色んな人と関わることで様々な考えを知ることが出来てよかったです。 また、縫うのはとても大変でしたが任された外装製作でミシンの扱い方や上手くなりました。外装が褒められて嬉しかったです






MIRS 2005