mizohiro
ロボット、技術をはじめとした記事をまとめています。
知ってるのと、できるのと、やるのとは全然違うことだということ。 良い動画が流れてきたので共有 成果を上げれる人は、知ってる、できる、というだけでなく、それを実際にやっているという違いがある。 できるけどやらないという人がいかに多いことか。できるならやろう、以上。人の能力なんて、たいして変わらない。 勉強の復習と同じ。自分への戒めも兼ねて。
2023年末から健康に気を遣った方がいいという気もしてきて。30代後半に差し掛かると30代前半とも身体・精神の上で世界線が変わって見えてくるものがある。 身体の機能は衰えてくるが、精神としては、自分だけではなく拡張された周りも含めて自分ごととして、改めて見えてきたような気もする。 環境の変化に伴って、3-4年で思考のループが回っている。 ①33歳がmujin転職のタイミング、②30歳がカワダロボへの転職タイミング。③その前がTELへの就職タイミング。そのポイントポイントで
https://www.criteo.com/jp/insights/%E3%83%9F%E3%83%AC%E3%83%8B%E3%82%A2%E3%83%AB%E4%B8%96%E4%BB%A3-vs-z%E4%B8%96%E4%BB%A3/ ミレニアムからZ世代への変遷でより同質性の高いメンバとコミュニティ作るのが容易になったよね。 趣味も仕事も。 キュレーションするサイトなんて当たり前になったし、村化したことにより、ミニマムな構成で仕事をする人も増えた。 その
専用機と汎用機専用機と汎用機という視点で設計概念を考えると面白い。 汎用設計(機能・拡張性重視)：再利用性が高くなるような要件定義 専用設計(コスト・能力重視)：要件の絞込みによるシステムの簡易化 2足歩行のロボットは究極の汎用機だ。何をさせるかはユーザ次第でどうにでも使えるが、要件を絞らないと拡張性のみがあるだけで使えないものになる。 専用機として、搬送するためのコンベヤなどを考えると、要件を絞り込むことでシステムを簡易化して、コスト・能力を格段に上げることがで
難しい、分からない、を口癖にしない
ウォールマートに学ぶ危機感。 老舗でも、失敗して次の発見を見つけ出そうという貪欲さ
今私が読んでいる本の一節を紹介します。 「ＯＯＤＡも「観察（Observe）」→「方向づけ（Orient）」→「決断（Decide）」→「行動（Action）」という４つの段階から構成されている。観察に基づいた「方向づけ」をもとにやるべきことを決めていく、まさにフィードフォワード型の思考法である。 ＯＯＤＡループの各ステップが、本書で描いてきた「真のWant toの発見」「パーパスの自分ごと化」「決断が先」「行動変容」といった各要素とどこか似ているのは決して偶然ではない。エ
アニマルウェルフェアとか、SDGsとかの文脈を言い訳に無駄とかコストアップを是とする世の中なんとかなって欲しい。 コストがかかるということは、エネルギかかっているというという可能性もあるからね。
「仕事について気にかけると報われるのか？ それとも、これっぽっちも気にかけないほうが得をするのか？ 社員が努力して何かを変えようとしたり、新しいアイデアを提案するたびに、官僚体質や優柔不断さや無関心に阻まれていれば、文化は傷つく。会社を前進させた社員が認められ報われるたびに、文化は強くなる。」（『Who You Are（フーユーアー）君の真の言葉と行動こそが困難を生き抜くチームをつくる』（ベン・ホロウィッツ, 浅枝 大志, 関 美和 著）より）
ソフトなくして、ロボットに命を吹き込めないが、逆も然り。 堅牢な良いハードウェアなくして、ロボットは成立しない。 ソフトウェアが強いメーカの良いところは、自由な発想が生まれやすいことだ。いい意味で、メカ的な制約を考えずに「これ出来たらいいな」というアイディアが生まれやすい。逆に言えば、それを解消すれば新たな道が開けるからだ。 所謂日本のメーカは通例、メカエンジニアの部署が幅を利かせ、そこで決まったものが全て。その後に、メカの制約を守りながらソフトウェアが実装される。その組
久しぶりに、読書ノートをつけたのでメモ。 「ユニコーン企業のひみつ」を読んだ。オライリーの本はなんとなくテンションがあがります。 自分なりに咀嚼すると、やはり信頼と権限を与える代わりに言い訳を与えず、結果にフォーカスできる組織だと。 信頼もせず、権限も与えなければ、結果だけを求めることは傲慢なことだと（エンタープライズ企業のできない管理職にありがちな）。 繰返しのイテレーションからプロダクトへフォーカスしていこう。自分が分析して、事前に要件を把握できているという傲慢さも
アベレージなパフォーマンスしてたらやられる 終わるか、変わるか
やりすぎると変更範囲の管理が大変。 やらないと似た様なことを何度もやることに。 最適化をするために考えていることをステップで書き出してみた。自分の思考のフローの整理も兼ねて。 ①利用シーンのユースケースをできるだけ書き出す大抵の場合、この作業に漏れがあり、最終的なモジュール化を行ったときに、なんとなくつかえないものになったり、現実に即さないものになる原因である。ユースケースの書き出し方は、箇条書きにしても良いし、UMLなどを使って書き出してもよいが、このステップに時間をと
Mujin入社して2年経ちました。 今の時代、会社と個人の目標は一心同体である必要性はないんだなぁ、と色々な文化や時代の流れを経て感じるようになってきた。 人の成長と会社の成長の過程で、不調和が起きることは絶対にあると思うが、その違いを捉え、どのように受け入れるかということは、会社のライフサイクルが早くなっていくこれからの時代に備え、自分なりに咀嚼する必要がありそうだ。 一方で、昔も今も変わらず、 ロボットによる自動化に最短距離であるところで、貢献したい 気持ちはよ
先月、34歳になりました。 20代で、大量のインプットとTry＆Errorみたいなものを繰り返し行って、いろいろな人からフィードバックをもらってきて、ようやく足し算だけでなく、引き算ができる年齢になってきたと実感がある。 20代の頃はとにかく、自分が知っていることはすべて盛り込めば良いものができると信じていた。 おそらく教授にも呆れられていたと思うが、修士論文は３００頁を越えていたし、新入社員の頃の提案プレゼン資料は、ページ数30頁を下回ることは無かったと記憶している。客
この10年くらいで学んだことは、ロボットを使った自動化はハードウェアはやっぱり結構重要ってことと、足し算より引き算をいかに考え抜くかという事に尽きる。 余計なことをしないような最小限、を考えること。
