「何をやっても駄目だった」ポンコツの自分を救ってくれたマインドセット - メソッド屋のブログ
先日 エンジニアType さんから取材『牛尾剛さん、『世界一流エンジニアの思考法』って本当に日本でも実行できますか？(仮）』を受けました。私は「日本で出来ないことは何一つありません」と回答しました。私が日本にいるときに実際に実施したアクションや、実際にやってみた事例などをご紹介しました。 それは、私が自信に満ち溢れた人物だからではなく、幼少のころから自己肯定感も低く、何をやっても上手くいかなかった自分を救ってくれたちいさな「マインドセット」があったおかげです。 「何をやっても駄目だった」ポンコツの自分を 救ってくれたマインドセット このマインドセットは『日本では一見難しそうな何かを実現すること』に対しても過去の人生でとても有効でした。同じような悩みを持つ人のために、エンジニアTypeさんの記事のフォローアップとしてこちらにも書いてみることにしました。それは小さなマインドセットのチェンジなの
日米でエンジニアの育成戦略が正反対だと気付いた話 - メソッド屋のブログ
今週は、Thanksgiving はお休みムードなので考える時間や、自分の本についてディスカッションしている バンクーバーのえんじに屋さんのPodcast なんかを聞かせていただいたりしてるうちに、思い出したことがあって、記録に残してみることにした。それは、エンジニアの育成方針でこれはめっちゃくちゃ違うことに気づきましたので、シェアさせていただきたいと思います。 日米でエンジニアの育成戦略が正反対だと気付いた話 採用の段階での違い 良く知られているように、新卒のケースで考えると、こちらの場合は「コンピュータサイエンス」の学位を出ていることが前提で、中途採用の場合も、「コンピュータサイエンス」の学位を出ている、もしくはそれ相当する知識が求められる。だから、新人でも少なくともプログラムが結構組めることを期待されます。 一方、日本では文系でも理系でもプログラマになれます。採用されたときに「スキル
批判の文化が日本を技術後進国にしているかもしれないという話 - メソッド屋のブログ
先日、接触確認アプリがリリースされました。これは正直日本のソフトウェアの進歩に画期的なことだったと思います。私も衝撃を受けました。 www.mhlw.go.jp その後起こったことに関して正直は私の感想はこの通りです。 日本で起こっている地獄を見て、アプリ開発者は海外に流出してしまうわって思う。あの流れは最低最悪。みんな自分が気持ちよくなるためだけに、自分の国の未来を破壊してるんやで。— TsuyoshiUshio (@sandayuu) June 21, 2020 このような展開は、私が今住んでいるアメリカでは発生しない事案だと思います。じゃあ、日米でどういう違いがあって、日本人の自分が小さな一歩を踏み出して、日本がよりよい国になるようにできるとしたらどんなことだろうということを考えてみましたので、あまりソフトウェアの専門用語を使わない形で書いてみようと思います。 接触確認アプリが生まれ
アメリカに住んで初めてわかった「最大級」の違い - メソッド屋のブログ
昨年の年末にアメリカに移住して、今はシアトルの近くの Kirkland というところに住んでいる。大体三か月たって、いろんなことを体験した。移住した理由は単純で、コンピューターサイエンスの世界ではアメリカがどう考えても一番進んでいるので、そこで修行して通用するようになったら楽しいかなと思ったからだ。他にも他国の人を観察しているととても生産性が高い。特にアメリカの人は生産性が高い傾向が高い。なんでこんなにアメリカはコンピューターの世界が向いているのだろう？その一旦を感じた気がしたので久々にこのブログを書いてみることにした。 Kirklandの風景 自分へのご褒美を買う アメリカに移住すると、当然日本にいる友達とかと会えなくなる。私は一人でもさみしくない人だけど、さすがにこたえるだろうと思った。だから大好きなバンドをまたやろうと思った。ただ、こっちは正直レベル高いし、私はヴォーカリストだから、
ADHD プログラマの私がやっと見つけた「達成すること」が出来る方法 - メソッド屋のブログ
私は昔から ADHD で昔から発想力や問題解決力はあるのだが、自分自身が何かのスキルを上達することが非常に苦手だ。コンサルとか、エバンジェリストみたいな「人にやってもらう仕事」は得意だが、プログラマとか、ヴォーカリストとか、自分が本当になりたかった職業には何回もチャレンジして何回も失敗してきた。 遠くから見ていると私は何かが出来てるように見えるかもしれないが、冗談抜きで人の３倍ぐらい時間をかけないと成果が出ない。しかも、中途半端にしか完成しない。だから、土日も常に何か努力していないと不安になる。 多分私と同じようなADHDの人は、自分的に努力しても何も達成出来ない辛さを感じているかもしれない。過去にも色々試してみたのだが、４７年生きてやっと自分でも実施できる対策が見つかったので、同じ様なことで苦しんでいる人のヒントになればと思い久々にこのブログを書いてみた。 「自分で何かを作れる人」が長年
日本のITエンジニアがイノベーティブでないのは暇じゃないからかもしれない - メソッド屋のブログ
ここ１ヶ月ぐらいは、海外のメンバーと仕事をしているが、Serverless Hackfest というイベントと、Serverless Conf やワークショップに関わっているので仕事量が増えていった。日本にいることだし、久々に「日本流」のハードワークをしてしまったのだが、一つ気づいたことがあった。それは、ここしばらくの謎だった、日本人のIT エンジニアはなぜイノベーティブな感じがしないのか？ということに対する問いだった。 Microsoft Hack week 日本人はイノベーティブ Rochelle Kopp さんとの仕事で知ったことで、一つとても意外だったことは、アメリカ人から見ると日本人は相当にイノベーティブに感じるらしい。 自分的には、少なくともIT 分野に関しては、向こうの真似ばかりしていて、後追いのイメージがある。私たちも向こうで生まれたツールやサービスばかり使っていて、全然日
技術なきマネジメントの衰退とその対策 - メソッド屋のブログ
今回は、マイクロソフトにいて自分が感じているIT業界の大きなスタイルの変化の兆候とその対策について書いてみた。今回もいつも通り、単に自分の意見をシェアしているだけであって、他の人にどうこうしろと言いたいわけではない。ただ、日本のIT業界が米国に追いつき、追い越すための議論のきっかけになるといいなと思っている。自分も楽しみながらも、もがいていることと、そこで見えた光について書いてみたい。 世界は「技術力」の重視に向かっている 私のキャリアは、某大手SIerを12年勤めた後、ITコンサルティング企業に３年在籍して、主に超上流を実践した。その後独立し、ビジネスモデリングから、アジャイルや、DevOpsの導入支援、マネジメント、開発などを実施していた。 私がマイクロソフトを受けてみようと思ったのは、友人からの推薦の要素が大きかったのだが、その背景では、海外で勤務したいという希望があったのと、「技術
「検討」は無駄である - リスクや間違いを快く受け入れる第２の習慣 - メソッド屋のブログ
仕事の習慣・考え方を変え生産性や新しい技術の導入を米国並みに加速する「８つの習慣」のうち「リスクや間違いを快く受け入れる」に関して考察した。具体的な実践プラクティスに関して言及してみたい。 最初の習慣は次のブログで紹介してみた。 simplearchitect.hatenablog.com リスクや間違いを快く受け入れる リスクを背負うことは推奨されている 間違いを厳しく批判したり懲罰したりしない 失敗から学ぶ態度 Fail Fast(早く失敗する） 実験が推奨されている 全員に「現状維持」や「標準」を要求せず、臨機応変が推奨される 非難や恐怖感の無い環境 この習慣は、日本人の我々にとってかなり難易度の高いものである。なんとなく言葉では分かっているつもりでも、海外で働いていると、自分の想像の範囲を超えていた。ということは、この習慣が身につけば相当かっこいいかもしれない！ 間違いや失敗に対す
「それ、アジャイルできてへんのちゃいますか？」チェックリストの公開 - メソッド屋のブログ
DevOps を導入して、リードタイムの短縮などの効果を出したい時に、前提条件となっている「アジャイル」がまだ導入できていないケースが多い。そういったケースでは、まずアジャイル導入のご支援をすることもよくある。 そういった支援に入ると、「アジャイル導入前提」で構成されたはずのプロジェクトであっても、全然「アジャイル」のポイントを外しているというケースは珍しくない。更に問題なことに、「アジャイルをできます！」と言っているベンダーさんを連れてきても、全然ポイントを外しているというケースすら珍しくない。今回のブログではそういったケースでも、簡単に確認できる、「アジャイルになっていないかもしれない簡単なチェックポイント」を対策付きでいくつかご紹介しよう。 スプリントの中で、ウォータフォールを実施するのではない。それはミニウォータフォールというバッドプラクティスだ。 1. 進化型設計ができていない
新技術導入の遅さの一端はラーニングモデルの違いかもしれない - メソッド屋のブログ
以前から不思議に思っていたことがある。それは、少なくとも米英の人は、ソフトウェア技術やプロセスに対して誤解が圧倒的に少ないということである。 別の回でも書いたが、イギリスの会社とお話しした時も、「アジャイル」に対するとらえ方、考え方は、100%といっていいほど正確だった。 バリューストリームマッピングで困っている人の話 今回の出張で、Sam Guckenheimerに依頼されたことがある。ある人が「バリューストリームマッピングをやっているのだが効果が出なくて困っている」だから原因を一緒に探ってほしいとのことだった。 Samと一緒に彼の話を聞いていると、バリューストリームマッピング、DevOps に関する考え方とらえ方は極めて正確だった。彼の問題は、「コンセプトの理解」は何の問題も無く、その先の「実際にやってみて工夫してみないと到達できない部分」の問題だった。 なぜか米英では、ソフトウェアの
ソフトウェアの納期見積もりは、星占いレベルのものであると思う - メソッド屋のブログ
このエントリでは、ソフトウェアの見積もりがどういうものであるかをシェアした上で、今後日本はどのような方向に向かえばよいのでは？という私のアイデアをシェアしたいと思う。 注：このエントリは、某銀行の件とは全く関係ありません。考えるきっかけになっていますが、中の人がどんな状況だったかもわからないのに、勝手なことを想像して、人や企業を叩くのは私の趣味ではないからです。 ソフトウェアの見積もりの正確さ ソフトウェア見積もりのことを知りたければ、下記の本がお勧めだ。 books.rakuten.co.jp この本に「不確実性のコーン」という開発フェーズごとの見積もりの正確性に関する図がある。これを見ると、最初の企画の段階で実施した見積もりは、誤差が何と16倍もあり、概算見積もりのレベルでも4倍の開きがある。画面帳票仕様を「確定」したレベルでやっと1.6倍程度の開きになる。 請負開発を実施するときに、
自分で人生を決めるマインドセットが、生産性と、仕事の楽しさをもたらす - メソッド屋のブログ
今回は、前回のブログの内容をより考えてみたいと思う。 「自分で人生を決める」人は、他人に対して「すべき」がない 前回のブログの主張は、「自分で人生を決めない」マインドセットが、新しい考えや技術導入を遅らせるというアイデアだった。今回はさらに、「自分で人生を決める」マインドセットをもっていると、どういう効果があるのかを考えてみたい。 simplearchitect.hatenablog.com 「自分で人生を決める」というマインドセットを持っていると、「自分のことは自分で決める」という考えになる。心理学で鏡の法則というのがある。自分に適用している考えを他人にも適用するという法則だ。「自分のことは自分で決める」人は、「他人のことは他人が決める」という考え方になる。新しいアイデアや技術の導入スピードにはこれがとても効いている気がする。 逆に自分の人生が自分でコントロールできないと思っている人は、
私は間違っていた。ごめん。ウォーターフォールは何のメリットも無い - メソッド屋のブログ
私はソフトウェアの専門家としてお答えすると、ウォータフォールは何のメリットも無いというのが私の意見であることを共有しておきたい。そういう意見に至った経緯をこのブログで書き留めて置きたい。 尚、これは所属会社の見解ではないことは明確にしておきます。 サム・グッケンハイマーの一言 私は DevOpsのエバンジェリストで、それ以前からアジャイル開発をかれこれ１５年ぐらい実施し、導入の支援をしている。私はかつては、日本の環境の制約の中で如何にアジャイル開発のメリットを最大に引き出すか？ということを考えていた。 ウォーターフォールに対する立場も、真っ向から否定するものでもなく、現状もあるし、それに慣れている人もいるし、実際ウォーターフォールでも失敗しない人も居る。だから、人にウォータフォールのメリット・デメリットを聞かれた時も「変化しないものに関してはウォータフォールはいいのかもしれない」と回答して
ダイバーシティの本質はそういうことじゃないんじゃないかな - メソッド屋のブログ
いつも通り、生産性に関するブログを書こうと思ったのですが、その過程で、ダイバーシティについて少し調査しようと ブログや本をチェックして、とても違和感を感じました。そこで自分の意見を整理するために、ブログを書いてみました。 私は単にインターナショナルチームのメンバーであるだけで、専門家でもなんでもないので、稚拙で誤った意見かもしれませんが、それでも何か書いておくと自分の整理と学び（プロセスの改善のプロフェッショナルとして）になるかと思い筆をとってみました。 自分の感じるダイバーシティの違和感 私はインターナショナルチームで働いています。そして実際にその環境で働いていると、本当に楽しく快適に働けています。だから、その環境の素晴らしさと、その環境を日本でも実現する方法を考察するために、インターネットを調査してみました。 Microsoftはダイバーシティに非常に力をいれているので、必須教育でもダ
「Be Lazy」を極めるためには残業をしてはいけない - メソッド屋のブログ
「Be Lazy」というのは、日本側の上司にあたる Drew がいつも口にしている言葉だ。その意味合いは、「最小の工数で、最大のインパクトを出す」 という考え方だ。私もアジャイルやリーンを学んできたので、「大量のものを高速に作れること」はむしろ悪であり、いかに「作らなくていいか」を考えてインパクトの出るものにエネルギーをフォーカスするのが重要と思っている。 しかし、正直に言うと、それは、日本人の感覚からいうと最も縁遠い感覚だ。私がなぜ「Be Lazy」を極めたいと思っているか？というと、インターナショナル チームの同僚は仕事で成果をガッツリ出すのも尊敬に値するが、仕事をしている様子も実に楽しそうだ。誰も苦しそうだったり、我慢したりしていない。 仕事は楽しむものと言っていて、「我慢するべきもの」という日本側の空気とは相当違う。私は自分も人生や仕事を楽しみたいし、多くの人がそうなったらいいのに
ソフトウェア開発の生産性を阻害する「気軽に聞けない」ことの考察と対策 - メソッド屋のブログ
マイクロソフトの DevOps テクニカルエバンジェリストになる前から、ずっと不思議だったことがあります。 それは、「アメリカのエンジニアの生産性の高さ」です。素晴らしいサービスは大抵彼らから生まれていますし、彼らを見ているとアウトカムも生産性も非常に高く感じます。 私は個人的にこの秘密を解く旅の途中にいます。私はインターナショナルチームに所属しているのですが、同僚と一緒に働いたり、ハッカソンをしたりして気づいた１つの仮説について共有したいと思います。 気軽に「聞けないこと」が生産性を阻害しているのでは？ 以前私は「米国のエンジニアはコンピュータサイエンスを専攻している人が多くすごく優秀で、さらに英語が出来るので、技術収集するのも楽だから相当アドバンテージがある」と思っていました。 英語に関してはそうだと思いますが、彼らの個々の人がそんなに優秀かというとそうでもないことに気づきました。それ
プレゼン作成の効率化について考えてみる - メソッド屋のブログ
職業柄講演資料を作る事というのは結構多い。しかし、毎回困るのがホンマに時間がかかることだ。今回はベトナムで英語で講演という事がなんと１週間前に決まったので大慌てで作った。しかも日本とソフトウェア開発の事情が違うから一から作り直ししかも英語というわけで、結局２日徹夜した。 多分これは英語云々のお話ではなく私はそもそもプレゼンテーションを作るたびにこんな事をやっている。ホンマにしんどい。なんとか効率化できんものやろか？ということで、Facebook等でつぶやいているといろいろありがたいご指摘をいただいた。 私がプレゼンテーションに求める要件 私がプレゼンテーションに求める要素は三つある。必要十分にシンプル／カスタマイズ可能／かっこよさだ。 私はプレゼンテーションZENスタイルはあまり好きじゃない。すっごくかっこ良くて、プレゼンとして聞いている分にはとてもいいんだけど、後から見たらキレイさっぱり
こんなプログラマはアジャイル出来ますって言ったらアカンやろ - メソッド屋のブログ
最近、とある機会があって、いろんなアジャイルが出来るといってくるベンダーさんとあう機会があるけど、正直「おい！どの口がアジャイル出来るって言ってるねん！」って思う事がむっちゃくちゃ多い。 今は確かにアジャイル開発ブームで、世間では引き合いも多いらしい。いろんなベンダーの営業さんが、「うちもアジャイルできます」って言って営業してはるけど、マジでちゃんと自社でできるか調査してから営業してほしい。私はアジャイルを１０年以上やってるけど、元々は「この方法やったら、お客さんにホンマにええアプリを届けれるんちゃうか？」と思ったところから来ている。 それが、今や猫もしゃくしもアジャイル出来ますとか言って、ろくにアジャイルも出来へんのに売りつけて、結局効果がでなくて、「やっぱアジャイルなんかアカンやん」ってなるのがむっちゃくちゃ嫌なのだ。 これって数十年昔のオブジェクト指向ブームと一緒やん。当時のオブジェ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
