超巨大クラウドのシステム開発現場を行動観察。ガチ三流プログラマが米国システム開発の現状をリークする話（1） Regional Scrum Gathering Tokyo 2022 代表的なアジャイル開発手法であるスクラムをテーマにしたイベント「Regional Scrum Gathering Tokyo 2022」が、1月5日から7日までの3日間、都内およびオンラインのハイブリッドで開催されました。 そのクロージングセッションとして行われたのが、現在シアトル在住でMicrosoft Azureの開発を担当している牛尾剛氏による「アメリカの超巨大クラウドの中の人に転生したガチ三流プログラマが米国システム開発の現実をリークする話」です。 本記事ではほぼ90分におよぶセッションの内容を、前編、後編（1）、後編（2）の3本に分けて紹介します（この記事は後編（1）です）。 前編では、子供の頃からプロ
こんにちは。NewsPicks プロダクトチームの文字です。今日はプロダクト開発組織のチームビジョンを作ったら、すごいパワーが生まれた話をさせて頂きます。 「経済を、技術でもっとおもしろく。」 今年の春、NewsPicks のプロダクトチームでは、こんなチームビジョンを作りました。実は NewsPicks のタグラインは「経済を、もっとおもしろく。」なので、会社の掲げるタグラインをほぼ踏襲しているように見えます。しかし一見凡庸なこのビジョンが、実はとても大きなパワーを秘めていたのです。 1/ なぜビジョンをつくったのか 増大し続ける技術的負債と運用負荷 組織の急拡大 2/ みんなでビジョンをつくる 合宿の開催 腹落ちできるビジョンが完成 3/ ビジョンをつくったら、どうなったのか？ ビジョンはパワー 4/ これからのプロダクトチーム 1/ なぜビジョンをつくったのか そもそも、何故こんなチ
ソフトウェアのレビュー 先日はバグを見つける事について話した． 今日もちょっと関連してソースコードのレビューについての話だ． プログラマであるわたしはプログラムを作る．それと同時にバグも作る．一番いいのはバグを作らない事だが，残念ながらだれしもバグは作る．どのようにしてバグを作り込むかを分析すればひょっとしたらバグを埋め込まないプログラムの作り方を発見できるかもしれないが，現時点での研究もバグに関する理解も進んでいないので当面はバグはそこにあるものだという前提で物事をすすめていかないといけないであろう．とはいうものの，バグの少ないコードを書くプログラマも世の中にはいる．できればそのコツというかノウハウを学びたいものであるが残念ながらそれはある種黒魔術のようなもので素人には手が出せない神秘である． バグを埋め込んだのならそれをできる限り早く発見してできる限り早く修正したい．ソースコード１００
学生時代にソフトウェア工学を学び、オブジェクト指向分析/設計に傾倒。執筆活動や講演、ハンズオンイベントなどを通じてテスト駆動開発を広めようと努力している。 『プログラマが知るべき97のこと』（オライリージャパン、2010）監修。『SQLアンチパターン』（オライリージャパン、2013）監訳。『テスト駆動開発』（オーム社、2017）翻訳。『Engineers in VOYAGE』（ラムダノート、2020）編者。テストライブラリ power-assert-js 作者。
「共同創業者になってくれるエンジニアを探している」と起業家（準備中含）から相談されてだいたい同じことを回答してる気がするので僕の考えを書きます。 想定読者・起業を考えていて自分自身はエンジニアではない ・試したい仮説はあって、検証するためにはプロダクトを開発する必要がある ・現在、コミットしてもらえるエンジニアもいない ・どういうエンジニアを探せばいいかわからない 結論 結論から書きます。 検証するためのプロダクトをあなた自身で書いていきましょう。 創業者が優秀なエンジニアになれという話ではなくて、 一人目のエンジニアを採用するためには自分自身でプロダクトを作るのが一番の近道という話です。 ソフトウェア開発について一定の理解を得ることができる ソフトウェアの開発を行う時にどういうことを考えて、結果どういうものを作っていくかのフローを一度経験しておくことにより、 エンジニアを採用した後に自分
こんにちは。JetBrains 堀岡です。 JetBrains では、近年世界中の開発者をターゲットとした「The State of Developer Ecosystem（開発者エコシステムの現状）」と呼ばれる年次サーベイを行っています。 2020年版の調査結果は以下のサイトで公開されています。 この調査結果において、「世界とのトレンドは分かったが、日本のトレンドはどうなんだろう？」と興味を持たれた方もいるのではないでしょうか。 このブログポストでは、JetBrains のリサーチチーム の協力を得て、日本の開発者からの回答と、（日本以外の）世界の開発者から回答の比較を行います。加えて、考察（というよりは個人的な感想かもしれません）、 JetBrains 関連のトピックについても紹介します。 開発者の属性 今回の比較に用いられたサーベイの回答数は以下の通りです。 日本からの回答数:623
Facebook、社内のデフォルト開発環境にVisual Studio Codeの採用を表明。マイクロソフトと協力してリモート開発機能の強化も推進 Facebookは社内のデフォルト開発環境として、マイクロソフトがオープンソースで開発しているコードエディタ「Visual Studio Code」の採用を発表。あわせて、マイクロソフトと協力してVisual Studio Codeのリモート開発機能について強化を推進していくことも明らかにしました。 下記はFacebookのブログ「Facebook and Microsoft Partnering on Remote Development」から。 We’re making Visual Studio Code the default development environment at Facebook and teaming with Mi
前書き 「一緒に働いている以上、プログラマのことを理解して仕事をしたい」そう考えている企画・ディレクションの方は経験則的に少なくない。 ノンプログラマから見て、プログラマの仕事はイメージが湧きづらく、何故その工程にそこまでのコストをかける必要があるのかわからない事が多い。 プログラマは作業の必要性を説明してくれるかもしれないけれど、専門用語も多いしイマイチピンとこなかったりする。 ここで重要なのはまさに「イメージ」だと思う。すなわちイメージを提供するための良質なメタファーだと思う。メタファーが良質であれば より直感的に理解できる。 実際メタファーの力はバカにならない。「Chef」も「Jenkins」も それぞれ 統一的な世界観が学習者の直感的な理解を後押ししてくれる。 というわけで、今回から数回に分けて なるべく「技術的な話」をせずに イメージを想起しやすいストーリーを導入することで プロ
デキるプログラマだけが知っているコードレビュー7つの秘訣 7つの秘訣の1〜5は本当にそのとおりだと思います。 「怒り」って言葉を使っているところはなかなか画期的だと感じた。というのも僕は前から「人格攻撃に思われて」しまうような、コードで人を殴るようなことをしてしまう人が出てきてしまうのは何故かということを考えた時に、そこには「コードに対する怒り」があるからだろうなと思っていたからである。怒りがあるからこそ強く指摘しすぎてしまうことが起こりうる。 「怒り」というのはつまり「感情」である。であれば、「その『怒り』はコードに向けられたものであり、書いた人に対してのものではないので、その人に対しての攻撃ではない」というのは、理屈ではかろうじて通るかもしれないが、書いた人の「感情」的には通らないこともあることは理解したほうが良いと思う。 じゃあ怒らなければ良い、という話にはしたくなくて、どうしても怒
IT業界の世代間ギャップを「ロードマップ指向 VS エコシステム指向」という図式でまとめるとうまく整理できるような気がしてきた。 他の業界でも、常に勉強してないと仕事にならない所では、似たような問題があるかもしれない。普通の人は「ロードマップ」の中では真ん中を進むべきで、「エコシステム」の中では真ん中を避けるべきだ、という話。 私は、80年代からずっとプログラマをしていて、今でも現場でコードを書く仕事をしているので、同世代の人から、彼らと現場の若い人との仲裁役というか通訳のようなことを期待されることが多い。 確かにそこには微妙なギャップがあって、自分はどちらの言い分にも共感する所があるので、なんとかそれを言葉にしたいのだが、なかなかうまく言えなかった。 プログラマという仕事は、今も昔も勉強をしてないと普通の仕事も成立しないのだが、その勉強の仕方というか意味づけが、違ってきていると思うのだ。
用語は形式的なものではなく感覚的なものであることをお断りしておきます。 言語・フレームワーク・プラットフォーム まず最初に触れるものでとっつきやすい。何か使えないことには話になりません。多くの人が、勉強というとまずここ。 何かすでにつかえる人が新しく勉強することは、生産性をあげない。そのプラットフォームを初めて採用するときの準備が減らせる。どちらかというと仕事の選択肢を増やす感じですね。 深く知ることは、最適なコードを書きトラブルを減らしトラブルが起こったときの対策も早くなるので、生産性があがります。ただ、ある程度の深さ以降は生産性への寄与度がさがるので、その点では深くまで勉強する必要はありません。 プロダクトの使い方なので、プロダクトの寿命が勉強成果の寿命です。実際に使わないものの勉強は無駄になるし、使われなくなったら無駄になる。寿命もそう長くないです。 「プログラマは勉強してもすぐ使わ
前回のエントリで、プログラマの業界が労働集約的なものと知識集約的なものにわかれてきているという話を書きました。 プログラマ業界の二分化 - きしだのはてな 前のエントリでは労働集約的なものと知識集約的なものに完全にわかれているように書きましたが、もちろん完全に労働集約的であったり完全に知識集約的であったりすることは少なく、どのような組織でもある程度は両方の性質をもっています。知識集約的な性質の強いSI会社というのもあります。 ただ、SIに労働集約的な、サービスに知識集約的な性質が強くなる傾向はあると思います。 また、知識集約的であればよくて労働集約的であればダメということもありません。労働集約的なSIでありながら良い会社というのもあります。 という断りをいれておかないと、SIで労働集約だからといって全部ひとからげにするなという、労働集約的なSIでありながら良い会社方面から鋭利なマサカリが飛
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
