タグ

ブックマーク / simplearchitect.hatenablog.com (34)

  • 「何をやっても駄目だった」ポンコツの自分を救ってくれたマインドセット - メソッド屋のブログ

    先日 エンジニアType さんから取材『牛尾剛さん、『世界一流エンジニアの思考法』って当に日でも実行できますか?(仮)』を受けました。私は「日で出来ないことは何一つありません」と回答しました。私が日にいるときに実際に実施したアクションや、実際にやってみた事例などをご紹介しました。 それは、私が自信に満ち溢れた人物だからではなく、幼少のころから自己肯定感も低く、何をやっても上手くいかなかった自分を救ってくれたちいさな「マインドセット」があったおかげです。 「何をやっても駄目だった」ポンコツの自分を 救ってくれたマインドセット このマインドセットは『日では一見難しそうな何かを実現すること』に対しても過去の人生でとても有効でした。同じような悩みを持つ人のために、エンジニアTypeさんの記事のフォローアップとしてこちらにも書いてみることにしました。それは小さなマインドセットのチェンジなの

    「何をやっても駄目だった」ポンコツの自分を救ってくれたマインドセット - メソッド屋のブログ
    isrc
    isrc 2023/12/12
    人生において「出来ない」ことは物理法則以外存在しません。「やる」「やらない」ジャッジを自分が選択しているだけです。やりたいことにフォーカスして「やる」判断を、自重要でないことは「やらない」ジャッジを
  • 日米でエンジニアの育成戦略が正反対だと気付いた話 - メソッド屋のブログ

    今週は、Thanksgiving はお休みムードなので考える時間や、自分のについてディスカッションしている バンクーバーのえんじに屋さんのPodcast なんかを聞かせていただいたりしてるうちに、思い出したことがあって、記録に残してみることにした。それは、エンジニアの育成方針でこれはめっちゃくちゃ違うことに気づきましたので、シェアさせていただきたいと思います。 日米でエンジニアの育成戦略が正反対だと気付いた話 採用の段階での違い 良く知られているように、新卒のケースで考えると、こちらの場合は「コンピュータサイエンス」の学位を出ていることが前提で、中途採用の場合も、「コンピュータサイエンス」の学位を出ている、もしくはそれ相当する知識が求められる。だから、新人でも少なくともプログラムが結構組めることを期待されます。 一方、日では文系でも理系でもプログラマになれます。採用されたときに「スキル

    日米でエンジニアの育成戦略が正反対だと気付いた話 - メソッド屋のブログ
    isrc
    isrc 2023/11/27
    アーキテクチャや設計などが誰でも最初から経験でき、経験無いエンジニアでもガンガンに難しいことにチャレンジして実装して、保守します。インターンでも結構主要な機能の開発とか任されることもあります。
  • 令和の時代に本を読む必要はあるだろうか? - メソッド屋のブログ

    私は好きの人間であるが、最近はめっきりを読む機会が少なくなった。技術を学ぶなら pluralsightとかのビデオのコースもあるし、Webの公式ドキュメントも充実している。よしんばを読んでも紙ではなくKindle が多い。ブックマークもつけれるし、サーチもできるし、老眼にもやさしい。ってもうオールドファッションのメディアじゃないだろうか? 最近を書く機会があって、そんなことを考えたので久々にはてなのブログのほうで考えたことを書いてみたい。 を書くべきかどうかの葛藤 私は米国のマイクロソフトで Azure Functions というサーバーレスのサービスの開発者として勤務している。アメリカで働いているので日を書こうとか全く考えていなかったが、ある日文藝春秋の山さんが突然コンタクトをとって来て「を出しませんか」と言われた。私は普段はnoteで自分の学んだことを、自分の

    令和の時代に本を読む必要はあるだろうか? - メソッド屋のブログ
    isrc
    isrc 2023/11/06
  • 批判が少しだけ上手くなる方法を考えてみた [最終回] - メソッド屋のブログ

    職場が変わって、前の職場と比べるとよりインターナショナルになりました。今はアメリカ人の人はいてなくて、インド、メキシコ、ロシア中国、エジプト、ブラジルかなりインターナショナルです。 前回私は批判についての気づきをシェアしましたが、今までのブログの中でも1、2を争うぐらいに多くの人に読んでいただいたみたいです。そのリアクションの中で、多く含まれたコメントが「批判」と「非難」「中傷」はちがうというコメントが多くありましたの、今回はそのトピックに関して書いてみたいと思います。 simplearchitect.hatenablog.com 反対意見や批判が全くつらくない職場 私がアメリカに移ってから職場が2つ目ですが、今まで反対意見を言われたり、批判をされたときに心がつらくなったことがありません。日にいたときを思い起こすとそうではなくて、批判や、反対意見を聞くと正直心がつらいと思っていました。

    批判が少しだけ上手くなる方法を考えてみた [最終回] - メソッド屋のブログ
    isrc
    isrc 2020/07/05
    今の評価制度に代わって人と「競争」がなくなったのが効いているようです。ゴールの達成、人を助けたということで評価されます。「コラボレーション」を目指しているのが、現在の快適な職場環境をつくっているのかも
  • 批判の文化が日本を技術後進国にしているかもしれないという話 - メソッド屋のブログ

    先日、接触確認アプリがリリースされました。これは正直日のソフトウェアの進歩に画期的なことだったと思います。私も衝撃を受けました。 www.mhlw.go.jp その後起こったことに関して正直は私の感想はこの通りです。 日で起こっている地獄を見て、アプリ開発者は海外に流出してしまうわって思う。あの流れは最低最悪。みんな自分が気持ちよくなるためだけに、自分の国の未来を破壊してるんやで。— TsuyoshiUshio (@sandayuu) June 21, 2020 このような展開は、私が今住んでいるアメリカでは発生しない事案だと思います。じゃあ、日米でどういう違いがあって、日人の自分が小さな一歩を踏み出して、日がよりよい国になるようにできるとしたらどんなことだろうということを考えてみましたので、あまりソフトウェアの専門用語を使わない形で書いてみようと思います。 接触確認アプリが生まれ

    批判の文化が日本を技術後進国にしているかもしれないという話 - メソッド屋のブログ
    isrc
    isrc 2020/06/22
    アメリカには「コントリビュート」するという文化がある/一方日本では「責任の追及」や「批判」、いったい何の貢献になるのでしょう/何よりもアプリをインストールすることも貢献だと思います
  • 世界規模のクラウド「中の人」の働き方 - メソッド屋のブログ

    現在私は、世界規模のクラウドの中の人になって一か月が経過しました。グローバルで、クラウドプラットフォーム自体を作って運用する側はどんなスタイルで開発されているのか興味がある人もあるかもしれないと思ってブログを書くことにしました。これは自分のチームや周りのチームを観察しただけであって、私の所属会社全体がそういうスタイルではないかもしれませんが、何らかの参考になるかもと思い書いてみました。 スモールチーム 世界規模のグローバルなシステムなので、ものすごい大人数で、ものすごく厳密に開発されているイメージがあるかもしれませんが、実際のところ小さなチームの集まりです。自分がアジャイルコーチだったころに学んだことですが、開発は25人ぐらいのチームがマックスで、Amazon でも two pizza team といわれているように、ソフトウェア開発は少人数でないとまわらないのでそうなっているようです。沢

    世界規模のクラウド「中の人」の働き方 - メソッド屋のブログ
    isrc
    isrc 2020/05/25
    個人事業主スタイル/オンコールと呼ばれる、お客さんから上がってきた障害報告のみに対応する週間/「できるもの」として扱うと、みんなちゃんとできる/日本にいるときは自分の実力以上にチャレンジしていなかった
  • ガチ三流エンジニアが米国マイクロソフトのドリームチームのメンバーになれた話とそのためにやった事 - メソッド屋のブログ

    私は卑下しているわけではなく、ガチでプログラミングの才能が無い。他に才能があるといわれる分野は持っているが、プログラマとしてはガチで三流だ。 そんな私が、今でも夢のようなのだけど、長年あこがれた米国マイクロソフトのドリームチームのポジションを得ることができた。今回はどうやってそのポジションをゲットすることができたかについてシェアしてみたい。 ガチの三流プログラマ 私はガチでプログラミングの才能が無い。プログラミングを始めたのは確か、10歳ぐらいだろうか?だからキャリアはスーパー長い。三流というのは謙遜ではなくて、自分と過去に仕事したことがある人なら知っていることだと思う。私には人より出来ることもある。それはコンサルティングだったり、アジャイルや、DevOps のコーチ、そしてエヴァンジェリストだ。日のマイクロソフトではプレゼンは必ず上位だった。私は過去を振り返ると、何回もプログラマになろ

    ガチ三流エンジニアが米国マイクロソフトのドリームチームのメンバーになれた話とそのためにやった事 - メソッド屋のブログ
    isrc
    isrc 2020/04/23
    希望のポジションがあったらApplyすることです。当たり前に聞こえるかもしれませんが、Applyしなければ絶対受かりません。しかし、今になって思いますが、これが最も重要です。
  • アメリカのエンジニアと仕事をするときに日本人エンジニアがやったら良さそうなこと - メソッド屋のブログ

    前回のブログの最後で少し触れましたが、今回はアメリカエンジニア仕事をしていて感じたコミュニケーションの大きな違いについて書いてみたいと思います。 私はアメリカのシアトルでソフトウェアエンジニアをやっていますが、日人の人と仕事をするときに求められるコミュニケーションのスタイルと、アメリカのスタイルがものすごく違う点があって、 今も苦労しています。 そんな中でも自分が気づいて改善中のポイントについてシェアしたいと思います。今回の対象は「アメリカ在住のエンジニア」ではなくて、「アメリカ人の」エンジニアの感覚の違いです。同じ英語圏でも文化が違うので、今回は英語の話ではなく、文化的な違いと思ってください。 日ではコミュニケーションが得意だったのにまるで通用しない 私は日にいるときは元コンサルタントですし、プレゼンをするとマイクロソフトでも常に上位でしたし、お客さんをエンゲージするのも非常に

    アメリカのエンジニアと仕事をするときに日本人エンジニアがやったら良さそうなこと - メソッド屋のブログ
    isrc
    isrc 2020/04/18
    アメリカの人とコミュニケーションをとるときは、最初から全部説明ぜず、「情報量を減らす」というのがものすごく重要/これは良しあしではなく、文化/「その場で吸収できることを最大化したい」という感覚
  • 米国から一時帰国して「老害」がなくなるといいなと思った話 - メソッド屋のブログ

    米国に移住して一年が経過した。正直なところ日のほうがいいところはめっちゃある。特に生活面は、日はホンマに素晴らしいと実感している。ただ「職場環境」は米国に圧倒的に負けていると思う。たとえ英語のハンデを背負ったとしてもこちらの方が圧倒的に快適だ。日に一時帰国して感じた違和感とその分析、対処策について考えてみた。 日で感じた「違和感」 日を出た1年前と比べると、働き方改革の成果か、多くの人が日の職場環境に疑問を抱くようになっていてそれはとても素晴らしいことだと思う。ただ、一方でインターネット上の議論を読んでいると、今まで圧倒的な「権力」を持っており、ある意味表面上は「尊敬の対象」だった「年齢の高い人」が「老害」や「昭和」などとバッシングされているのを見て非常に違和感を感じた。私も来年早々50だし、昭和だし、日に帰ってきたら年齢で就職できないから自分で会社やるしかないかなとかぼんや

    米国から一時帰国して「老害」がなくなるといいなと思った話 - メソッド屋のブログ
    isrc
    isrc 2020/01/01
    米国では、職場において年齢で区別されるというのが全くない。人を「叱る」ような人も見たこともない。指示待ちの人とかは存在しない。それは得な選択肢ではないから。GOD以外は「人」なので偉い人もくそもない。
  • アメリカで、ソフトウェアエンジニアの日本人がインパクトのある仕事をする方法 - メソッド屋のブログ

    アメリカ移住してもうすぐ4ヶ月ぐらいになるけど、こちらに来てから面白いほど成果が出ていない。 最初の2ヵ月ぐらいはなんやかんやで仕事にならんやろうなと思っていたから、気にもしなかったが、そろそろ4ヵ月なので、流石に焦りを感じて来た。何一つ仕事が完了しない。日仕事をしていた時はこんなことは発生しなかった。こっちの方が一緒に働いている人が同じタイムゾーンだし、近いし、やりやすいはずなのに何故だろう?焦っていても何も改善しないので、直接仕事をしているクリスと、日エンジニアの先輩の河野さんに話を聞いてみた。自分の会社限定かもしれないけど、学んだことの記録と、もしかすると誰かの役にたつかもしれないから書いておこうと思う。 仕事が完了しない焦り 何だろう、この仕事の完了しないっぷりは。いくつか、終えたらインパクトがある仕事があるのだが、これがまた完了しない。一緒に働いているエンジニアの人はみ

    アメリカで、ソフトウェアエンジニアの日本人がインパクトのある仕事をする方法 - メソッド屋のブログ
    isrc
    isrc 2019/03/28
    メールでダメならメッセ、こちらから会議を設定、それでダメなら直接乗り込んで。ただし、相手に尊敬を持って/常時大阪のおばちゃんレベルの厚かましさになる/周囲の人をリソースとして考える/マネージャを使う
  • アメリカに住んで初めてわかった「最大級」の違い - メソッド屋のブログ

    昨年の年末にアメリカ移住して、今はシアトルの近くの Kirkland というところに住んでいる。大体三か月たって、いろんなことを体験した。移住した理由は単純で、コンピューターサイエンスの世界ではアメリカがどう考えても一番進んでいるので、そこで修行して通用するようになったら楽しいかなと思ったからだ。他にも他国の人を観察しているととても生産性が高い。特にアメリカの人は生産性が高い傾向が高い。なんでこんなにアメリカはコンピューターの世界が向いているのだろう?その一旦を感じた気がしたので久々にこのブログを書いてみることにした。 Kirklandの風景 自分へのご褒美を買う アメリカ移住すると、当然日にいる友達とかと会えなくなる。私は一人でもさみしくない人だけど、さすがにこたえるだろうと思った。だから大好きなバンドをまたやろうと思った。ただ、こっちは正直レベル高いし、私はヴォーカリストだから、

    アメリカに住んで初めてわかった「最大級」の違い - メソッド屋のブログ
    isrc
    isrc 2019/03/12
    こんなタフなことを起こっても全員が「絶対にできるよ」とか、「これ、めっちゃいいやつだよね!」「つよしが、ヴォーカルブースでエンジョイできることを楽しみにしてるよ」とか、どんな立場の人でも言ってきた。
  • メタファーを身につけてプログラミングの生産性を向上させる - メソッド屋のブログ

    インターナショナルチームでプログラミングの仕事をしていると、いろんなところで同僚との差を感じてしまう。いろんな国の人がいて、レベルは人によりそれぞれなんだけど、一般的にいうと、アメリカのプログラマのレベルは平均してとても高い場合が多い。とにかくコードがきれいでシンプルで仕事が早い。 彼らがなぜそれができるのかを観察しているが、一つ気が付いたことについてその対策も含めて書いてみたい。 彼らがプログラマとして優れているところ USにいるとお客様の技術レベルが高いとか、新しいことにチャレンジするとかいろいろ要素はあるのだけど、個人の生産性、コードの美しさをみても、平均値を観察するとアメリカの人が一番に感じる。その他にも、ドキュメントを見てすぐ理解できる能力は、アメリカの人はおろか、ヨーロッパ圏やインドの人と比べても、私は圧倒的に負けていると感じる。 Williams 衝撃の読解力 新しいライブラ

    メタファーを身につけてプログラミングの生産性を向上させる - メソッド屋のブログ
    isrc
    isrc 2018/07/23
    アメリカのプログラマはとにかくコードがきれいでシンプルで仕事が早い/コードに書かれている英単語の意味が「ふわっと」しか分かっていないのでは?/コードに出てくる単語を英英辞書で調べるとかなりすっきりする
  • 日本のITエンジニアがイノベーティブでないのは暇じゃないからかもしれない - メソッド屋のブログ

    ここ1ヶ月ぐらいは、海外のメンバーと仕事をしているが、Serverless Hackfest というイベントと、Serverless Conf やワークショップに関わっているので仕事量が増えていった。日にいることだし、久々に「日流」のハードワークをしてしまったのだが、一つ気づいたことがあった。それは、ここしばらくの謎だった、日人のIT エンジニアはなぜイノベーティブな感じがしないのか?ということに対する問いだった。 Microsoft Hack week 日人はイノベーティブ Rochelle Kopp さんとの仕事で知ったことで、一つとても意外だったことは、アメリカ人から見ると日人は相当にイノベーティブに感じるらしい。 自分的には、少なくともIT 分野に関しては、向こうの真似ばかりしていて、後追いのイメージがある。私たちも向こうで生まれたツールやサービスばかり使っていて、全然日

    日本のITエンジニアがイノベーティブでないのは暇じゃないからかもしれない - メソッド屋のブログ
    isrc
    isrc 2017/11/06
    働き方改革を待つより転職して海外の企業を体験するのはどうだろう。今まで「常識」で「無理」と思っていたことが平気で実現されている世界に触れると、「あー、あれって不可能じゃなかったんだ」と思えるようになる
  • 技術なきマネジメントの衰退とその対策 - メソッド屋のブログ

    今回は、マイクロソフトにいて自分が感じているIT業界の大きなスタイルの変化の兆候とその対策について書いてみた。今回もいつも通り、単に自分の意見をシェアしているだけであって、他の人にどうこうしろと言いたいわけではない。ただ、日IT業界が米国に追いつき、追い越すための議論のきっかけになるといいなと思っている。自分も楽しみながらも、もがいていることと、そこで見えた光について書いてみたい。 世界は「技術力」の重視に向かっている 私のキャリアは、某大手SIerを12年勤めた後、ITコンサルティング企業に3年在籍して、主に超上流を実践した。その後独立し、ビジネスモデリングから、アジャイルや、DevOpsの導入支援、マネジメント、開発などを実施していた。 私がマイクロソフトを受けてみようと思ったのは、友人からの推薦の要素が大きかったのだが、その背景では、海外で勤務したいという希望があったのと、「技術

    技術なきマネジメントの衰退とその対策 - メソッド屋のブログ
    isrc
    isrc 2017/06/19
    プレゼンとか、デモとかの重要度が下がって、「ガチの問題を一緒に解決してくるれる技術イケメン」への需要が高まっている/部長も課長も全員お客様の所でコード書いてバリュー出せるレベル/Mob Programmingの衝撃
  • 英語技術ブログのちょっとしたテクニック - メソッド屋のブログ

    tumblrにアカウントを作って、世界に知ってもらいたい日の開発シーンの情報をたまにブログしてみようと思い立ちました。 ブログの第一号は、顧客、経営者、開発者の3者のWin-WIn-Winを達成して、私が興味津々の、ソニックガーデンさんのビジネスモデルについて書いてみました。もし良かったらご覧ください。(そして、よかったら拡散してくださいw) Keep it simple — No Delivery, No Due Date, No Fixed Scope さて、この過程で下手でもいいので、英語技術情報発信してみよう!と思ったのですが実際にやってみると、当に難しかったです。多分喋りの1000倍ぐらい難しいと感じました。しかもブログなので、残ってしまいます。私の英語の師匠のお力を借りてなんとか仕上げましたが、彼が私の文をレビューしてくれて、いろいろテクニックを伝授してくれましたので、私

    英語技術ブログのちょっとしたテクニック - メソッド屋のブログ
    isrc
    isrc 2017/05/28
    文法的に正しいかどうかのチェックは最近様々なサービスが出ています/事実と自分の意見を混ぜない/繰り返しを避ける/シンプルな表現を心がける/ナチュラルな表現を採用する
  • ネイティブに伝える為のロジカルさとは? - メソッド屋のブログ

    イギリス人のプレゼンテーション/ヴォイスコーチのChristianeから指導を受けているが、彼女とのディスカッションの過程でネイティブに対してわかりやすくしゃべる為には、ロジカルさが必須だと実感した。その顛末と気づきを共有したい。 1. イントロダクション Christianeとの出会い 私は昔から音楽が好きで昔はヴォイストレーニングに行っていた。また音楽をしたいなと思ってまたヴォイストレーニングをやってみようと思っていた。そんな時に、PechaKucha 20x20 - Tokyoという六木で毎月やっているプレゼンテーションのイベントに参加していた。英語をガチで使う機会を求めて、英語のプレゼンが聞けるし、外国人の人が沢山来ているこのイベントはとても自分にとって楽しいイベントなのだ。自分は結構人見知りなので、「今日は自分から話しかけてみる!」というノルマを課していたが、自分が1人出来てい

    ネイティブに伝える為のロジカルさとは? - メソッド屋のブログ
    isrc
    isrc 2017/05/28
    日本人は「具体例」の方がわかりやすいと感じる傾向にあると思う。逆に定義なんて普段の生活でそんなに重要視していない。でも少なくとも彼女は、具体例の前に「明確な定義」が必要なようだ。
  • プレゼン作成の効率化について考えてみる - メソッド屋のブログ

    職業柄講演資料を作る事というのは結構多い。しかし、毎回困るのがホンマに時間がかかることだ。今回はベトナムで英語で講演という事がなんと1週間前に決まったので大慌てで作った。しかも日とソフトウェア開発の事情が違うから一から作り直ししかも英語というわけで、結局2日徹夜した。 多分これは英語云々のお話ではなく私はそもそもプレゼンテーションを作るたびにこんな事をやっている。ホンマにしんどい。なんとか効率化できんものやろか?ということで、Facebook等でつぶやいているといろいろありがたいご指摘をいただいた。 私がプレゼンテーションに求める要件 私がプレゼンテーションに求める要素は三つある。必要十分にシンプル/カスタマイズ可能/かっこよさだ。 私はプレゼンテーションZENスタイルはあまり好きじゃない。すっごくかっこ良くて、プレゼンとして聞いている分にはとてもいいんだけど、後から見たらキレイさっぱり

    プレゼン作成の効率化について考えてみる - メソッド屋のブログ
    isrc
    isrc 2017/03/20
    結局のところ、ガチの要約力が必要/マスタースライドのフォントサイズを40以上にする/自分の今の実力でプレゼン作る
  • 生産性を向上させるためには、日本人エンジニアに英語での会話力は必須だと思った - メソッド屋のブログ

    私はマイクロソフトのインターナショナルチームで働いています。特に私は以前からUSのエンジニアの生産性の高さの秘密を学びたいと思っています。今回は同僚からの何気ない一言からの気づきをシェアしたいと思います。 David からの何気ない一言 私は無宗教で葬式の時は曹洞宗なのですが、以前から聖書には興味がありました。私の叔父はドイツアメリカに長年住んで仕事 をしていました。そんなガチに海外で生活していた彼が言っていました。 彼らの文化を理解したかったら聖書を読むのがいいよ 確かにイギリスにいた時もあらゆる場面で、日に帰っても海外映画を見ても様々な場面で、聖書の影響を感じます。 私は自分の仲間をより理解したいし、明るさ、生産性の高さ、芸術性などを当に尊敬しているので、是非ともその考えを学んでみたいと思っていました。 私の尊敬する同僚の David もクリスチャンなので、彼にどの聖書を読んだ

    生産性を向上させるためには、日本人エンジニアに英語での会話力は必須だと思った - メソッド屋のブログ
    isrc
    isrc 2017/03/20
    「ディスカッション」の目的は「お互いが持っている意見を交換して、知識や考えを深めること」/どっちが正しいとかまったくもってどうでもいい/「自分の理解を助けてくれてありがとう」といったノリ
  • 新技術導入を米国並みに!働き方を変えて生産性を高めるための8つの習慣 - メソッド屋のブログ

    クロスカルチャーの専門家のロッシェル・カップさんと共同でマイクロソフトの投資の元作成した「働き方を変えて生産性を高める8つの習慣」だが、動画シリーズが完成したので、各習慣の動画をここで整理しておきたい。楽しんでもらえる内容になっているので、是非楽しんでご覧ください!また、すべての項目について、私が過去にこのブログで書いた、各習慣に関するポストへのリンクを整理しておいたのでブログの集大成になっている。 元々シリーズは、日でも、DevOps や Agile を米国並みに実践したいという考えから考察されたものですが、働き方を変えて変化対応性と、生産性を向上させるためのもので、どなたにも楽しんでもらえる内容になっております。早速各習慣のビデオをご紹介させてください。それぞれ10数分以下のサイズになっています。 序章:イントロダクション 8つの習慣をなぜ作成したのか?どういう効果があるのか?と

    新技術導入を米国並みに!働き方を変えて生産性を高めるための8つの習慣 - メソッド屋のブログ
    isrc
    isrc 2017/02/13
    クロスカルチャーの専門家のロッシェル・カップさんと共同でマイクロソフトの投資の元作成した「働き方を変えて生産性を高める8つの習慣」だが、動画シリーズが完成
  • 「無理を承知で」のお願いが「無駄」を生む - 不確実性を受入れる 第3の習慣 - メソッド屋のブログ

    仕事の習慣・考え方を変え生産性や新しい技術の導入を米国並みに加速する「8つの習慣」のうち「不確実性を受入れる」に関して考察した。具体的な実践プラクティスを踏まえ言及してみたい。 ご興味があれば、是非以前にご紹介した第一、第二の習慣に関してもご一読されるとよいかもしれない。 不確実性を受入れる マネージメントは詳細まで細かく練られた計画を期待しない。 予算と報告のプロセスは精密な結果の予測を要求しない。 内部プロセスは計画や優先順位の変更に柔軟である 事前に全ての問題分析が完了せずとも新しい事に挑戦する姿勢を持つ システムとプロセスは柔軟で、複数の頻繁な変更を受入れられる 学びに基づいて、変化を精力的に行う。 この習慣は日人の最も苦手とするところのうちの一つかもしれない。しかし、変化に柔軟に対応する必要のある分野特にソフトウェア開発の分野では最も理解し、実戦して練習しておいたほうがよいと思

    「無理を承知で」のお願いが「無駄」を生む - 不確実性を受入れる 第3の習慣 - メソッド屋のブログ
    isrc
    isrc 2017/01/30
    マネジメントは詳細まで細かく練られた計画を期待しない/予算と報告のプロセスは精密な結果の予測を要求しない/事前に全ての問題分析が完了せずとも新しい事に挑戦する姿勢を持つ/複数の頻繁な変更を受入れられる