水曜日, 7月 20, 2016

瞑想による、業務効率改善


瞑想による業務効率改善 from Yuya Yamada

  1. 1. meditation engineering 瞑想による 業務効率改善 Powered by YAMDADA
  2. 2. Life hack? 仕事術?そんなの、クソッタレだ 。 ❖ 瞑想で得られる究極の適度な集中力と、好奇心が あなたの仕事を加速し、人生を捗らせる。 ❖ インターネットには仕事のノウハウが溢れている。 が、「正しく集中する」と比べればどれも瑣末な話題 だ ❖ 仕事術で大事なことはせいぜい「ゴールを見失わない 」くらいのことだ。
  3. 3. 瞑想とは何か。 ❖ ここでいう瞑想とは「心を無にする技術」だ。 ❖ 超能力や電波を受信する力とかでは、断じて違う。 ❖ 意図的に心を無にするスキルがあれば 人生は驚くほど簡単になる。 ❖ 瞑想とはスキルであり、練習して習得するものである 。 ❖ 瞑想は究極の休憩スキル。仕事で無駄に憔悴しなくな る
  4. 4. 瞑想的気分獲得による無我無双 ❖ 心を無にできない状態は、心を掌握したとは言えない 。 ❖ 心配事、余計な好奇心に、集中力を無駄遣いしていま せんか?
  5. 5. 瞑想的気分 ❖ 言葉の定義;瞑想的気分とは。 ❖ 観念奔逸(考えが迸る状態)の真逆な気分 ❖ 連合弛緩(考えが纏まらない状態)の真逆な気分 ❖ 連合弛緩や観念奔逸の程度が社会適合性に問題がある 状態は、何らかの精神疾患病名が付与されます。
  6. 6. 瞑想的気分 ❖ たとえ貴方が十分に健全と言えど、程度の差はあれ 誰しも大なり小なり観念奔逸や連合弛緩がある。 ❖ 自分の意思で心を無にできる状況が瞑想的気分 ❖ この時、観念奔逸と連合弛緩がなくなる。
  7. 7. 瞑想的気分のメリット ❖ 心を無にすると、究極の休憩になる。 寝るより疲れ取れます ❖ その状態から何か(なんでもいい)を始めると、 それに適度に集中出来る。(雑念など湧いてこない)
  8. 8. 瞑想的気分で仕事する ❖ 観念奔逸(雑念)と連合弛緩(考えが纏まらない) から無縁の状態で仕事ができて、究極に捗る。 ❖ 雑念はなくなるが、なぜか好奇心だけは静かに湧いて くるので勉強は捗る。新しい概念の習得とかが超楽。
  9. 9. 瞑想の方法 ❖ 瞑想法;純然たる単なる瞑想 ❖ やり方;ただ単に心を無にする。 ❖ デメリット;超絶難しい。常人には無理。
  10. 10. 瞑想の方法 ❖ 瞑想法;ながら瞑想 ❖ やり方;歩きながら、呼吸しながら、家事など 何かと併用して心を制止する。 ❖ 具体的なことと組み合わせると、心の制止は楽になる
  11. 11. 瞑想の方法 ❖ 瞑想法;複式呼吸の数を数えるだけ ❖ 最も初心者向け。心を制止して呼吸を数えるだけ。 ❖ 心を制止できた呼吸の数が上達の証 ❖ 呼吸は複式の意識的な呼吸とする。呼吸を無意識に任 せない。
  12. 12. 瞑想のコツ ❖ ながら瞑想でながらにやる何か具体的なことは、具体 的であればあるほど簡単に瞑想に入れるが、深くは入 れない。初心者は掃除や家事などのかなり具体的な事 から始めると良い。慣れるにしたがって無意識的にや れる事に切り替えて、最後は呼吸数えるだけ瞑想に持 って行く
  13. 13. 瞑想の前提 ❖ 意識的な複式呼吸こそが一番大事。 ❖ 呼吸がおろそかだと瞑想には入れない。 ❖ 呼吸は練習で上達する。
  14. 14. 瞑想のコツ ❖ 姿勢は超大事。正しい呼吸は正しい姿勢がベースとな る ❖ 印相はなぜか大事。理由は知らん。印は組んだ方が深 く瞑想に入れる。合掌か、法界定印がおすすめ
  15. 15. まとめ ❖ 瞑想は「心を無にする技術」。 スキルなので練習で上達する。 ❖ 観念奔逸と連合弛緩が完全にない状態が瞑想的気分 ❖ 瞑想的気分を維持して仕事すると超捗る。 ❖ 瞑想で獲得する「瞑想的気分」は人生観書きかわるほ どに何もかもが楽になる。
  16. 16. 作者自己紹介 ❖ http://xelvis.blogspot.com/(技術ブログ) ❖ https://www.linkedin.com/in/yuya-yamada-aa0ba711a( linkedIn) ❖ http://zen-engineering.blogspot.jp/(瞑想ブログ) ❖ このスライドは瞑想的気分で30分くらいで作成しま した。

月曜日, 7月 18, 2016

Fiji(フィジー)に行こう!! おすすめビーチリゾート 南太平洋の楽園。

ビーチリゾートってフィジーしか行ったことないのですが
ビチカンバー(beachcomber)が最高だったので
改めて動画で紹介いたします。

確か、Nadiの空港に現地の旅行代理店があって
そこで直接交渉してここにしました。
空港近くのホテルに泊まって、
翌日、バスでデナラウまで移動して、船で向かいました。
格安航空券駆使して、1週間で25万円くらい使ったかなぁ。
レンタルバイクでの本島のツーリングも楽しかったです。



身長163センチの短足がハイシートWR250Rに乗るとこうなる。



WR250Rの足つきが気になる人へ勇気を与えるために

この動画を公開いたします。

日曜日, 7月 17, 2016

オフロードバイク林道探検! 埼玉県名草周辺



林道体験の楽しさがなんとなく伝わるように編集された動画でございます。

大迫力の神輿担ぎ! 館林祭り前夜祭



神輿とは神様の御霊を振ることで、神に活力を与えるのだと

本で読みました。

館林祭り前夜祭の動画です。

本日7月17日は本番ですので是非ともご来場ください!

活気があって、お祭り気分を味わうには最高ですよw



館林市 館林祭りホームページ

土曜日, 7月 16, 2016

理系でフリーランスだなんて、もったいない!!サラリーマンエンジニアという生き方。

雇われエンジニア8年目の社畜の独り言ではございますが
まぁ割と中堅のような立場になってきたこともあり、
いよいよ仕事が楽しくなってきました。

最初はどうすれば楽しい仕事ができるのかよく理解していなくて
くそつまらない時期もありました。
辛い時期もありました。体調崩して休職すらしたことがあります。

とはいえ、8年目ともなるといろいろ学んだこともあり
どうすれば仕事が楽しくなるか!?
という、コツが、なんとなくわかってきました。

これはスペシャリストになりたいあなたへ贈る記事であります。
ゼネラリスト志向の人向けでは、ありません。

僕の主張は簡潔です。
エンジニアとしてスペシャリストになりたいのであれば
大企業のサラリーマンエンジニアこそが至高!!
以上です。

フリーランスはやったことないですけど
さぞや大変だと思います。

なぜか。
雑務から何から全部やらざるをえないからです。

フリーランスになると経営にまで踏み込まざるをえないです。
キャッシュフローを破綻させないよう、慎重な金回しが必要になります。
そんな中で技術的に集中するなんて、おおよそ不可能な話です。
おそらくはキャッシュフローを維持するのが精一杯で
長期的視野に基づいた仕事なんて捗らないでしょう。

ゼネラリストにならざるをえないのが、フリーランス。
スペシャリストには、絶対になれません。

他方、サラリーマンエンジニアだと、どうでしょう。

大企業にいればやりたい放題です。
目先の日銭なんて頭の片隅に置いといて、
数年後、10年後を視野に入れた、投資的な仕事ができます。
日々の業務の中に勉強をねじ込むことだってできます。
(会社が潰れない限り。。。)

やりたい仕事ができないからフリーランスになろう
という判断は大きな間違いだと、僕は確信しています。

まともな大企業ならやりたいことはやりたい放題です。
もし仮にやりたい放題じゃないと思うのであれば、
それはその人の交渉力欠如です。根回しとプレゼンが下手なだけ。
要するにサラリーマンとしてのスキルが足りていないのです。

やりたい仕事は、創れる。
これが社会人を8年やって理解したことです。

ちゃんと企画書作って予算引っ張ってきて、ちゃんと根回しができる人は
分業が進んでいる大企業なら、やりたいことが選択的に、ちゃんとできる。
分業・選択と集中こそが大企業の特権です。それを生かさない手はありません。

この程度の根回しや交渉ができない程度の人材は
エンジニアとして独立するのは大変危険なのです。

やりたい仕事は勝ち取る。
これは僕がいつも仕事しながらフォーカスしていることです。
とにかくやりたいことに関してはきっちり結果を出す。
やりたいことを会社の利益にどう絡めてアウトプットを出すかを考え抜く。
最終的に儲かるんであれば、会社は文句言いません。
会社の体力が続く間にマネタイズできる展望さえあれば。。。
でも、それを周囲にちゃんと説明できることが大事
それさえできれば長期的視野に基づいた仕事ができるようになります。
営利企業で働く限り、マネタイズのことだけは絶対忘れちゃいけません。
ですが大企業であればあるほどマネタイズを先送りすることが可能になるわけです。
要するに大胆なことができます。リスクを取れるんです。
経営危機にでもならない限りどうせクビにはならないんだから
技術的にはリスク取りたい放題でハイリターン狙えるわけです。
なぜなら大企業ならテクノロジーポートフォリオが組まれているからです。
規模が小さいとポートフォリオも組めないので技術でリスクテイクができない。
だからフリーランスになったらさぞやつまらないだろうなと思います。

ポイントはもう一つあります。
目の前の仕事に忙殺されないことです。
ちゃんと業務中の時間は自己管理して、
長期的視野に基づいた投資的な仕事を、
1日1時間でもいいからなんとかして確保するのです。
じゃないとエンジニアとして伸びない。やりたい仕事にたどり着けない。
この程度の時間管理ができないようであれば、
やはりエンジニアとして独立するのは危険だといえるでしょう。

やりたい仕事、楽しい仕事をやりたい。
特定分野のプロフェッショナルになりたい。
であれば、独立して雑務に忙殺されるより、
大企業に所属してプレゼンスキルと交渉力、周囲を巻き込む力を磨いたほうが
結果的に圧倒的に近道なのです。

ゼネラリスト志向の人は、逆にフリーランスを目指すべきでしょう。
なんでもやれてやり甲斐あると思いますよ。
なんでも屋にやり甲斐を見出せるのであれば。。。
ところでエンジニアのあなたは本当になんでも屋になりたいんですか?

僕はスペシャリストになりたかった。
何年もなれなかった。
でもやっとコツが分かってきた。
立ち回り方が、分かってきた。
ポイントは周囲を動かす力。
プレゼン能力とドキュメント作成能力だ。
スペシャリストを目指すのであれば、
否応無しに説明責任が付きまとうのです。
結局その場合一番重要なのは仕事上のコミュ力だ。
そう気付いてしまったのです。
コミュ力はゼネラリストのスキルと思われがちかもしれません
違うのです。
むしろスペシャリストこそコミュ力が問われる、
ということです。

まとめます。


  • エンジニアは自分がゼネラリストを目指しているのかスペシャリストになりたいのか、しっかり自問自答しよう。
  • ゼネラリスト志向なら、フリーランスはあり。
  • スペシャリストこそ、究極のコミュ力が問われる。
  • スペシャリスト志望なら分業せざるをえないので大企業しか選択肢がない
  • 長期的視野で仕事したいなら体力のある大企業しか選択肢がない
  • 技術的に大胆にリスクテイクしたいなら、やっぱり大企業しか選択肢はない。
  • 技術的にやりたいことに集中したいなら大企業がはるかに楽
  • 大企業でやりたいことを勝ち取る程度のコミュ力(企画力、プレゼン力、交渉力)がない状態で、安易にフリーランスを目指すのは危険
  • 仕事は勝ち取るもの。与えられるものではない。

水曜日, 7月 13, 2016

32bit ARM Cortex M3 Arduino Dueによるラパイド実験のススメ


32bit Cortex Arduinoの布教とラパイド実験のススメ from Yuya Yamada

  1. 1. ARDUINO布教 ラパイド実験のススメ
  2. 2. アルゴ検証を ラパイドに。 コンセプト検証に最終形は不要。 イマジネーションを加速させるのは 思考に追従する道具だ。
  3. 3. マイコンに32BITのPOWERを
  4. 4. 8BIT AVRとは違うのだよ • A 32-bit core, that allows operations on 4 bytes wide data within a single CPU clock. (for more information go to int type page). • CPU Clock at 84Mhz. • 96 KBytes of SRAM. • 512 KBytes of Flash memory for code. • A DMA controller, that can relieve the CPU from doing memory intensive tasks. • Hardware divide.
  5. 5. 卓越したペリフェラル • GPIO 53ch →バルブ叩き放題、センサ読み放題, 割り込み自在 • 5 UARTs, 2 TWIs, 4 SPIs ,2 CANs →拡張性無限大 • 8bit PWM 11ch →お手軽にアナログ吐きたい時に便利 • 12bit DAC 12ch →基準電圧さえ確保できれば立派な測定系に。 • 12bit DAC 2ch →ヒーターやDCモータなどの制御に • Mouse / Keyboard →スタンドアロンヒューマンインターフェイスに 。
  6. 6. DETAIL OF PERIPHERALS• USB 2.0 Device/Mini Host: 480 Mbps, 4 Kbyte FIFO, up to 10 bidirectional Endpoints, dedicated DMA • ̶ Up to 4 USARTs (ISO7816, IrDA®, Flow Control, SPI, Manchester and LIN support) and one UART • ̶ 2 TWI (I2C compatible), up to 6 SPIs, 1 SSC (I2S), 1 HSMCI (SDIO/SD/MMC) with up to 2 slots • ̶ 9-channel 32-bit Timer Counter (TC) for capture, compare and PWM mode, Quadrature Decoder Logic and 2-bit • Gray Up/Down Counter for Stepper Motor • ̶ Up to 8-channel 16-bit PWM (PWMC) with Complementary Output, Fault Input, 12-bit Dead Time Generator • Counter for Motor Control • ̶ 32-bit low-power Real-time Timer (RTT) and low-power Real-time Clock (RTC) with calendar and alarm features • ̶ 256-bit General Purpose Backup Registers (GPBR) • ̶ 16-channel 12-bit 1 msps ADC with differential input mode and programmable gain stage • ̶ 2-channel 12-bit 1 msps DAC • ̶ Ethernet MAC 10/100 (EMAC) with dedicated DMA • ̶ 2 CAN Controllers with 8 Mailboxes • ̶ True Random Number Generator (TRNG)
  7. 7. DETAIL OF CORTEX M3 • ARM Cortex-M3 revision 2.0 running at up to 84 MHz • ̶ Memory Protection Unit (MPU) • ̶ 24-bit SysTick Counter • ̶ Nested Vector Interrupt Controller • Up to 17 peripheral DMA (PDC) channels and 6-channel central DMA plus dedicated DMA for High-Speed USB Mini Host/Device and Ethernet MAC
  8. 8. APPLICATION FOR WORK • Measurement • level(voltage) • sampling rate 10kHz-MAX • resolution 12bit(4096) • timing • micros() resolution is 1us • Control • 12bit DAC • 53ch GPIO 65MHz max
  9. 9. ELECTRICAL CHARACTERISTICS • Operating Temperature (Industrial).....................-40°C to +85°C
  10. 10. GPIO DETAIL
  11. 11. GPIO DETAIL

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


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




  1. 1. 学生フォーミュラの組織論 久留米工業高等専門学校 ロボコン部 OB 豊橋技術科学大学 自動車研究部 OB ㈱アドバンテスト 山田 祐也
  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  自分の工数見積もりより他人の工数見積もりは断然難しい。 当然、組織全体で工数の見通しを立てるのは至難の業 ü 意味不明な楽観視禁止 →「徹夜すればテストまであと10時間あるから楽勝!」→常勝ではない ü 学生フォーミュラに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  指導者に求められる資質 部員に「やるべきこと」を1伝えるために理由/目的、そして 「アツイ想い」を「自分の言葉」で9語れる人間であること。 n [人を動かす力]=[理屈]×[情熱] u 賃金で縛られる「仕事」 5:5=手順:目的 u やる気を大切にする「部活」 2:8=手順:目的 u 簡単な作業 手順だけでOK  u 難しい作業 目的を伝えないと迷走する。 u 問題解決能力ある奴 目的だけで十分 u 目的より手段に走る人、好奇心で動く人 目的と理由を徹底的に。 配分の目安
  43. 43. POWERED BY YAMADA 3.それでもなお、勝ちにこだわるアナタへ。 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  自慢話(学内展示、近所の祭りへ参戦などの広報活動) ※楽しまないと続かないです。大変ですから。。。 ※他の楽しみ方知ってる人居たら教えてください 見過ごされがちですが、この活動がスポンサー様の 善意に支えられている以上、この上なく大切な事です 夢は逃げない、逃げるのはいつも自分だ。 文責:山田

火曜日, 7月 12, 2016

自動車開発での本質へのアプローチ TUT-Formulaの技術開発を思い出しながら。


自動車開発での本質へのアプローチ from Yuya Yamada

  1. 1. 日付 自動車開発での本質へのアプローチ POWERD BY YAMADA
  2. 2. 自動車工学の世界 ✤ 動けばいい、のは100年前の話。 ✤ 感性の世界へ突入したのは50年前 ✤ 膨大な技術の蓄積を土台とした多角的技術
  3. 3. TUT-F技術開発 ✤ 統合的ホイルアライメント技術 ✤ マスバランスマネジメント ✤ クラッシュセーフティー ✤ エルゴノミクス ✤ 吸排気系インピーダンスマッチング 及び環境適合性の追求 ✤ エアロダイナミクス ✤ 統合的先端複合材技術
  4. 4. トレードオフと の戦い ✤ まず、人命を掛ける ✤ ダイナミクスこそ全て ma=μF : aを最大化するのがレーシングカー。 m:イナーシャテンソル μ:friction circle management F:トルクデリバリー、ストッピングパワー、 CF ✤ コスト、車重、安全性、環境性能が aに対して全面的にトレードオフ
  5. 5. 多変量との戦い ✤ 自動車設計はマルチパラメタ ✤ 値ではなく、多次元MAP。写像が重要。 ✤ 非定常問題 (レイテンシ、ゲイン、リニアリティ) ✤ 熱、流体、弾性体、粘弾性体、そして剛体の物 理の知識が前提
  6. 6. 自動車のTDとは ✤ 車両の全体コンセプトを管理 ✤ トレードオフ要件を整理する。 ✤ トレードオフ要件に対して仕様 確定する。 ✤ 設計メンバから迷いを取り除く 。
  7. 7. ビークルダイナミクス ma=μF ✤ a:加速度ベクトル 走る、曲がる、止まる。あらゆる機能における、出力となる aで考えれば過渡応答の問題から解放 ✤ m;慣性テンソル、 平たく言えば、車両重量、ヨー、ロール、ピッチの慣性モーメント 設計的にはマスバランス最適化が課題となる。 ✤ μ;グリップ円、統合的ホイルアライメントで決まる 設計パラメタ ✤ F;駆動力(トルクデリバリー)、制動力、CF 設計パラメタ ✤ aを最大化する上で、m、μ、Fが全部干渉するから車は難しい。
  8. 8. レーシングカーの基本機能 ✤ 基本機能 ✤ 入力;舵角、ペダルストローク ✤ 本当の出力;a ✤ 仮の出力;CF、V、ヨーレート
  9. 9. 自動車開発におけるPSPの例 ✤ トルクデリバリー ✤ 統合的ホイルアライメントテクノロジー ✤ マスバランス最適化
  10. 10. m;イナーシャマネジメント ✤ 要求 ✤ 基本的には軽く作りたい。 ✤ 重心を低くしたい。荷重移動を最小限に抑えたい ✤ 慣性モーメントは限界まで削って、固有振動数稼ぎつつサスをソフトにしたい ✤ でも配置すべきコンポーネントがあるし、予算に限りある。 ✤ 対応 ✤ 設計パラメタは軽量化コスト分配とコンポーネント配置 ✤ 重心と慣性モーメントをパラメタとした線形結合評価関数を作って決めた。重みは車両実験で決定
  11. 11. μ;ホイルアライメント ✤ やりたいこと;タイヤのグリップ円最大化、すなわちトレッド面の面圧積分値最大化、と表面温度管理 ✤ 動的なパラメタ;ヨー、ロール、ピッチ、キャンバー、トー、 ✤ 設計パラメタ;ホイルアライメントジオメトリと動的な剛性、アンチローリング特性、固有振動数 ✤ 基本機能 ✤ 入力 舵角とペダルストローク ✤ 出力 aのリニアリティを最大限に確保しつつ、穏やかにサチらせる。 ✤ 誤差要素 タイヤの動力学、路面幾何学、動的なボディ姿勢、アライメント誤差、ボディ剛性、アライメント精度、車高 誤差
  12. 12. μ;ホイルアライメント ✤ 設計の進め方 ✤ タイヤの仕様決め→タイヤの要求アライメント精度を確定させる。 ✤ ボディの6軸での動きの仕様を決める バネ上の6軸の固有振動数決めて、ダンピングで姿勢変化速度を決めて、狙いのボディ姿勢からアンチローリ ング特性を決めて、 ✤ ボディ姿勢に合わせてトーとキャンバーの動特性を作りこみ、 要求アライメント精度で路面にタイヤを立てる。 ✤ ホイルの動的なアライメント精度がそのままメカニカルグリップと直結。 エアロがあると事情はだいぶ違い、車高誤差がそのまま性能に直結する。 ✤ 加速度とスキール音の周波数特性、サスストロークセンサー、タイヤ表面温度で計測評価する。
  13. 13. トルクデリバリー ✤ 基本機能 ✤ 入力;アクセル開度(ペダルストローク) ✤ 出力;a 加速度(トルク) ✤ 基本機能を乱す要素 ✤ 過渡応答最悪、吸排気系インピーダンスマッチング、回転数特性、エンジンto路面のインピーダン スマッチング
  14. 14. ストッピングパワー ✤ 基本機能 ✤ 入力;ブレーキペダル(インピーダンス特性をどうするかはチューニング次第) ✤ 出力;減速加速度 ✤ 基本機能を乱す要素 ✤ 熱交換、pedal to pod剛性とヒス損、コンタミ、雨、
  15. 15. マフラーのPSP ✤ 機能 ✤ 排気の誘導 ✤ 排気の質量流量最大化 ✤ 排ガス浄化、エミッションコントロール ✤ 排気音低減 ✤ やなこと(設計干渉事項) ✤ かさばる、重い
  16. 16. マフラーのPSP ✤ ビークルダイナミクスma=μF;aを最大化 ✤ F;トルクデリバリーのリニアリティ ✤ トルク=ゲイン*アクセル開度 ✤ ところが、T=α*Aとはならず、T=f(t,ω,A) 要するに、過渡応答、回転数依存がある。
  17. 17. トルクは回転数依存性ある
  18. 18. 設計方針 ✤ トルクを回転数方向に積分した 値を最大化するように設計パラ メタを選んだ。 ✤ パラメタは、管の長さ、太さ、 トポロジ、消音コンセプト ✤ 具体的には4−2−1集合、管 を細長くした。
  19. 19. PSP a最大化 エネルギ回収 ターボ ペルチ ェ 等長マニ 背圧低減 インピーダンスマッチング 独立マニ パイプ式 マニ 抜ける サイレンサ 排気誘導 排気干渉低 減 共鳴過給 慣性過給 流速最大化インピーダンス 境界面管理 音速管理 タコ足 サーモテープ 2重排気管 断面積最適化

pythonで何ができるのかを簡単に紹介します!!


Pythonic world from Yuya Yamada

  1. 1. PYTHONIC POWERED BY YAMADA
  2. 2. YAMADYNAMIC PROGRAMING LIFE OF YAMADA ▸小学生 計算機の勉強を始める。インベーダーゲームのコンパイルを通して感 動した。 ▸中学生 ロゴライターでプログラミングして遊んでいた ▸高専 16歳でC言語始める。19歳でLinux上で超電動モータのリアルタイム 制御に成功 ▸大学 数値計算大好き。多数の計算コードを作成。研究はロボットリアルタイ ム制御コード書いていた。ベンチャーでハンドラのシーケンス書いてた ▸大学院 研究はC++でVision robot, ベンチャーでCAD作って儲けた。 ▸社会人 arduinoとC#で遊んでいた。ruby少し写経、最近pythonがマイブーム
  3. 3. テキスト 素人なりにC, C++, C#, RUBY, MATLAB,SCILABを 俯瞰して。 ▸道具超重要。チューリング完全ならなんでも良いというわけ ではない。 ▸複雑性は悪。 ▸手に馴染む道具の定義 ▸エンジニアリング工程の99%は非創造的作業時間 ▸計算リソースは金で買う、エンジニアの一秒は単価高い ▸そもそも本当にそんなに計算資源必要か!?
  4. 4. テキスト なぜ今PYTHONを選ぶべきなのか ▸可読性が高い=コラボレーションできる ▸簡潔に書ける=手に馴染む道具となりうる ▸コミュニティが活発=ライブラリの発展性に無限の可能性 ▸C言語拡張で基本的にやれることに制限がない。
  5. 5. テキスト PYTHONに苦手なこと。 ▸Cと上手に連携させないとハードウエアは叩けない ▸SMP環境でマルチスレッドしても高速化はできない ▸所詮はスクリプト言語
  6. 6. テキスト C・C++を使ってはいけないシチュエーション ▸リアルタイム性が要求されていない、十分な計算資源があ る ▸テキスト処理 ▸オブジェクト指向を駆使せざるをえないほど複雑なこと ▸コンテナにアクセスしまくる。 ▸チームでの大規模開発。
  7. 7. テキスト C・C++を使うべきシチュエーション ▸リアルタイムアプリケーション ▸計算機のお勉強。 ▸限られた計算資源を最大限引き出す。 ▸他の言語を学習するのが面倒くさいため、一つで全部やりた い ▸10年後、C言語はアセンブラ言語のような扱いになるだろう
  8. 8. テキスト 努力と成果のSCALABILITY 努力 OUTPUT 凡人 まぁまぁ 目指す姿
  9. 9. テキスト 努力に対して、成果がサチる理由 ▸車輪の再発明に明け暮れる ▸スケーラビリティーを蔑ろにして複雑性を放置する ▸創造的なことに時間を割けていない ▸可読性を蔑ろにしてコラボレーションを阻害する
  10. 10. テキスト 努力に対して、成果がSCALABLEな人 ▸仕事を創る人 :創造的な時間を大切にしている ▸仕掛けを仕込む人 ▸コラボレーションができる人 ▸アウトソースしちゃう人
  11. 11. WHAT IS
  12. 12. テキスト PYTHONを一言でまとめ る ▸ 可読性を重視した高水準汎用プログ ラミング言語。 ▸ 全てがオブジェクト ▸ 動的型付け、ガベコレあり ▸ ワクワクするライブラリ ▸ マルチプラットフォーム ▸ 勉強がしやすい。
  13. 13. テキスト とりあえずアナコンダ入れとけ
  14. 14. テキスト 画像処理 ▸>>>import cv2 ▸画像処理でやりたいことはとりあえずなんでもできるはず 。
  15. 15. テキスト MATLABの代替として ▸>>>import Scipy ▸統計、最適化、積分、線形代数、フーリエ変換、信号・イ メージ処理、遺伝的アルゴリズム、ODE (常微分方程式) ソ ルバ、
  16. 16. テキスト R言語やエクセルの代替として ▸import pandas as pd
  17. 17. テキスト マスマティカの代替として ▸>>>import sympy
  18. 18. テキスト GNU PLOTの代替として ▸import matplotlib
  19. 19. 応用先 人工知能 ▸$ pip install https://storage.googleapis.com/tensorflow/linux/cpu/tensorflo w-0.5.0-cp27-none-linux_x86_64.whl ▸import tensorflow as tf
  20. 20. テキスト 対話環境 ▸$ ipython notebook

サラリーマンエンジニアがこの先生きのこるには。


ゼネラリストか、スペシャリストか。 from Yuya Yamada


  1. 1. サラリーマンエンジニア が この先生きのこるには。 株式会社アドバンテスト やまだ 1
  2. 2. profile 佐賀生まれ、群馬在住、32歳 好き 勉強、旅行、くるま、バイク、 インターネット、プログラミング、 電子工作、プリキュア、 嫌い メモを取ること、人参、キュウリ 2
  3. 3. specific area of expertise 機械工学全般 画像処理、ロボティクス、 統計学、計算物理学、最適化の数理、 tolerance design, 3
  4. 4. なにをやってたか 久留米高専 ロボコン部 豊橋技術科学大学 自動車研究部 株式会社アドバンテスト 4
  5. 5. 話の枠組み サラリーマンエンジニアとしてキャリア形成をする上で、 気に留めておいて欲しい「ヒント」を大げさに提示する。 keyword Generalist / Specialist Outsourcing / template Output scalability
  6. 6. メッセージ ゼネラリストと、スペシャリスト、君はどっちを目指したい? 6
  7. 7. 優秀なサラリーマンエンジニア? 情熱がある。夢がある。 具体化できる力がある。 チームでコラボレーションができる。 僕が独断/主観で考える≠企業が欲しい 僕は上が重要だと信じている。 ブラック企業は下が重要だと思ってる? 君はどう思う?? 7
  8. 8. ここが変だよ日本企業。 〜やたらコミュ力が重宝される〜 過度にコミュ力やプロマネ力、 はたまた経営力なんかをエンジニアに要求(強要)する企業は だいたいブラック。気をつけよう。 仕事もくだらない調整ばっかりで忙殺。 8
  9. 9. ブラック企業の定義 見渡す限り何でも屋。スペシャリスト不在。 ドキュメントやシステム化が疎か コミュ力無くして仕事が回らない、腐った組織 明確な目標を示せない管理職 明確なビジョンを示せない経営者
  10. 10. なぜ日本は負けるのか。 経営者と管理職が無能 ゼネラリスト気質のエンジニアばかり採用、 なんでも屋が重宝される 全員管理職目指して誰もコアな事ができなくなり すべて中途半端。結局効率悪い。 有能な何でも屋がごり押しで仕事を進めてしまうので、 問題意識も自浄作用も無い。いつまでたっても非効率。 現場力がぁぁあ云々で理想を追いかける気もない。 10
  11. 11. ブラック企業はスペシャリストを軽視する。 組織として、スペシャリストをハンドリングするスキルが無い。 11 なぜか。
  12. 12. 日本でスペシャリストを目指すのが なぜこんなに難しいのか。 日本企業はゼネラリストを求めている。 ゼネラリストからスペシャリストへの転向はけっこう難しい。 12
  13. 13. 世界で通用する人材はどっち? 日本で通用するゼネラリストには、やればなれる。 ただし、過当競争気味。 世界で通用するゼネラリストになるのはけっこう大変。要才能。 世界で通用するスペシャリストになるのは、比較的簡単。 情熱と専門スキルがあれば良い。 戦略さえあれば比較的簡単です。 13
  14. 14. コミュ障に未来はあるか Ans. ある。 但し、ブラック企業にだけは行くな。 コミニュケーション能力=期待に応える力 応える≠答える。 コラボレーションがスムーズに進めば良い。
  15. 15. message スペシャリストを目指すなら 今、決断する。 15 初動が肝心です。
  16. 16. それでもゼネラリストを目指す貴方へ ゼネラリストの代わりは世界中にいく らでもいます。そこで質問です。 16 Question: 貴方の仕事のアウトプットは賃金1/10の 外国人労働者10人に勝てますか? 勝てないなら、そのうち仕事がなくなります。 世界がフラットになった頃、また仕事にありつけます。
  17. 17. 具体的解決策の例 競争力のあるスペシャリストになる。 Outsourcingする側に回る。 内需型産業で生きる。
  18. 18. 言葉の定義 Outsourcingを、 する人 仕事をハンドリングしている人、主導権を持っている人。 受ける人 その道を極めたスペシャリストや 「される人」より低賃金な労働者 される人 結果的に仕事を失う人。
  19. 19. outsourcingされる側 Specialistとして、代替不可な、競争力のある core competence を持っていない。 Generalistとして、外国人労働者の10倍の成果を出せない。 主導権が無い。運命は他人に握られている ゆるやかな死と悲惨な未来 アウトソース不可能な仕事なんて無い。油断禁物。 常に自分がどっち側に立っているかを意識しましょう。
  20. 20. outsourcingの手順 要点/課題を整理して テンプレ化/システム化して 適切な人/組織を探して スペシャリストである/自分より頭がいい人 自分より単価の安い ビジネス化して、お願い(outsource)する。
  21. 21. outsourcingのスキル 1. ビジネス感覚 2. ルールや基準を敷ける。 3. 仕様書(love letter)を書ける 4. ツールを創れる 5. データベース/最適化 2-5がtemplate化
  22. 22. 努力と成果のScalability 努力 output 凡人 まぁまぁ 目指す姿
  23. 23. 努力に対して、成果がサチる 人 頼まれたことしかやらない。 なんでも抱え込んでコラボできない。
  24. 24. 努力に対して、成果がscalableな 人 仕事を創る人 仕掛けを仕込む人 コラボレーションができる人 アウトソースしちゃう人
  25. 25. outsourceされないspecialist core competence を持っている。 自分でやるべきでない事を把握してて outsourceする力を持っている。 努力と成果がscaleしない事は 全部お願いして やりたい事に集中しよう。
  26. 26. 楽しく仕事をする 仕事を選べる立場を勝ち取る。 目標のピラミッドツリーと仕事のストーリーを創る。 やりたい事に集中する。 やりたくない事はお願いする。 10人分の成果を一人でハンドリングする。
  27. 27. メッセージ 全体を俯瞰しよう。 やりたい事に集中するための努力を惜しまない。勝ち取れ。 成果と努力がスケールしない事はやらない。頼め。 一人で抱え込まない。頼れ。
  28. 28. 最後に。 情熱と好奇心が一番大切な才能 楽しくないと、成果は出ない。 楽しい仕事は勝ち取る。 当事者意識が無い人は何やっても駄目。 以上、全部極論です。コツコツ頑張ってください。 なんだかんだ基礎と下積みは超大事。

日曜日, 7月 10, 2016

すべてはBOMになる。ハードウエアエンジニアに大切なこと。

BOMとは、いわゆる部品表のことだ。

ハードウエアエンジニアの最重要アウトプットとは何か。
この問いにはそれぞれ色々な答えがあると思う。
仕様書、回路図、図面、あるいはCAD上の構想図かもしれない。
だが僕は、BOMこそが最も大切なアウトプットだと思う。

製造も、購買も、営業も、すべてはBOMをベースに動く。
BOMはあらゆることを管理することができる。
価格(コスト)、数量、リードタイム、などなど、
リストの項目に何を載せるかは、設計者のセンスだ。

マスターとなるBOMに網羅的に情報を載せることで、
あらゆることが検索、フィルタリング、可視化できるようになるのだ。
製品に対して横断的に分析するにはまずBOMから始まるといっていい。

この時、重要なことがある。

  1. できるかぎりMECE(漏れなく重複なく)にリストを作ること
  2. 極力機械的に自動的に生成すること(手打ちしない)
  3. それと徹底した一元管理だ。

ここでいう一元管理とは、
マスターとなる情報に仕上げることを徹底的に意識し、
複数のリストを作らないことである。
止むを得ず複数のリストになってしまう場合は
リレーショナルデータベースとして機能するように配慮しなければ、実用的なBOMとはならない。

BOMはいくらでも拡張できる。
設計にBOMを徹底的に生かすと、設計の品位は圧倒的に卓越したものとなる。
僕はここで仕様・構想段階の、上流でのBOMの活用を提案する。
一方エンジニアは往々にしてBOMは下流に対して作るものという思い込みがある。
僕の主張は、上流、主に検討段階でBOMがものすごく役に立つ、
だから極力、上流の段階でBOMに落とし込み、開発中も常にメンテしろ
ということだ。

僕は機械設計技師なのでメカトロ系を例にして説明する。

設計で使うBOMそのものはCSVでもエクセルでもCAD組み込みの表でもいい。
リッチなリレーショナルデータベースを使っても良い。
僕はエクセルで十分に満足している。スプレッドシートで十分だ。
検索、ソート、フィルタリング、ができ、合計が分かればそれでいい。
ポイントは合計だ。エクセルでいうところのSUM()さえ使えればいい。

BOMの項目に設計パラメタを入れるとき、重要なことがある。
足し算に意味のある項目を入れることだ。
大学で微分積分やら複雑な代数学を学んだ技術者に取って
たかが足し算にどれほどの意味があるのか、疑問に思うかもしれない。
だが複雑かつ非線形でマルチパラメタな設計を
足し算に落とし込むその過程こそが
本質を見極める上で、最も大切な思考過程であり、
大学で学んだ数学や物理の知識を駆使せざるをえない、
クリエイティブな工程だ。

あらゆる最適化テクニックにおいて、パラメタを削って式を閉じる際に
評価関数を立てるが、
加重和、要するに線形結合の形をとる場合が多々有る。
また大学で線形代数を学ぶ意味の一面も、ここにあると言っていい。
本質となるパラメタは、往々にして足し算で表現できるのだ。
大学で学んだ各種数学は、そのパラメタにたどり着くために重要となる。
幾何学、写像、変換を駆使すれば、たいていのパラメタは
足し算可能なパラメタに変換できるのだ。

まず、一般的にBOMに乗る項目を眺めていこう。
コスト、利益、価格など、貨幣価値に換算できるものはもちろんBOMに乗る。
議論の余地もなくこれらは足し算可能な項目だから、
BOMに乗せるのが合理的だ。
リードタイムや納期、工期などの時間の変数もBOMに載せることは多い。
この場合、並列化できないものを抽出できるようにBOMを組み、
ボトルネックや積み上げ工期をフィルタリングでアウトプットできるように組む必要がある。
設計の面では、重量や体積は足し算可能な、BOMに乗せても自然なパラメタだ。

もう少し設計や開発に踏み込んでBOMを眺めてみよう。
僕は機械設計技術者なので例は機械関係となる。

まず、剛性はどうだろう。
技術者なら分かると思うが、足し算が成り立つパラメタではない。
部品が増えれば増えるほど、剛性は減るのだ。剛性をBOMに盛り込むのは不自然だ。
また、剛性は基準部品の基準部位に対してどの部品が撓むのか
と言う情報にも辿り着けなくてはいけない。
そこでまず、数学を使って剛性を足し算可能なパラメタに変換しよう。
とは言ってもさして難しい話ではなく、
逆数を取ってコンプライアンス(柔らかさ)で考えるのだ。
電気回路でもよくあるが、逆数を取れば足し算可能になるパラメータは数多い。
インピーダンス(フローとエフォートの割り算)が関係してくる場面だ。
コンプライアンス、要するに柔らかさは足し算可能なパラメタだ。
だから部品表にコンプライアンスの項目を追加し、積算可能な形にすることは意味のあることだ。
次は、製品の中で、どこからどこまでの剛性に興味があるかを抽出する必要がある。
この時、メカループが定義され、リストの項目に明示してあり、
メカループ毎にコンプライアンスが抽出できるようになっている必要がある。
ここまで来たら、フィルタ一発でコンプライアンスを積み上げ計算し、その逆数を取るだけで剛性が一発計算できる環境にたどり着けるというわけだ。

強度もまた足し算していいパラメタでは、ない。
最弱リンク仮説に基づくのでリストに対して意味のある計算はSUM()ではなくMIN()だ。
ちょっとBOM化するのは少し魅力がないが、乗せておいて損はない。

MTBFの逆数は非常に重要な、BOMに載せるべきパラメタの一つだ。
MTBFそのものは足し算に意味は無い。

誤差はどうだろう。
これまた単純に和を取っていいものでは無い。
だがこれもメカループでのフィルタリングができるならば
数学で和に変換できる。
標準偏差の次元では足し算できないが、分散は足し算できるのである。
これを分散の加法性と言う。
分散の加法性は中心極限定理から説明することもできるし、
分散が2次のモーメント量という点からエネルギーに類似したパラメタとして
足し算が可能であるという説明もできる。
BOMに分散を盛り込み、フィルタ積算した値の平方根を取れば
それがユニットの誤差推定値となりうるのだ。

強度、剛性、誤差を例として挙げたがその他幾何学的なこと、要するに寸法関係も
ちゃんとフィルタで抽出できれば意味のある演算と成り得る。
メカ関係の設計パラメタをマスターBOMで管理する際に重要なことは
とにかく興味あることに対してメカループが定義され、
抽出可能な状況になっていることだ。
何がメカループなのかを考え抜くことそのものが
設計であると僕は思っている。

もっと一般化した話をすると
そもそもあらゆる機械は、
基本機能が関数の入出力としてリニアに定義されるべきなのだ。
理由は機械とは基本的にエネルギー変換機構として働く場合が多く
その場合、基本機能がリニアな、線形な関数として入出力を
何らか定義することができる。
これは品質工学的な見地だ。
ここまでたどり着くには対象となる機械の機能とは何かについて
とことん考え抜くことになるのだが、結局はエネルギー変換に行き着く。
すると、その次元だとスカラー足し算可能な境地にたどり着くのだ。
そこまで行くと後は損失関数という概念を使うことで、
すべての機能を金額換算できてしまう。
すると、すべてはBOMでコントロール可能だということだ。

微積分やら各種の変換、写像、線形化、次元削減、
様々なテクニックを大学で学んだと思うがそれらはすべて
現象を足し算に落とし込むための道しるべと言っても過言ではない。
僕は日本の学校教育は良くできていると思う。

まとめる。

  • 複雑な現象は工学的テクニックにより、足し算に落とし込める。
  • 足し算に落とし込めばBOMで一元管理できる。
  • BOMで一元管理すれば、検索、フィルタリング、可視化などの横断的分析が圧倒的に捗る
  • 複雑な現象は大抵はエネルギー変換に落とし込んで足し算で管理できるばかりか
  • 損失関数により金額換算できてしまうのでBOMに落とし込むことは自然である。
  • だから開発の上流で開発用のBOMをさっさと作り込むことこそが究極のフロントローディング開発となる。
  • これらの見地はハードウエア開発で特に有効である。


以上、BOMの重要性でした。



ADHDが天才になるためのヒント。集中力はマネジメントすべき有限の資産だ。

僕は我ながらADHDっぽいところが多々あるなぁと自覚している。
ADHDとはAttention Deficit Hyperactivity Disorderの略で、
日本語で言うところの注意欠陥・多動性障害だ。

その行動障害が社会生活の差し障りとなっている場合、
この病名が付与される。

僕は、診断を食らった訳ではない。
その資質は大いにあるが、おそらく病的ではない。
仕事もクビにならず、むしろ理系サラリーマンエンジニアとして
ADHDならではの過集中を仕事に戦略的かつ最大限生かし、生活している。
だから病気ではなく、個性の範疇だ。

僕の興味の対象がたまたま自然科学と工学分野だったのは不幸中の幸い、
いや、むしろ軽度のADHDだったからこそ、今の僕がある、と思っている。

ADHDとは、精神病の一つの枠組みというだけだ。
鬱やらアスペルガー同様に、症状や程度は人それぞれ異なる。
ADHDの典型的な症例(社会生活上の困難)は
不注意、過活動、衝動性だと言われる。
要するに、
興味無いことを無視してしまう。
興味のある領域が狭い。
その一方で興味あることに対しては無性にアグレッシブ。
これがADHDだ。
ある種の天才になれる、それもADHDだ。
個性か、はたまた病気か、あるいは才能と呼んでいいかは
人それぞれだ。

ただ、サラリーマンとして活躍できるか否かは
この病気?と正しく向き合い、
適切な対応が出来るか否か
にかかっていると僕は捉えている。

自覚して、
戦略的に対処すれば、
これは何物にも代えがたいほどの
魅力的な個性となりうると、
僕は確信している。

その魅力とは、スイッチが入った時の異様な集中力だ。
一般的にこれは過集中と呼ばれる。

双極性障害、アスペルガー症候群でもこう言った過集中は起こりうる。
健常者だと、どうだろうか。僕には健常者の気持ちは分からないが
おそらく大抵の健常者には集中力で勝てるだろう。

もし、興味の対象が生産的・有意義なことであれば
その人は無敵となりうるのだ。

ただ、ADHDはその集中力をマネジメントすることが大変苦手だ
おおよそ不可能と言っていい。そもそもそれが可能なら病気じゃない。

一方、サラリーマンエンジニアに限らず、
なんらかの分野でプロであるという意味は
コンスタントに結果を出せるということだ。

コンスタントに、安定して、アウトプットを出すというのは
ADHDの人にとって最も過酷な課題といえる。

そこでこの記事では
集中力とはマネジメントすべき有限のリソースである
という概念を提案したい。

健常者だとちょっと想像し難いかもしれないが、
ADHDの人は集中力を管理できない。
しかも、スイッチさえ入ったら一気になんでもやれちゃうから、
気分が乗らない時は何もしないのだ。
基本的になんでも先延ばしである。
そう、学生時代になんでも一夜漬けで勉強してしまい、
その上、そのスイッチ入っちゃった時の卓越した集中力で
なんとか乗り切ってしまうという、
ある種、不幸な成功体験をたくさん持っているのである。
言うまでもなく僕もそんな人間だ。

こういうメンタリティーの人間は、
コンスタントな結果が求められる社会に出てから苦労する。
もちろん僕は苦労した。

そんな苦労の中で、社会人として、ADHDとして、学んだことをここで伝えたい。

結論はシンプルだ。

  1. 過集中は過度に疲れるので、割に合わない。
  2. そもそも集中力は有限のリソース。意識的にコントロールすべき
  3. アウトプットを最大化するには「適正な集中」が必要。
  4. 瞑想で集中力の総量は少し上げることができる。
  5. 過集中は瞑想で得た冴えた気分を台無しにする。
  6. 瞑想後はいつでも過集中に入れるがお勧めしない

以上である。

過集中はとにかく疲れる。虚脱とセットの行為であると言って差し支えない。
虚脱とは、すべての集中力がなくなる時間のことだが
大抵、過集中していた時間の数倍の虚脱が待っている。
過集中を仕事で使うとせいぜい3時間くらいしかもたない。
午前中に過集中で仕事すると午後は消化試合になる。
1日の仕事のアウトプットを最大化させるには適正な集中を続けるしかない。
ADHDな人にとって「適正に集中する」というのは死ぬほど難しい
ことであることは百も承知だが、それでも
声を大にして、僕は言いたい。
重要なのは適正な集中である。
それが1日の仕事の総量を最大化させるコツだ。
まずは適正な集中を目指し、過集中を避ける。
これがADHDサラリーマンへのアドバイスだ。

集中力が有限のリソースであるという事実も仕事をする上では見逃せない。
体力ややる気同様に集中力も有限の資産であり、予算があるのだ。
集中力を仕事でどう分配するつもりなのか、
ちゃんと意識して仕事することはとても大事なことだ。
集中したら、疲れるから、休憩する。
集中に対する休憩は、ボンヤリするか、心を無にするか、寝る、しかない。
休憩中にスマホを弄るなんて、とんでもない話である。それは休憩にならない。
休憩できたかどうかの目安は、また集中できるか、である。
休憩後に集中力が上がらないのであれば、それは休憩とは言えない。

欲しい時に欲しいだけの集中ができる人というのはそれほど多くはないだろう。
ジョギングやら筋トレ、コーヒーなど、人それぞれルーチンはあると思うが
僕は瞑想をお勧めする。
瞑想のやり方はこちらで説明する。
瞑想で得られる気分を僕は瞑想的気分と言っているが、
この状態になるといつでも集中した状態に入れる。かなり便利だ。

瞑想的気分は再現性よく集中した状態に入れるが、
過集中は瞑想的気分をなぜかぶち壊す。

以上
集中力をマネジメントする意識をもてるかどうか
がADHD気味の人への成功のアドバイス
という話でした。