日本がホンダジェットから学ぶべき教訓とは？
MRJを考える際にどうしても気になるのは、ホンダが開発し、好調な滑り出しを見せたホンダジェットだ。あるいは、MRJのライバルであり、リージョナルジェット旅客機大手のブラジルのエンブラエル。ホンダジェットは、エンブラエルは、なにがMRJと違っていたのだろう。ええい、全部訊いてしまえ――ということでオリンポス社長、四戸哲氏インタビュー、第5回です。 （前回はこちら） 四戸 哲（しのへ さとる）有限会社オリンポス代表取締役。1961年、青森県三戸郡生まれ。小学生時代に見た三沢基地でのブルーインパルスのアクロバット飛行を見たことが航空エンジニアを志すきっかけとなった。学生時代のヒーローは航空エンジニアの木村秀政氏。高校卒業後に木村氏が教授として在席している日本大学理工学部航空宇宙工学科に入学し、日大航空研究会に所属。卒業後、日本には極めて珍しい、航空機をゼロから設計する会社としてオリンポスを創業。
エンジニアの特別感について
某所で主にエンジニアの方々が、 「人間はミスをするのが当然で、それを組織でカバーするのが望ましい」って言ってるけど、 それって別の立場でも言えるのかな？ 例えば、社内の連携ミスで無謀な仕事を取ってきた営業がいる場合、 その営業に文句言うことなく、それを組織、この場合は会社としてカバーするように対応してる？ 私見だけど、どうもエンジニアの方って、自分（達）を特別視してるような気がするんだよね。 どんな仕事も苦しいこともあるのに、自分たちの苦しさは異常だ！っていう風にさ。 ＜9/9 17:30追記＞ 散々ブコメで指摘されてますが、「組織でカバー」は「そういうものを防ぐような組織や制度を作る」という認識でした。 ここまで注目されると思っていなかったので、雑にまとめてしまいました。申し訳ありません。
「ニッポンはもうIT大国になれない」を書いてから1年たった
http://anond.hatelabo.jp/20160228001028 あれを書いた意図ははもちろん、「ニッポンがんばれ」だ。日本のITを取り巻く状況は変わらないといけない。だからこそディスったのだ。 （保育園落ちた日本死ねと書いた人もおそらく、日本もっとちゃんとしてよ！という意味で書いたのだと思う。） ありがたいことに非常に多くの反応があり一通り全部読ませていただきました。 しかし本当に見たかった「いや、ニッポンはIT大国になれる」という説得力のあるコメントや記事は見つけることはできませんでした。 代表的な意見を(エスパー的に)かいつまんで返信してみます。 主語が大きい → 狙い通りです。ありがとうございました。ドラゴンボールの例え？おまえおっさんだろ？ → 返す言葉もございません。ところであなた様もオッサンでございますか？ITじゃなくても自動車とかあるし大丈夫だよ？ → 車はそ
ITエンジニアが誤った情報にツッコミを入れるのは「正しさハラスメント」ではない - give IT a try
はじめに 先日、はてなブックマークで話題になっていたこちらの記事を拝見しました。 確かに「一理ある」といえばそうなんですが、僕個人はこの意見に対して率直に「NO」だと感じました。 僕は基本的に自分の専門分野であれば、結構積極的に技術記事にツッコミを入れていくタイプです。 このエントリでは、なぜ僕は「NO」だと感じたのか、そしてなぜ積極的にツッコミをいれていくのか、その理由について書いていこうと思います。 元記事の要点 僕なりに元記事を要点をピックアップすると次のようになりました。 ITエンジニアの中には初心者の成功体験を折りに来る人がいる。 筆者は成功体験の「気持ちいい」状態を阻害する行為に疑問を覚える。 初心者にはセキュリティ周りについて教えても仕方がない。 初心者もいずれセキュリティ対策について知識を得るはずだ。 早すぎる指摘が生まれるのは「それが間違っているから」だ。 初心者にはまず
SICPの翻訳についての補足と和田訳について - アスペ日記
最近、計算機プログラムの構造と解釈（通称SICP）を訳し直すということをやった。 そのときに書いた記事にはだいぶ反響があった。 ぼくとしても、いろいろ言われることは予想できていたので、ぼくの考えを「腐った翻訳に対する態度について」という別記事にまとめた。 この記事でぼくの考えをわかってくれる人もいたが、いろいろ見て回ると、ぼくに対して強い反感を持つ人もいたようだ。 そういうわけで、この件全体について改めて考えてみたことを書くことにする。 前提 まず、以下のような意見について簡単に触れておく。 SICPをいま読む価値はない。 SICP（に限らず、英語の技術書）は原書を読むべきだ。 SICPには和田訳があるからそれでいい。 SICPのminghai氏訳はそれほど悪くない。 誤訳は読者自身が気づくべきだ。 SICPをいま読む価値はない。 たしかに…もうSICPなんか読む時代でもないし、あれはねえ
若手開発者の後悔 | POSTD
(編注：2020/08/18、いただいたフィードバックをもとに記事を修正いたしました。) これはある仕事熱心な若手開発者のほぼ実話です。2004年の後半、この若手開発者は小さな会社で働き始めました。条件は全て彼の望みどおりでした。給料はいいし、扱うのは彼の得意とするプログラミング言語、アプローチの複雑性、モデリングのアーキテキチャでした。 彼にとって今回の会社が初めての職場ではありませんでした。しかし、ここでの最初のプロジェクトは結果的に 問題だらけ に終わりました。当時、この若手開発者は、機能は絶対に変わらないものだと思っていました。しかし、それは間違いでした。機能が変更されるたびに完全なリファクタリングを行わなければなりませんし、バグを引き起こして膨大な時間を無駄にしてしまいます。彼は、テストを書くといった実直な方法も試してみましたが、書いたテストはメンテナンスが必要な上、書くのに時間
エンジニアマネージャー論と学びを抽出する努力を続けること - ワザノバ | wazanova
https://news.ycombinator.com/item?id=8406507 1 comment | 1 point | by WazanovaNews ■ comment by Jshiike | 約1時間前 真剣にものごとに取組むと、やらなくてはいけないことはそのうち次から次へと気づく and/or 嫌でも湧き出てくるもの。なので、アドバイスを求められれば、やるべきことは最小限、できれば三つ以内に絞って、何をやめることができるかを探す手伝いをするようにしています。やるべきことを毎日洗い直して、絞り込むことが大切。 情報の収集は自動化されてきますが、自分にとって何がポイントなのか、どう活かすべきかという抽出作業は、自らを鍛え続けなくてはいけない人力作業ですね。 RethinkDBのFounderであるSalva Akhmechetが、エンジニア組織のマネージャーのあるべき姿
第7回 エンジニアは資金調達も苦手 | gihyo.jp
今回は資金調達について考えてみたいと思います。 以前も書きましたが事業には元手＝キャッシュが必要です。 キャッシュを増やす方法 キャッシュを増やすには3つの方法があります。 1つは事業による利益で増やす、1つは増資で増やす、1つは借り入れで増やすというものです。このうち、増資もしくは借り入れで増やす2つをまとめて資金調達と呼びます。 エンジニアに限らず一番よくあるパターンが、最初は手金で起業するというものでしょう。手金が尽きる前に事業でキャッシュを増やせれば、つまり営業キャッシュフローをプラスにできれば資金調達は不要です。 以前の連載で取り上げた、フリーランス的な起業、いわゆる単なる独立はここでは除外します。とはいえ最初からなかなかキャッシュフローの収支をプラスにするのは難しいですし、逆に最初から順調にキャッシュが増えているケースだからこそ資金調達したくなる場合もあるでしょう。 そこで、今
エンジニアに求められるコミュニケーション能力とは〜社交性なんてなくたって仕事はできる | Social Change!
エンジニアにとってコミュニケーション能力は必要でしょうか。この話題については、賛否両論あるでしょうし、そもそもコミュニケーション能力とは何かを考えなければいけないでしょう。 私たちの会社ソニックガーデンでは、プログラマの仕事を「ソフトウェアのエンジニアリングすべてに責任を持つ仕事」と定義しています。具体的には、お客さまと対話して要件を引き出すことから、データ構造から画面までの設計を行ったものをソースコードで表現し、クラウドでの運用まで面倒をみるという、ソフトウェアを作って動かす全てを行います。 そう話すと、よく聞かれる質問があって「コミュニケーションが苦手なエンジニアはどうすれば良いでしょうか？」というものです。もし本当に誰とも話をしたくないし出来ないというのであれば、残念ながら、と言うしかありません。しかし、コミュニケーションと一括りにしてしまっていて誤解があるのかもしれません。 そこで
「もう政治に興味はない」堀江貴文氏が語る世の中がメンドくさい理由
2014年6月22日、首都圏コンピュータ技術者、パートナーフォーラム 2014の特別講演として、「フリーランスと起業」をテーマに、ロケット開発を手掛ける企業SNSのオーナー、堀江貴文氏が登壇した。現役エンジニアが多く集まる会場に、堀江氏が日ごろの不満をぶちまけるところから話はスタートした。 堀江氏はまず、自身のTwitterでも話題にし、ネット上でも議論を呼んだ「病院待ち時間問題」を取りあげた。「腎臓結石の予防で慈恵医科大学に行ったんですが、1時間30分も待たされて腹が立った」――。 この件をTwitterに書いたところ、堀江氏のもとに何社かの医療関係企業が「わが社の取り組みを聞いてくれ」とアピールしてきたとのことだ。それらの企業が売りにする、病院での待ち時間短縮の仕組みを聞いたそうだが、どれもイマイチだったという。 「病院のイヤなところはあのプラスチックの診察券。あんなのなくして当たり前
技術は発想やデザインの限界にならない
当時の思い違い たとえば、一般的なエンジニアが何かを作ろうとすると、その個人の「技術的な限界＝発想の限界」となりがちです。 ではデザイナーと呼ばれるような職能を持っているひとが、果たしてプロダクトを実装として理解すべきか、というと、それは分業上の実装サイドによるエゴ（こっちの都合もちゃんと考えて欲しい！的な）でしかないと思っていました。 多少、吹っ飛んだ話であっても、意図を失わずに現実的な実装に落とし込むのはコミュニケーションの問題であって、デザイナー職能の理解不足ではない、と。 コミュニケーションでも解決できる問題として、これは今も間違ってはいないはずですが。 しかし、これは適切なタイミングで、大きな青写真を描くための能力であり、デザイナー職能を全うする話とは違ったのです。 優秀とは 身の回りで優秀なデザイナーと呼ばれる諸氏は、ビジュアルを作るだけでなくステートの管理までよく考え、利用コ
エンジニアの成長と反抗期 | 外道父の匠
最近、後進の育成について考える機会があります。 ある時、こんな状況で困ることがあるんだけど、どう思う？ と聞かれて飛び出した言葉【反抗期】について考えてみます。 相談内容 育成や生産効率をテーマにした会食にて、相談された内容は あるエンジニアが実力以上に過信して自己評価する やたら特定の技術に拘って、結局リリースが伸びたり改悪したりする ・・・んだけど、これは何なんだろう、どうしたらいい？というもの。 これに対し、自身の辿った道も思い直して出した返答が 『それは、エンジニアの反抗期だよ』 もちろんこれは、こどもがヤダヤダ拒否する（＝仕事したくない）本来の意味ではなく 逆に、やり過ぎによる失敗経路への舵切りのことを指しています。 聞き手はこれで非常に納得がいった様子。 反抗期とは おそらく3～5年目の時期に、技術やアイデアに偏ったものを創り出すことがあります。 そして、閑古鳥／改悪サービスに
【寄稿】 エンジニアはブログを書いた方が良い、その理由をキャリアの視点から考える - 週刊はてなブログ
CodeIQ×はてなの エンジニア夏祭り2013 第2夜では、エンジニアにブログを書いてもらうキッカケになってもらえればと、お題キャンペーンを実施中です。この一環として、ITエンジニアがブログを書くべき理由を、CodeIQプロデューサーの サカタカツミ さんに寄稿いただきました。 無名のはてなブロガーが、こんな晴れがましい舞台に出る理由 最初にネタバラシをしてしまうと、エンジニアはブログを書いた方が良い、というエントリーを、まったく無名のはてなブロガーである私が寄稿してあげても良いよという、上から目線で何様な発言を、はてな東京オフィスのとても美味しいランチを取りながらしていたのを、どこでどう間違ったのか、真に受けた人がいて「だったら寄稿してくれてもいいですよ」と依頼メールが飛んできて、今書いているという次第。が、ブログの楽しさを紹介していくブログマガジンを読んでいる人の多くは、もうブログを
青色発光や電力素子用の材料開発に関する昔話少々
シャープのGaN系トランジスタ開発のニュースに絡めて、SiCやGaN、ZnSe等の材料開発現場の昔話を少々。@koma2ug さんのシャープ内部の怖い話とか、ソニーの圧巻のZnSe系最終報告の話とか。
エンジニアを頑張ったで評価する会社は衰退する | rake enjoy
この前飲み会でこんな話をしていたのでまとめてみます。 終身雇用が崩壊し、昨今では会社の評価制度では成果主義というのが普通になりつつあります。ただ成果主義とは言いつつ何を持って成果とするかは議論の余地があると思います。 例えば営業職であれば分かりやすく売上目標というものがあります。企画職の場合でも売上やその他のKPIを目標設定することで分かりやすく評価出来ると思います。ではエンジニアの場合はどうでしょうか。 開発したシステムが実際に軌道に乗って数字を出し始めるまでには相当時間がかかります。（最近のゲームなどは除く）またその数字が出るか出ないかは実際営業や企画側の問題が多分にある為、こういったケースでエンジニアを数字で評価するとシステムの良し悪しとは関係なく単純に運がいいか悪いかだけになってしまいます。もちろん企画に意見が反映出来る環境であったり営業に指示できる環境であればエンジニアでも数字を
we-blog — プログラミングを知らない人が、優秀なエンジニアとチームを組む方法
2012/11/24 (読了時間1分) この記事は長部(おさべ)が担当しました。 私は開発できません。それでも何か作りたい。 「自分は開発できなくて困ってます。。エンジニアはどうやって集めたんですか？」と学生によく聞かれます。今日はそんな「作りたいけど作れない人」に向けたエントリーです。 大学4年生の夏、私は「このままゆっくり人生が終わってしまうのではないか！」と思い、とりあえず何かサービスを作ってみることにしました。会社をつくる半年前の出来事です。 当時は今よりウェブサービスいけいけの時期でした。つくるならアプリだな、そんな感覚で動き出しました。 「なにやら、、、プログラミング、、、という物が、、、あるらしい、、、？？」そこではじめてアプリをつくるのにプログラミングが必要なことを知りました。 もちろん、一度は自分でもプログラミング勉強してみたのですが、全然歯が立ちません。 これはだめだ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
起業家の勉強会にて『エンジニアは自身の趣味で開発請け負って金を稼げるので会社として払う給与は低くて良い』と主張する人が現れた
トップ技術者1000人流出 - 日本経済新聞
エンジニアから飛んでくるマサカリを受け止める心得
Re:コミュ障に悩む技術者へ。
