学生フォーミュラの組織論（プレゼン）

学生フォーミュラの組織論 from Yuya Yamada

1. 1. 学生フォーミュラの組織論 久留米工業高等専門学校　ロボコン部　ＯＢ 豊橋技術科学大学　自動車研究部　ＯＢ ㈱アドバンテスト 山田　祐也
2. 2. POWERED BY YAMADA 2 やまだゆうやのガイドライン n  名前：山田祐也(26) n  職業：サラリーマンエンジニア2年生 n  趣味：車、バイク、チャリンコ、ジョギング n  経歴 n  久留米工業高等学校　機械工学科 n  ロボコン部 (チームリーダ、部長) n  豊橋技術科学大学　機械システム工学科 n  自動車研究部 (テクニカルディレクタ) n  株式会社TCI (SE,PG) n  ロボコン部 (仮部員？) n  Team SBR (幽霊部員)　 1.  5つの部活を創り、10個の部活に入った経験あり。 2.  ものづくりコンペティションがわりと好き。 REMARK
3. 3. POWERED BY YAMADA Keyword n  士気混在許容組織 n  エースプレーヤー取り扱い説明書 n  士気が低い部員をどう扱うか。　～部活で怠惰は悪なのか～ n  モチベーションエンジニアリング n  モチベーションを創造する仕掛け作り n  モチベーションをマネジメントする n  誰がために目標を設定するのか？ n  目標って何だ？ n  その目標、根拠ありますか？ n  下方修正を恐れるな！ n  教科書に書いていない「開発」のコツ n  設計≠開発 n  技術伝承とデータベースの重要性 n  思いついても形にならないのは何故だろう？
4. 4. POWERED BY YAMADA 1．部活術への誘い n  目的：ディスカッション慣れしてほしい n  メッセージ1：目標管理は大切ですよ(`･ω･´) n  メッセージ2：部活は楽しむもの(＾ω＾)
5. 5. POWERED BY YAMADA ビジネス本が通用しないF-SAE n  【理由】F-SAEに必要なのは。。。 n  仕事術 n  部活術 n  【テーマ】仕事と部活の共通点、異なる点を2つづつ挙げてみよう。 ü まず役割分担(リーダ、書記、タイムキーパ、発表者) ü ゴール設定を明確にする ü 発散系(ブレスト)、収束系(ディスカッション)、報告を明確に分ける。 ü 発表は結論を先、続いて根拠を説明する ü どんなに素晴らしい結論を導こうと、時間オーバーに価値は無い ü 【提案】画用紙上でマインドマップを活用してみてください。 会議のコツ
6. 6. POWERED BY YAMADA マインドマップ活用例① n  議事録 アイディアや情報を視覚的に把握、整理、および優先付けする
7. 7. POWERED BY YAMADA マインドマップ活用例② n  組織図 アイディアや情報を視覚的に把握、整理、および優先付けする
8. 8. POWERED BY YAMADA マインドマップ活用例③ n  プロジェクト進捗管理 アイディアや情報を視覚的に把握、整理、および優先付けする
9. 9. POWERED BY YAMADA マインドマップ活用例④ n  TODO LIST 作成 アイディアや情報を視覚的に把握、整理、および優先付けする
10. 10. POWERED BY YAMADA マインドマップ活用例⑤ n  フォーミュラカーの仕様策定
11. 11. POWERED BY YAMADA マインドマップを活用しなかった例 n  就職の面接対策　～箇条書きで表現する自分の個性～ n  長所 n  好奇心旺盛かな？ n  行動力がある。 n  コミュニケーション能力に長ける n  短所 n  飽きっぽい。口癖が「めんどくさい」 n  集中力が無い。興味が無いと続かない。 n  得意教科 n  数学 n  物理 n  力学 n  不得意教科 n  国語 n  英語 n  ボキャブラリー 箇条書きって、階層構造が分かりにくいし、見辛いよね。僕は嫌いだ
12. 12. POWERED BY YAMADA マインドマップでまとめた例 n  面接で喋る内容のまとめ方 ～マインドマップ活用術～ アイディアや情報を視覚的に把握、整理、および優先付けする
13. 13. POWERED BY YAMADA 情報の整理のコツ n  階層化/構造化 n  例)PCのファイルシステム n  紙ベースでも可能 n  情報量が多いと紙では無理 n  データ、アルゴリズム双方に有効 n  ネットワーク化/ハイパーリンク n  例)PCのショートカット、グーグル先生 n  例)本のしおり n  紙ベースでは無理 n  強力だけどたまに迷子になる n  データベース化 n  例)ファイルにインデックスを付ける n  情報量が多いと紙ベースだとかなり難しい。 n  計算機ベースだと実装及び運用がめんうどくさいけど強力 情報を整理する時は常に上記3点のどれに類するか、意識すべし！ マインドマップが カバーする領域
14. 14. POWERED BY YAMADA さぁ、議論を楽しもう。 n  今回のルール n  議論10分、発表1分、質疑応答1分 ü まず役割分担(リーダ、書記二人、タイムキーパ、発表者) ü ゴール設定を明確にする ü 発散系(ブレスト)、収束系(ディスカッション)、報告を明確に分け、 　適切なメンバー数にする。 ü 発表は結論を先、続いて根拠を説明する ü どんなに素晴らしい結論を導こうと、時間オーバーに価値は無い。 　君の一時間は幾らの価値がある？ ü 【提案】画用紙上でマインドマップを活用してみてください。 会議のコツ 【テーマ】仕事と部活の共通点、異なる点を2つづつ挙げよ！
15. 15. POWERED BY YAMADA ビジネス本が通用しないF-SAE n  【理由】F-SAEに必要なのは。。。 n  仕事術 n  部活術 n  回答例 ü  仕事には報酬がある。契約に基づいて進行する。 ü  部活は無賃金無報酬。契約に曖昧な部分が多い ü ビジネス本に書いてない部活術のヒントを掴もう。 ü 部活と仕事の違いを掴もう。そしてこの活動を将来に繋げよう。 今日のテーマ 【テーマ】仕事と部活の共通点、異なる点を2つづつ挙げよ！
16. 16. POWERED BY YAMADA F-SAEと仕事をリンク n  FSAE経験で仕事に応用が利く例その1 ü ものづくりの上流から下流まで横断的に経験できた。 Ø 前後の工程を意識したものづくりが可能に！ FSAEの財産 　 　 FSAE活動 個人の裁量は とても大きい ü 徹底した分業と特化 ü 個人の裁量は小さい 企業活動 　企画 　営業 　設計 　解析 　製作 　評価 Aさん　　Bさん　　Cさん 設計 解析 実験 密接に リンク 企画 営業 設計 解析 評価 製作
17. 17. POWERED BY YAMADA FSAEと仕事をリンク n  FSAE経験で仕事に応用が利く例その2 経験に裏打ちされた自信 知識から体得へ!! 技術力 営業力 プロジェクト マネジメント プレゼン力
18. 18. POWERED BY YAMADA 社会人になって得た仕事術 n  仕事が出来る≠仕事が楽しい 仕事術 ü  思考のフレームワーク ü  目標設定、スケジューリング ü  etc… ü  各種自動化、データベース化 システム化で余計な思考 を遮断して生産性向上 n 生産性は上がるけど、楽しくなくなるかも？ n どうせビジネス本にいくらでも書いてある n どうせ社会人になったら嫌でも学ぶ ☆楽しむ事を最重要視するF-SAEと相性悪い 教えてあげない(^ω^)
19. 19. POWERED BY YAMADA 部活は楽しむもの n  楽しむために勝つ、そのために頑張る(普遍的な解ではない n  勝つために頑張る(駄目じゃないけどよろしくない 疲れる デスマーチ 人が去る デスマ加速 加速する負のスパイラル 「自分は何のためにF-SAEを頑張っているのか」 常に上位の目的を意識しよう。→じゃないと突然辞めたくなる。
20. 20. POWERED BY YAMADA Q)なぜにF-SAEはかくも素敵なのか。 ANSWER 1.  数多くの成功体験と失敗体験を積み重ねることができる。 2.  組織で動く楽しさと難しさを存分に味わえる。 人は失敗から学び、成功で自信を得る 成長 これほど多くの失敗と成功を積み重ねることができるのはものづくり倶楽部だけ。 Q)では、同じF-SAE経験者でも成長速度が違うのは何故だろう？
21. 21. POWERED BY YAMADA 適切な目標が人を成長へと導く n  【テーマ】君ならどうやってF-SAEの目標を立てる？F-SAEにおいて駄目な 目標設定って何？そして如何にして目標を達成する？ n  【ルール】議論10分、発表1分、質疑応答無し ü まず役割分担(リーダ、書記、タイムキーパ、発表者) ü ゴール設定を明確にする ü 発散系(ブレスト)、収束系(ディスカッション)、報告を明確に分け、 　適切なメンバー数にする。 ü 発表は結論を先、続いて根拠を説明する ü どんなに素晴らしい結論を導こうと、時間オーバーに価値は無い。 　君の一時間は幾らの価値がある？ ü 【提案】画用紙上でマインドマップを活用してみてください。 会議のコツ
22. 22. POWERED BY YAMADA 適切な目標が人を成長へと導く n  目標設定が闇雲　or 下手糞な例(回答例) n  無茶な目標を立てて挫折する ←1番多い例 n  目標を忘れて手段に走る ←好奇心旺盛な奴 n  目標を行動にブレイクダウン出来ない ←初心者に多い n 【テーマ】君ならどうやってF-SAEの目標を立てる？F-SAEにおいて 駄目な目標設定って何？そして如何にして目標を達成する？ n 【ルール】議論10分、発表1分、質疑応答無し Point ! n  自分に対する目標設定、部下に与える目標設定、チームとしての目 標設定はそれぞれやり方、難易度が違う n  ミッション遂行のための目標設定とモチベーションコントロールのため の目標設定はちょっと趣が違う n  部活ではモチベーションコントロールに焦点を当てよう 常に部員へ心地良いストレスを提供しよう！
23. 23. POWERED BY YAMADA 目標設定のヒント　~山田流目標設定術~ n  何回に一回成功するのか n  99回失敗していいのは天才だけ。 [ ] [ ] [ ]失敗体験の数 成功体験の数 困難度 = [ ] [ ] [ ]活動時間 失敗体験の数 人生 =MTBF [ ] [ ] [ ]活動時間 成功体験の数 人生 =MTBS 君は何度挫折したら心が挫けるだろうか？ 短期間に失敗が続くと心が折れるよね？「負け癖」に気をつけろ！ リーダはここを強く意識すること！ ※信頼性工学からのアナロジー、ジョークです n  何日に一回失敗するのか n  何日に一回成功するのか n  部員に1ヶ月に一度は達成感を！
24. 24. POWERED BY YAMADA そもそも目標って何だ？ ANSWER n  「いつまでに」「なにを」成し遂げるか。 超有名な目標管理手法に「ガントチャート」がある。 時間軸が抜けていたら、それは願望に過ぎない What’s GanttChart n  縦軸にタスク、リソース、横軸は時間軸 n  ツール：Excel、 GanttProject
25. 25. POWERED BY YAMADA GanttChart　構築アルゴリズム n  事務的に淡々とガントチャートを作れるようになろう。 【Step1】タスクとそのデットライン、サブタスク、リソースをリストアップ 【Step2】サブタスク間の依存関係を洗い出し、並列化、シーケンスを組む 【Step3】表に落とす。表が破綻してたらサブタスクのボリューム見直し n  例1)実験したい n  タスク：実験、デットライン：2w n  サブタスク 装置Aの準備(2d)/手配(5d)、装置Bの準備(2d)/手配(5d)、 プログラムの準備(5d)、仮説と理論の整理(10d)、 実験(2d)、データ整理(1d)、レポート作成(2d) n  リソース：一人
26. 26. POWERED BY YAMADA GanttChart　構築アルゴリズム n  事務的に淡々とガントチャートを作れるようになろう。 【Step1】タスクとそのデットライン、サブタスク、リソースをリストアップ 【Step2】サブタスク間の依存関係を洗い出し、並列化, シーケンスを組む 【Step3】表に落とす。表が破綻してたらサブタスクのボリューム見直し n  例1)実験したい 装置Aの準備 装置Bの準備 プログラムの準備 仮説と理論の整理 実験 データ整理 レポート
27. 27. POWERED BY YAMADA GanttChart　構築アルゴリズム n  事務的に淡々とガントチャートを作れるようになろう。 【Step1】タスクとそのデットライン、サブタスク、リソースをリストアップ 【Step2】サブタスク間の依存関係を洗い出し、並列化、シーケンスを組む 【Step3】表に落とす。表が破綻してたらサブタスクのボリューム見直し n  例1)実験したい リソース 1 2 3 4 5 6 7 8 9 10 11 12 13 14 タスク 工数 担当 優先度 D eadLine月 火 水 木 金 土 日 月 火 水 木 金 土 日 装置A 2+5d 山田 ☆☆☆ 9 装置B 2+5d 山田 ☆☆☆ 9 PG M 5d 山田 ☆☆ 9 理論整理 10d 山田 ☆ 12 実験 2d 山田 ☆☆☆ 11 データ整理 1d 山田 ☆☆ 12 レポート作成 2d 山田 ☆☆☆ 14
28. 28. POWERED BY YAMADA GanttChart　構築アルゴリズム n  事務的に淡々とガントチャートを作れるようになろう。 【Step1】タスクとそのデットライン、サブタスク、リソースをリストアップ 【Step2】サブタスク間の依存関係を洗い出し、並列化 【Step3】表に落とす。表が破綻してたらサブタスクのボリューム見直し n  例2)設計したい n  タスク 設計開発(モジュール4点、部品4x5=20点)、デットライン=4w n  サブタスク 検討/仕様策定=5人日/module 設計(モデリング/製図)=2人日、BOM=1day、設計検証=2day n  リソース：CAD　x　2ライセンス、3人 リソースのボトルネックであるCADをフル稼働させる Point
29. 29. POWERED BY YAMADA GanttChart　構築アルゴリズム n  例2)設計したい 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 タスク 工数 担当 C AD D eadLine 月 火 水 木 金 土 日 月 火 水 木 金 土 日 月 火 水 木 金 土 日 月 火 水 木 金 土 日 M odule 1検討 山田 - 21 M odule 2検討 田中 - 21 M odule 3検討 清水 - 21 M odule 4検討 山田 - 21 M odule 5検討 山田 - 21 part1-1　設計 田中 PC 1 25 part1-2　設計 清水 PC 2 25 part1-3　設計 田中 PC 1 25 part1-4　設計 清水 PC 2 25 part2-1　設計 田中 PC 1 25 part2-2　設計 清水 PC 2 25 part2-3　設計 田中 PC 1 25 part2-4　設計 清水 PC 2 25 part3-1　設計 田中 PC 1 25 part3-2　設計 清水 PC 2 25 part3-3　設計 田中 PC 1 25 part3-4　設計 清水 PC 2 25 part4-1　設計 山田 PC 1 25 part4-2　設計 田中 PC 2 25 part4-3　設計 清水 PC 1 25 part4-4　設計 山田 PC 2 25 part5-1　設計 清水 PC 1 25 part5-2　設計 山田 PC 2 25 part5-3　設計 田中 PC 1 25 part5-4　設計 清水 PC 2 25 BO M 山田 - 26 設計検証 田中 - 28 リソース
30. 30. POWERED BY YAMADA それでもなおスケジューリングできないアナタ(僕)へ。 n  スケジューリングが破綻する一番の原因は 「サブタスクの工数見積もり精度の甘さ」 ※僕も学生時代は何をやるにも自分の工数は見積もれませんでした。(注1)今も。 ü 自分の工数見積もり精度を向上させる努力を継続する(超重要) 　仕事に取り掛かった時間と終わった時間を全部メモして絶望しよう ü スケジューリングは常に柔軟に見直すこと。(下方修正を恐れない) ü 死守することと妥協して良いことを最初に分類しておく 　(この切り分けが下手でどうでも良いことに工数突っ込む人多い) ü 立てたスケジュールそれ自体に有効期限を設ける 　(状況は常に変わる、半年前に立てた目標なぞゴミ以下の臭い) 対策 ※学生に自分の開発工数を見積もることは絶対に無理。 だから、ガントチャートくらいは事務的かつ迅速に作らねばならんのです。 問題
31. 31. POWERED BY YAMADA それでもなおスケジューリングできないアナタ(僕)へ。 n  学生は1日が24時間あると勘違いしている馬鹿が多い。(注2)僕も n  学生フォーミュラの工数見積もりはdayじゃなくてhour で計算する。 n  自分の工数見積もりより他人の工数見積もりは断然難しい。 当然、組織全体で工数の見通しを立てるのは至難の業 ü 意味不明な楽観視禁止 →「徹夜すればテストまであと１０時間あるから楽勝！」→常勝ではない ü 学生フォーミュラに3h/day以上時間を注ぎ込まない「覚悟」を決める。 遊び、勉強、研究などを犠牲にせず年中バランスよく活動し、リズムを作る。 ü マイルストーン管理を併用する ü 考えながら走り、走りながら考える。←バランスが重要 対策 問題
32. 32. POWERED BY YAMADA 2.組織論 n  これまでのまとめ n  会社と部活は違うから、社会人の言うことをいちいち真に受けるな。 n  目標管理の大切さ 上位の目標を常に見定めながら下位の目標へとブレイクダウンする。 上と下が見えていない人が多いよ。 n  目標=TODO＋期限 n  常に目標を修正し続け、精度を上げる。 n  限られた時間で結論を出す訓練を経験してみた n  これからの話 n  自動車会社と自動車部の組織的な違い。 n  会社よりも部活の方が、ややめんどくさい点をご紹介。
33. 33. POWERED BY YAMADA 部活と仕事の違い　～組織編～ n  理想的組織(みんな士気が高い) n  特に管理する必要は無い ほっとけば才能の無駄遣いと無駄なクオリティー炸裂 立てたスケジュールも勝手に前倒しされる。 現実を直視しろ弱虫！実際にそういう理想的組織は滅多に存在しない。
34. 34. POWERED BY YAMADA 部活と仕事の違い　～組織編～ n  企業流目標設定 n  【目的】業務遂行 n  【アプローチ】 n  時間当たりのパフォーマンス最適化 n  デットラインから遡るスケジューリング n  【下方修正閾値】 n  社員が倒れない程度に厳しく(ブラック企業除く) n  優先度管理徹底(どうでも良いことは容赦なく先送り) Point ! n  賃金と契約あってこそ成立する手法(部活では無理) n  企業でも士気の個人差はあるから、目標設定は必須
35. 35. POWERED BY YAMADA 部活と仕事の違い　～組織編～ n  部活流目標設定術 n  【目的】？ n  【アプローチ】？ n  【下方修正閾値】？ n  【テーマ】どのような目標設定がF-SAEに適しているか。 n  【ルール】議論10分、発表1分、質疑応答1分 ü まず役割分担(リーダ、書記、タイムキーパ、発表者) ü ゴール設定を明確にする ü 発散系(ブレスト)、収束系(ディスカッション)、報告を明確に分ける。 ü 発表は結論を先、続いて根拠を説明する ü どんなに素晴らしい結論を導こうと、時間オーバーに価値は無い ü 【提案】画用紙上でマインドマップを活用してみてください。 会議のコツ
36. 36. POWERED BY YAMADA 部活と仕事の違い　～組織編～ n  部活流目標設定術　(回答例) n  【目的】楽しみながら共に成長する。 n  【アプローチ】 n  モチベーションコントロールを意識する n  簡単過ぎず、難しすぎない挑戦し甲斐ある難易度設定 n  出来るだけ楽しいテーマを選出 n  【下方修正閾値】 n  部員に対して匿名アンケートを実施して満足度調査
37. 37. POWERED BY YAMADA 士気混在許容組織について n  企業と部活では人材の質のバラつきがまったく違う！ n  モチベーションが高い人と低い人の混在した組織の運営は とても難しい。この点は会社運営より大変である。 FSAE活動 企業活動 ü 仕事出来ない奴は給料泥棒 ü エースも居るが、平社員の最 低限能力レベルは意外と高い。 ü 士気のレベルはわりと均一 ü 部活はそもそも「義務」ではない ü 下級生新入部員からエースまで 能力の差が激しい ü 士気のレベルは様々
38. 38. POWERED BY YAMADA 士気混在許容組織について n  モチベーションの低い人の扱いについて。 →既に各チーム議論が尽くされている(と思われる) 1.  やる気ある人だけ集める →夢は寝て見ろ 2.  やる気無い人をクビにして少数精鋭を目指す →デスマーチに片足突っ込んでますよ 3.  やる気を奮い立たせる仕掛けを考える →それが出来たら苦労しねぇ。　本日の最終議論テーマ 4.  「腐ったミカン」エフェクトを最小限に抑制しつつ、 皆で楽しくワイワイガヤガヤやる。 →個人的には現実的な解。創造力は楽しさから生まれる →F-SAEでは実働部員の数はとても大切
39. 39. POWERED BY YAMADA 士気混在許容組織について n  エースプレーヤーとは　(山田定義) どのものづくり倶楽部にも必ず要となるエースが居る。やる 気に満ちてたり、やたら行動力があったり、めっぽう頭良かっ たり、工学のセンスに卓越してたり。色んなタイプが居るが共 通していることは無駄にクオリティーが高いこと。 n  エースプレーヤーの数：大会成績と強い相関 n  実働部員の数：車検通過率と全種目完走率に直結 n  実はエースの方が取り扱いが難しい。 ここの議論は各チームまだ不十分だと思われる。
40. 40. POWERED BY YAMADA 士気混在許容組織について n  エースプレーヤー取り扱い説明書 n  天才タイプ 稀にわき道へ逸れ、目的を見失う。突然飽きて居なくなる恐れあり。 n  秀才タイプ 頼りになるが、他人に努力や成果を「強要する」タイプは度が過ぎる と部活を崩壊させる場合もある　注)社会に出ると成功する 能 力 Skill 高 野生のプロ 鼓舞する エース 委任する 低 ムードメーカー 命令する？ 次期エース 指導する 低い 高い やる気　will ～部活で人を動かす時に必要なことは　強要ではなく、鼓舞～ 実働部員 ココがキモ 実は大切 Will-Skill Matrix
41. 41. POWERED BY YAMADA 士気混在許容組織について n  エースは突然居なくなる!! 【理由1】エースに仕事が集中しちゃう →ワークロード平準化はリーダの勤め！ 【理由2】やる気無い部員に不満を抱えている場合がある。 →やる気が無い事はそもそも悪なのか？ 罪を憎んで人を憎まず。部員に逃げられたら人を恨むのではなく、 モチベーションマネジメントの甘さを再確認しよう。 注)影で一番悩んでいるのもまたエース！皆で支えてあげよう。
42. 42. POWERED BY YAMADA 人を動かすコツ n  指導者に求められる資質 部員に「やるべきこと」を１伝えるために理由/目的、そして 「アツイ想い」を「自分の言葉」で９語れる人間であること。 n [人を動かす力]＝[理屈]×[情熱] u 賃金で縛られる「仕事」 5：5=手順:目的 u やる気を大切にする「部活」 2:8=手順:目的 u 簡単な作業 手順だけでＯＫ　 u 難しい作業 目的を伝えないと迷走する。 u 問題解決能力ある奴 目的だけで十分 u 目的より手段に走る人、好奇心で動く人 目的と理由を徹底的に。 配分の目安
43. 43. POWERED BY YAMADA ３.それでもなお、勝ちにこだわるアナタへ。 n  これまでのまとめ n  リーダーは現状把握と負荷分散、スケジューリングに勤める。 仕事している場合じゃないぞ。 n  エースは気難しい場合がある。エースを手懐けよう！ n  心地よい組織を目指そう。 n  これからの話 n  学生フォーミュラ必勝法 n  教科書には書いていない「開発」とは n  システムは自然に形骸化する
44. 44. POWERED BY YAMADA 無難なマシンを半年前に仕上げて走りこむ。 偉人の格言 モビルスーツの性能の違いが 戦力の決定的差では無いという事を教えてやる。 ☆F-SAE必勝法☆ n  レースで重要なことは 1.  ドライバーの仕上がり 2.  タイヤ 3.  車のセッティング　≠　車のポテンシャル 4.  その他(マスバランス、W/P ratio、電子制御)
45. 45. POWERED BY YAMADA 無難なマシンを半年前に仕上げて走りこむ。 偉人の格言 モビルスーツの性能の違いが 戦力の決定的差では無いという事を教えてやる。 ☆F-SAE必勝法☆ n  これはどのチームも理解はしているけど体得していない 「少しでも良いものを作りたい」という「目先の欲」に負け、技術に走り、 発散する例が後を絶たない。「大会までに」良いモノを作れ Message n  シェイクダウン期日だけは死守すること(ここは妥協しない、覚悟を決めろ) n  目標管理はやっぱり大切です。下方修正を恐れるな。 n  車は部品作るよりも、走らせたほうがよっぽど楽しいよ。 n  エンデュランス完走できないチームに「安全性を語る資格無し」
46. 46. POWERED BY YAMADA 開 発 開 発 学校で誰も教えてくれない「開発」 n  開発≠設計 設計の教科書はたくさんあるし、授業でも教えてくれるけど、「開発」は誰 も教えてくれない。古典的なウォーターフォールモデルを以下に示す コンセプト決定 要求定義 仕様策定 設計 加工 検証 Feedback 泥 臭 ーー 具 体 的 抽 象 的 ü もっとも大切な原点。一年の成果はここで決定 される。妥協せず考え抜き、合意を得ること！ ü INPUT/OUTPUT情報をLIST_UP/整理。コンセ プトを具現化するための「在るべき姿」を決める ü 要求を満たすためのアーキテクチャとそのパ ラーメータを決定。未定パラメタの決定手法決定 ü 仕様をモデルと図面に転写するだけのルーチ ンワークだが、経験が必要とされる。 ü モデルを現物に転写する。経験を必要とする ü 検証方法は仕様策定とセットで予め準備して おくこと(例：テスト駆動開発) これが卒業後の皆の仕事
47. 47. POWERED BY YAMADA 学校で誰も教えてくれない「開発」 n  開発≠設計 設計の教科書はたくさんあるし、授業でも教えてくれるけど、「開発」は誰 も教えてくれない。 n  【ヒント】ソフトウエア工学には「開発」のヒントがいっぱい。 【理由】彼らは50年前から常にデスマーチと戦い続けたため、ソフトウエ ア開発手法は機械開発手法の30年飛んで斜め1rad先を突っ走っている。 仕様書の大切さを知りたければSEに聞け！ n  CAD/CAM/CAE統合環境や3DプリンタなどRapid Prototyping手法 が整備された今、彼ら(SE,PG)から学ぶことは多い。 n  10年後にはアジャイル「ハードウエア」開発も可能になるかもね。 Point !
48. 48. POWERED BY YAMADA 開 発 開 発 学校で誰も教えてくれない「開発」 n  開発≠設計 設計の教科書はたくさんあるし、学校でも教えてくれるけど、「開発」は学 校で教えてくれない。古典的なウォーターフォールモデルを以下に示す コンセプト決定 要求定義 仕様策定 設計 加工 検証 Feedback 泥 臭 ーー 具 体 的 抽 象 的 ü もっとも大切な原点。一年の成果はここで決定 される。妥協せず考え抜き、合意を得ること！ ü INPUT/OUTPUT情報をLIST_UP/整理。コンセ プトを具現化するための「在るべき姿」を決める ü 要求を満たすためのアーキテクチャとそのパ ラーメータを決定。未定パラメタの決定手法決定 ü 仕様をモデルと図面に転写するだけのルーチ ンワークだが、経験が必要とされる。 ü モデルを現物に転写する。経験を必要とする ü 検証方法は仕様策定とセットで予め準備して おくこと(例：テスト駆動開発) これが卒業後の皆の仕事
49. 49. POWERED BY YAMADA 学校で誰も教えてくれない「開発」 n  【要求定義編】 マーケットイン開発は要求定義がキモ。ユーザーはそもそも 1.  ユーザーは自らが何を欲しているか理解していないことがある。 2.  ユーザーは要求仕様書に関わりたがらないことがある。 3.  ユーザーは既にスケジュールと費用が確定した状態で さらに新たな要求を出してくることがある。 4.  ユーザーとの対話には時間がかかる。 5.  ユーザーはレビューに参加したがらないか、参加できないことがある。 6.  ユーザーは技術に疎い。 7.  ユーザーは開発工程を理解しない。 n  プロダクトアウトではそこまで難しくないけど、重要
50. 50. POWERED BY YAMADA 開 発 開 発 学校で誰も教えてくれない「開発」 n  開発≠設計 設計の教科書はたくさんあるし、学校でも教えてくれるけど、「開発」は学 校で教えてくれない。古典的なウォーターフォールモデルを以下に示す コンセプト決定 要求定義 仕様策定 設計 加工 検証 Feedback 泥 臭 ーー 具 体 的 抽 象 的 ü もっとも大切な原点。一年の成果はここで決定 される。妥協せず考え抜き、合意を得ること！ ü INPUT/OUTPUT情報をLIST_UP/整理。コンセ プトを具現化するための「在るべき姿」を決める ü 要求を満たすためのアーキテクチャとそのパ ラーメータを決定。未定パラメタの決定手法決定 ü 仕様をモデルと図面に転写するだけのルーチ ンワークだが、経験が必要とされる。 ü モデルを現物に転写する。経験を必要とする ü 検証方法は仕様策定とセットで予め準備して おくこと(例：テスト駆動開発) これが卒業後の皆の仕事
51. 51. POWERED BY YAMADA 学校で誰も教えてくれない「開発」 n  【アーキテクチャー構想段階編】 ツール：Must-Want Matrix 1.  コンセプトからMust用件とWant用件を列挙する。 Want用件には優先順位をつける 2.  アイディアを列挙する 3.  横軸にアイディア、縦軸に用件を書いた表(Matrix)を作る 条件 要求 1 2 3 4 5 条件1 M UST ○ ○ ○ ○ × 条件2 M UST × ○ ○ ○ ○ 条件3 M UST ○ ○ ○ × ○ 条件4 ☆☆☆ ○ × × × × 条件5 ☆☆ ○ × ○ × ○ 条件6 ☆ ○ × ○ ○ × アイディア
52. 52. POWERED BY YAMADA 学校で誰も教えてくれない「開発」 n  設計パラメータ策定編 n  【背景】自動車は複雑系でトレードオフ多数。還元主義は通用しない n  重量と剛性、どっちを優先しようかな？ n  重心高さと完成モーメント、どっちを優先しようかな n  【対応策】コンセプトとそれを具体化した「仕様」が堂々巡りを断ち切る！ Module A Module A Module A 依存関係 いざ設計を始めても 堂々巡りが始まる
53. 53. POWERED BY YAMADA 学校で誰も教えてくれない「開発」 　 n  【背景】自動車は複雑系でトレードオフ多数。還元主義は通用しない n  【対応策】コンセプトとそれを具体化した「仕様」が堂々巡りを断ち切る！ n  【手段1】振るパラメータを絞るやり方 1.  パラメータ列挙 (強度、剛性、重量、耐久性、etc) 2.  パラメータ整理 (優先度や次元解析で絞る) 3.  Fixするパラメータを決定(コンセプトより決定) 4.  残りを最適化 (ココからが設計) 例)何かをマウントするブラケット。コンセプトは軽さとコスト。要求は100Nの静荷重 1.  ブラケットのアーキテクチャ決定(板金、削り出し、溶接、等) 2.  肉厚と直径という二つのパラメータを断面係数にまとめる、長さと幅という二つの パラメータをアスペクトレシオという1つのパラメータにまとめる、等 3.  Fixパラメータは強度と安全率(仕様として打ち決めしてしまう) 4.  後は加工性や入手製などを考えながら他のパラメータを振って重量を最小化
54. 54. POWERED BY YAMADA 学校でコンセプトの大切さ　 n  【手段2】目的関数作成で全体最適化 1.  パラメータ列挙/整理 2.  目的関数作成 (コンセプトより重みを決定) 3.  目的関数をシューティング 【感想】無茶苦茶難しいです＞＜ n  【手段3】繰り返し設計(スパイラルモデル)で最適化 ソフトウエアでは常套手段だが機械設計では工数的に夢物語 n  【手段4】田口メソッド(品質工学) 【感想】これまた無茶苦茶難しいです(´･ω･`) ココまでと設計検証方法を仕様書に落とす。これが開発 TODO ※TDは部員に対して何がMUSTで何がWANTかを常に即答できるように。 ※設計や加工、検証の際に迷いがあってはいけない。仕様の詰めが甘い証拠 ☆仕様書無き設計は加工図面無しに旋盤回しているようなもので、戻り工数多大 ☆設計検証(実験)は仕様が無いと合否判定基準すら得られない。
55. 55. POWERED BY YAMADA 人はなぜ技術継承がめんどくさいのか。 n  技術継承が上手く回っているチームは少ない。 n  皆知ってる(が、形にならない)技術継承のやり方の例 n  人から人への技術伝承(OJT) n  各種合理化システム、過去の設計資産活用データベース、 各種BOM,設計ルーチン書、自動設計ソフト、設計基準所、構想レ ビュー資料、設計レビュー資料、各種チェックシート、マニュアル、失 敗データベース、etc…. Point ! n 探し始めて10分で出てこない資料は資料じゃなくてゴミ。 過去の財産の整理整頓を怠るべからず。 →であれば、データベースが在れば良い(ただしこれは理想論) Q)ところで「なぜ」過去の財産は化石(持ち腐れ)になるのだろうか？
56. 56. POWERED BY YAMADA やはりめんどくさい技術継承 n  一番悪い例 物だけ作って勝手に満足。財産を何も残してあげない人。注)僕も。 大会後1ヶ月くらいは資料の整理に勤しもう。 n  あと一歩努力が足りない例 合理化システムを作ってみたが、本人しか使わずに部員に定着しない。 n  人間性に多少問題がある例 合理化システムを作った人が作った時点で満足して 「せっかく頑張って作ったのに、何で使ってくれないんだ」 と逆ギレしている。 n  「システムは自然に形骸化する」 ü  技術継承が出来ないチームはエースの卒業と共に弱体化する。 Point ! 意識的に維持する 努力が欠かせない
57. 57. POWERED BY YAMADA システムは自然に形骸化する n  合理化システム(データベース、自動計算ソフト)の作り方 1.  HOP :システムを考案する。 誰でも出来るし、ビジネス本に実例が書いてある 2.  STEP :システムを形にする。 けっこう大変だが、このレベルのチームは多い 3.  JUMP :システムを運営する。 膨大な工数が必要。ここに到達すれば安定して強い n  システムを作るときは使ってもらう「仕掛け」と対にして考えて構築しよう。 n  システムを運営する手間：システムを創る手間＝7：3だと「覚悟」しよう。 取り扱い手順書作成、部員への周知、トレーニング、メンテナンス等 【AA】まずは来週からでも部室に埋まっている埋蔵金を掘り起こしてみては？
58. 58. POWERED BY YAMADA 最後に。 n  F-SAEの楽しみ方 n  ものづくりそのもの。無から有を生み出す感動 n  無限に広がっていく人脈 n  この手のイベント、他大学交流(ロボコンには無い) n  擬似企業体験 n  自慢話(学内展示、近所の祭りへ参戦などの広報活動) ※楽しまないと続かないです。大変ですから。。。 ※他の楽しみ方知ってる人居たら教えてください 見過ごされがちですが、この活動がスポンサー様の 善意に支えられている以上、この上なく大切な事です 夢は逃げない、逃げるのはいつも自分だ。　文責：山田