タグ

ソフトウェア開発とmicrosoftに関するisrcのブックマーク (10)

  • アメリカの職場ではなぜドキュメントも無いのに人が去っても問題ないのだろう?|牛尾 剛

    アメリカの職場にいると、日にいるときよりも身近でレイオフだとか、職を変えるというのを頻繁に見かける。先日もそういう場面があったのだが昔日で働いていた時のことを思い出した。 ドキュメントを書く理由 日のソフトウェア企業にいたときは、「納品物であるから」という理由以外にも、「人がいなくなったときに会社が困るから」という理由でもドキュメントを書くことが推奨されていた。しかし、少なくとも今の職場ではそんな理由でドキュメントを書くのは推奨されていないのに、なぜ問題にならないのだろうとふと思った。 うちのマネージャは、バディ制ににして、みんな休暇できるようにしようとは言っているが、多分当に退職対策ではないと思う。 チームのメンバーが抜けたときも、「とても残念で、ワークロードをどうしようという問題はあるけど、彼女の門出を祝福しよう」言っていた。つまり、こちらでも「工数」は問題になるけど、「引継ぎ

    アメリカの職場ではなぜドキュメントも無いのに人が去っても問題ないのだろう?|牛尾 剛
    isrc
    isrc 2023/06/21
    日本にいたときには誰も触れない塩漬けのシステムとかもよく見かけた。ぶっちゃけそれは設計がいまいち/こちらでは全員が専門性を持っているので、「誰でも書けるコード」に寄せることはしない。
  • 超巨大クラウドのシステム開発現場を行動観察。ガチ三流プログラマが米国システム開発の現状をリークする話(2) Regional Scrum Gathering Tokyo 2022

    超巨大クラウドのシステム開発現場を行動観察。ガチ三流プログラマが米国システム開発の現状をリークする話(2) Regional Scrum Gathering Tokyo 2022 記事は「超巨大クラウドのシステム開発現場を行動観察。ガチ三流プログラマが米国システム開発の現状をリークする話(1)」の続きです。 日エンジニア層と米国のエンジニア層の違い 次はエンジニアのレベルっていう話です。 これはもう僕のイメージなんですけど、日のエンジンニアは、もちろん技術力の高い人がたくさんいます。 たくさんいるんですけど、ある一定以上のレベルになると人数がすごい減るっていうイメージがあります。 アメリカの場合は、別にエンジニアがすべて優れているとは思っていませんが、基的に一定のレベルが担保されてる感があって、みんな普通にオブジェクト指向とか、関数型とかDIであるとかデザインパターンとか、そうい

    超巨大クラウドのシステム開発現場を行動観察。ガチ三流プログラマが米国システム開発の現状をリークする話(2) Regional Scrum Gathering Tokyo 2022
    isrc
    isrc 2022/01/18
    日本ではイノベーションが起こらない、なんでか? とよく言われますけど、単純に技術とか経験の差なんじゃないかなと僕は思います。基礎知識があるから僕らは余分なことに工数を使わなくていい
  • 超巨大クラウドのシステム開発現場を行動観察。ガチ三流プログラマが米国システム開発の現状をリークする話(1) Regional Scrum Gathering Tokyo 2022

    超巨大クラウドのシステム開発現場を行動観察。ガチ三流プログラマが米国システム開発の現状をリークする話(1) Regional Scrum Gathering Tokyo 2022 代表的なアジャイル開発手法であるスクラムをテーマにしたイベント「Regional Scrum Gathering Tokyo 2022」が、1月5日から7日までの3日間、都内およびオンラインのハイブリッドで開催されました。 そのクロージングセッションとして行われたのが、現在シアトル在住でMicrosoft Azureの開発を担当している牛尾剛氏による「アメリカの超巨大クラウドの中の人に転生したガチ三流プログラマが米国システム開発の現実をリークする話」です。 記事ではほぼ90分におよぶセッションの内容を、前編、後編(1)、後編(2)の3に分けて紹介します(この記事は後編(1)です)。 前編では、子供の頃からプロ

    超巨大クラウドのシステム開発現場を行動観察。ガチ三流プログラマが米国システム開発の現状をリークする話(1) Regional Scrum Gathering Tokyo 2022
    isrc
    isrc 2022/01/18
    マネージャが自分の仕事やキャリアを助けてくれる/マネージャの大事な仕事「アンブロック」/基本的に納期の設定はない。マネージャも急かさない/僕の上司で僕よりもプログラミングができない人はいない
  • コロナ接触を通知する日本版「接触確認アプリ」を作ったのは誰か?…「6割普及」への挑戦

    厚生労働省は現在、新型コロナウィルス感染症(COVID-19)の“感染が疑われる濃厚接触”を通知する「接触確認アプリ」の開発を進めている。 開発を受注したのは日国内のベンダー。一部で「米マイクロソフトが受注した」と報道されたが、これは間違いだ。とは言え、マイクロソフトが無関係というわけではない。そこには多少事情がある。 実は、日で使われるアプリのベースとなる部分は、個人が中心となったボランティアベースのプロジェクトで、オープンソースとして開発されたものを利用している。 そのアプリは、なぜオープンソースで開発されたのか? そして、そこに人々はどう関わっているのか、開発にかかわった関係者を取材した。 接触確認アプリがどういうものか、おさらいしておこう。 接触確認アプリは、スマートフォンのBluetooth機能を使い「一定以上の長い時間、スマホを持っている人同士が近くにいた」情報を記録するア

    コロナ接触を通知する日本版「接触確認アプリ」を作ったのは誰か?…「6割普及」への挑戦
    isrc
    isrc 2020/06/22
    核となっているのは、個人を中心に集まって開発されたオープンソースのプロジェクトだ。ビ起点になった開発者は日本マイクロソフト廣瀬一海さんだ。社員としてではなく、個人の活動としてコミュニティに参加している
  • Today was a Good Day: The Daily Life of Software Developers

  • 世界規模のクラウド「中の人」の働き方 - メソッド屋のブログ

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

    世界規模のクラウド「中の人」の働き方 - メソッド屋のブログ
    isrc
    isrc 2020/05/25
    個人事業主スタイル/オンコールと呼ばれる、お客さんから上がってきた障害報告のみに対応する週間/「できるもの」として扱うと、みんなちゃんとできる/日本にいるときは自分の実力以上にチャレンジしていなかった
  • Secure the software development lifecycle with machine learning

    Every day, software developers stare down a long list of features and bugs that need to be addressed. Security professionals try to help by using automated tools to prioritize security bugs, but too often, engineers waste time on false positives or miss a critical security vulnerability that has been misclassified. To tackle this problem data science and security teams came together to explore how

    Secure the software development lifecycle with machine learning
    isrc
    isrc 2020/04/22
    We discovered that by pairing machine learning models with security experts, we can significantly improve the identification and classification of security bugs.
  • 新技術導入を米国並みに!働き方を変えて生産性を高めるための8つの習慣 - メソッド屋のブログ

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

    新技術導入を米国並みに!働き方を変えて生産性を高めるための8つの習慣 - メソッド屋のブログ
    isrc
    isrc 2017/02/13
    クロスカルチャーの専門家のロッシェル・カップさんと共同でマイクロソフトの投資の元作成した「働き方を変えて生産性を高める8つの習慣」だが、動画シリーズが完成
  • 中島聡氏が語る、世界で戦えるプロダクトリーダーを生む4つの条件【キャリアごはんvol.1レポ】 - エンジニアtype | 転職type

    エンジニア同士が交流し、ごはんと悩みをシェアしながら 仕事人生の次の一手を探るためのワークショップ型イベント「キャリアごはん」のイベント情報やイベントレポートを紹介します 日々の仕事に追われて普段はなかなか考える機会のない「ひとつ上のキャリア」について、ごはんをべるように自然に考えてもらいたい——。そんな想いを込め、エンジニアtypeと「今よりもっと満足できる仕事」との出会いを応援する姉妹サイト『@type』は共同で、新たにワークショップ型イベント『キャリアごはん』を立ち上げた。 第1回は9月29日、東京・青山にある『Royal Garden Cafe青山』で開催し、約60人のエンジニアが参加する形となった。テーマは、【Web・アプリサービス「次のデファクト」を生む現場リーダーになるには?】。MicrosoftWindows 95/98開発のチーフアーキテクトを務めた中島聡氏と、国内企

    中島聡氏が語る、世界で戦えるプロダクトリーダーを生む4つの条件【キャリアごはんvol.1レポ】 - エンジニアtype | 転職type
    isrc
    isrc 2015/10/11
    Windows 95ですが、仕様書と呼べるものはわずか2ページしかありませんでした。その2ページに、どんな商品を作るのかが10項目ほど書かれているだけで、後はエンジニアが自由に作ることが許されていたのです。
  • 「戦略的OS」の開発がことごとく失敗している点に関する一考察

    90年代にIBM、MicrosoftApple各社が巨額の開発費を投じて作っていた「戦略的OS」がすべて失敗してしまったことを皆さんはご存知だろうか? IBMが作っていたのはOS/2。元々はMicrosoftとの共同開発だったが、途中で仲違いをしてしまい、最後はIBMだけが細々とサポートしていたことすら覚えていない人が多いとは思うが、Windows95の成功であっというまに市場から消えてしまったのがOS/2。具体的な数値は公開されていないので分からないが、両社が数百人体制で数年間開発していたので、少なく見積もっても日円で数百億円は投じられたことは間違いない。 Cairoの方は私自身が初期のころにいたこともあるし、最終的には「Chicago(Windows95のプロジェクト名) vs. Cairo」の戦いの最前線にいた私としては知りすぎている点も多いのだが、一つだけ確かなのは、プロジェク

    isrc
    isrc 2009/04/05
    結局のところ、ソフトウェア作りはアートに近くて、大企業が資金力にまかせて優秀なエンジニアを集めても無理があって、少人数で作ったものが市場原理で自然淘汰されてこそ良いものができる
  • 1