三流プログラマがなぜ米マイクロソフトの開発者になれたのか？ ガチ三流プログラマが超巨大クラウドの中の人に転生した話。Regional Scrum Gathering Tokyo 2022
三流プログラマがなぜ米マイクロソフトの開発者になれたのか？ ガチ三流プログラマが超巨大クラウドの中の人に転生した話。Regional Scrum Gathering Tokyo 2022 代表的なアジャイル開発手法であるスクラムをテーマにしたイベント「Regional Scrum Gathering Tokyo 2022」が、1月5日から7日までの3日間、都内およびオンラインのハイブリッドで開催されました。 そのクロージングセッションとして行われたのが、現在シアトル在住でMicrosoft Azureの開発を担当している牛尾剛氏による「アメリカの超巨大クラウドの中の人に転生したガチ三流プログラマが米国システム開発の現実をリークする話」です。 子供の頃からプログラマになることを目指しながらも、同僚からは「プログラミングの才能がない」とはっきり言われるなど、自分はガチの三流プログラマだと称する
システム開発で曖昧な要望を形にしていく方法 - arclamp
このブログはグロースエクスパートナーズ Advent Calendar 2021の10日目です。 社内メンバーから要望があったので、僕自身がどのようにシステム開発の初期段階において、どのように要望を整理し、形にしていっているのかについて書きたいと思います。 なお内容は弊グループの案件を前提にしているので、システム開発は以下のような状況が一般的です。 クライアントは直接契約（プライム） 要望を出すのはクライアント企業内で事業運営側の人で、システム開発にかかわった経験がないことがある 対象システムはSoE/mode2で、一般消費者や取引先などの外部ユーザーと、社内で業務を回す内部ユーザーがいる 相手の話を整理するフレーム まず、相手から得られる情報を4つの階層にわけて整理する必要があります。 目的：達成すべきこと 戦略：目的を確実・効率的に達成するためのシナリオ 戦術：戦略を実行するための具体
日米OSDN離合集散、苦闘の21年史
さて、ついに退職エントリだ。私は米国のオープンソース・ムーブメントを日本で再現するためのコアを作るために民間企業へやってきたはずだった。それから21年、随分と長い航海になってしまったが、結局様々な尻拭いを続けてきたという感慨ばかりが起きてくる。一つの歴史として書き残すいいタイミングなのでその苦闘を振り返っておこう。 なお、長く付き合いが続いてしまう米国側法人は下記のように名称が変化している。なるべく頭に米国と付けて日本側法人と区別しやすいように記述するが、突然名称が変わったりするので注意してほしい。多くがもはや消滅した法人のことなので、さすがに一気読みするような酔狂な人はほぼいないと思うが。 VA Research Andover.net ↓ ↙︎ (VAによる買収) VA Linux Systems ↓ ↘︎ (Andoverから社名変更) VA
SDGsは達成不可能な理想なんかではない
少し開発にかかわったことがあるものとして、SDGsに関して思うところを述べます。 まずはSDGsが制定されるまでの歴史から。 アジア金融危機、LTCM破綻、ロシア金融危機などいわゆる国際金融資本による危機が続発していた１９９０年代後半のことです。IMFや世界銀行は苦境に陥った国と人々を支援しようとしたのですが、型にはまったアドバイスは役に立たないどころか状況を悪化させてしまうこともありました。NPOが世界銀行を取り囲んでデモをするなど、世界中で、先進国中心の開発援助と国際金融機関に対する疑いが強まってきた時代です。 そういう時代背景を踏まえて、世界銀行やIMFが上から開発援助の方向を決めるのではなく、NPOや途上国の声をもっと取り入れ、共に追求できる目標を設定しようという考えから生まれたのが、２０００年に国連総会で制定されたMDG(ミレニアム開発目標)です。いくつかのテーマがあるのですが、
Four Keys 〜自分たちの開発レベルを定量化してイケてる DevOps チームになろう〜
はじめに この記事タイトルに興味をもって読み始めていただいている方の多くは、ソフトウェアエンジニアとしてチームで開発をしていたり、エンジニアリングマネージャーとしてチームビルディングやマネジメントをされている方なのではないかと思います。 実際、この記事を書いている加藤も、リクルートライフスタイルのデータプラットフォームグループ (以前は CETチーム と呼ばれていました) に所属するデータエンジニアとして、データ活用のための基盤開発・運用を行っている一人です。また、担当している社内データプロダクトのプロダクトマネージャーも兼任しています。 本記事では、自分の所属している DevOps チームを「イケてる DevOps チーム」にするために取り組んだ内容や気づいた点をお伝えしたいと思っています。 目次 はじめに 「イケてる」DevOps チームってなに？ Four Keys とは なぜ Fo
「ITの開発現場によくいるやっかいな人」の対処法をタイプごとに解説したサイトが登場
ソフトウェアの開発プロジェクトにはさまざまな経歴や役職を持つ人が関与するので、我が強い人や性格に難がある人が問題になることもしばしば発生します。ソフトウェア業界のよもやま話を語るブロガーのニール・グリーン氏が、ソフトウェア開発プロジェクトの中で問題になりがちな人をタイプごとにまとめつつ、それぞれのタイプの特徴と管理職向けの解決策を解説しました。 How to Deal with Difficult People on Software Projects https://www.howtodeal.dev/ 上記のサイトにアクセスしたのが以下。上から「プロダクトマネージャー」「デザイナー」「プロジェクトマネージャー」「開発マネージャー」「開発者」「品質保証(QA)」の6カテゴリに分かれていて、それぞれの役職の中によくいる「問題のある人」のタイプが動物のアイコンで示されています。例えば、「プロ
リモートの Linux サーバを開発環境にする
これまで Macbook Pro を開発環境としていたんだけど、価格は高いし Docker for Mac は重いしでいいことないなということで Linux の開発環境に移ることにした。前職の最初の数年はすべて VM（当初は jail）にログインして開発していたのでその頃に戻った感じ。ただ GUI は macOS が何かと楽なので Intel NUC を購入して自宅に置いてリモートでログインして使っている。Core i7、メモリ 64GB で10万ちょいと安いのにめちゃくちゃ快適でさいこう。 ここからは備忘録としてリモートを開発環境とするうえで実施した作業を残す。あと作ったものもあるので宣伝。 外部からログインしたい自宅以外からも使うだろうということで（最近京都からリモートで働くこともあり）、VPN サービスとして Tailscale を導入した。 Best VPN Service for
技術的負債とステークホルダと説明責任と / The Debt
Talked at CloudNative Days Spring 2021 Online #CNDO2021. https://event.cloudnativedays.jp/cndo2021/talks/801
Hironori Funabiki on Twitter: "米ファイザーと独BioNTechの新型コロナウイルスに対する革命的なmRNAワクチンの接種が明日から始まるが、このワクチン開発にいたるまでの経緯が実に感慨深いので紹介してみる。まさに、大逆転ストーリー。1/22"
米ファイザーと独BioNTechの新型コロナウイルスに対する革命的なmRNAワクチンの接種が明日から始まるが、このワクチン開発にいたるまでの経緯が実に感慨深いので紹介してみる。まさに、大逆転ストーリー。1/22
グーグル元同僚が共同創業、“じゃんけん”も余裕な低遅延・等身大のビデオ会議システム「tonari」
むこはた・わかこ／書店員から出版社、Web制作会社取締役、米系インターネットメディアを経て独立、現在は編集・執筆業。IT関連のプロダクト紹介やベンチャー経営者インタビューを中心に執筆活動を行う。 From DIAMOND SIGNAL スタートアップやDX（デジタルトランスフォーメーション）を進める大企業など、テクノロジーを武器に新たな産業を生み出さんとする「挑戦者」。彼ら・彼女にフォーカスして情報を届ける媒体「DIAMOND SIGNAL」から、オススメの記事を転載します。※DIAMOND SIGNALは2024年1月をもって、ダイヤモンド・オンラインと統合いたしました。すべての記事は本連載からお読みいただけます。 バックナンバー一覧 東京・渋谷区のスタイリッシュなオフィス。取材に訪れるとすぐ“壁の向こうの和室”から「こんにちは、ようこそ！」と声がかかった。遠隔地同士を、空間が隣接してい
COEってご存知ですか？
皆さん、こんにちは。皆さんはCOEってご存知でしょうか？初めて聞いた、言葉は聞いたことがある、もちろん知っている等々、様々な反応があるかもしれません。今日はそんなトピックについて少し書いてみたいと思います。 既にご存知の方には繰り返し、釈迦に説法、になるかもしれませんが、COEはCenter Of Excellenceの略です。この言葉の由来は1940～50年代にまで遡り、米国カリフォルニア州のスタンフォード大学で当時多くの優秀な学生が東海岸へ流出してしまうことを防ぐため、全米から著名な教授・スタッフを呼寄せ、学究拠点の中心とする施策から来ているようです。その後、様々な大学や研究機関での施策・拠点として発展、企業においても優秀・有識なリソースを集約し組織運営を向上化・効率化するという形で適用され、ITの分野でも使われるようになったと理解しています。要は、会社の中でシステム化を進めていく際に
ITインフラのオープンな開発を推進する「Open Infrastructure Foundation」が発足。OpenStack Foundationの後継として
ITインフラのオープンな開発を推進する「Open Infrastructure Foundation」が発足。OpenStack Foundationの後継として オープンソースのクラウド基盤「OpenStack」の開発などをホストしている「OpenStack Foundation」は、10月19日から23日までオンラインで開催中のイベント「Open Infrastructure Summit 2020」で、同団体の後継となる新団体「Open Infrastructure Foundation」の発足を発表しました。 キーノートで「Open Infrastructure Foundation」の発足を発表し、乾杯するOpenStack Foundation Executive DirectorのJonathan Bryce氏（左）と、COOのMark Collier氏（右） OpenSta
『2時間スプリント』とフルリモートワークなシステム開発 - terurouメモ
デンキヤギという会社で『2時間スプリント』が定着してきたので、その話でも書きます。 2時間スプリント？ みなさん、すでにスクラムで開発してますよね！ ぶっちゃけ、スクラムがよくわかってなくても、とりあえずスプリントと称して開発のメリハリをつけるために、1週間なり2週間なりで区間を区切って開発をしていくのは、普通にやってるんじゃないかと思います。 2時間スプリントとは、その期間を2時間にするという話です。 スプリントを超短期サイクルにすること自体は、47機関の人たちがオリジナルだという認識です。このあたりに本家の情報がまとまっています。 kyon-mm.hatenablog.com 2018年に実際に47機関の人たちのチームに入って1時間スプリントで働くという機会があって、それ経て、デンキヤギでもパクって導入しています。本家ではのちのち15分スプリントになっていったらしいんですが、うちはうち
コンテナ・デザイン・パターンの論文要約 - Qiita
Brendan Burns, David Oppenheimerらの論文「Design patterns for container-based distributed systems」を読んで、コンテナを活用したシステム設計や開発に、とても有用と感じたので、図を中心にした要約にしてみた。 要約内容に誤りや理解不足な部分もあると思うので、原文も参照していただきたい。また、自身の理解のために、論文中に無い図を加えた点、独自の注釈も加えている。 背景 コンテナ化されたソフトウェアコンポーネントから構築されたマイクロサービスアーキテクチャの人気が高まり、分散システム開発においても同様の革命が起っている。 コンテナの境界の壁は、分散システムの基本的なオブジェクトの境界に適している。そこで、コンテナを活用して、コードの低レベルの詳細を抽象化し、アプリケーションやアルゴリズムに共通する高レベルのパター
転職1年の近況報告 - じんめんメモ
早いもので昨年の8月1日に転職してから1年経ちましたということで近況報告です。 現在のポジションは社内のプライベートクラウドのSREです。クラウドの利用者(=アプリ開発チーム)からの問い合わせ対応やトラブルシューティングだったり、クラウド基盤の開発の支援やキャパシティ管理、安定運用のためのあれこれをやっています。 クラウド基盤はサーバ仮想化、ネットワーク、データベース、ストレージ、ロードバランサ、コンテナなど幅広い分野のコンポーネントで構成されているわけですが、私は「突出した得意分野がないけどだいたいそこそこわかる」おかげでトラブルシューティングの一次切り分けが得意だったり、複数の開発チームやデータセンタ管理チームと話が通じやすい、のようにうまく強みにできている実感があります。 ばりばりコードを書いて開発するという感じでもないですが、運用のためのスクリプトやツールをそこそこ書いています。P
【JTF2020】凡人エンジニアの生存戦略
【CICD2021】デプロイメントパイプラインの原理原則を再確認する / Confirm Deployment Pipeline Principle
何故お役所ってオワコンIEが大好きなの？｜楠 正憲（デジタル庁統括官）
普通は役所のシステムって構築してから5年とか7年は塩漬けにして使うもので、一度やらかしてしまうと名誉挽回の機会なんて向こう数年は与えられないんだけど、こと本件に関しては高市総務大臣から「今すぐ私がマニュアルなしでも使えるように直しなさい」と叱責いただいて、しっかりと予算的なサポートも得られたことで、たったの数ヶ月で立て直すことができた。 この数ヶ月は外部のセキュリティやPKIの専門家の方から様々なサポートをいただいて何とか実現したんだけれども、役所のシステム開発としては非常識というか、極めて難易度が高い案件だった。「え？単にChromeやSafariをサポートするだけでしょ、難しい訳ないじゃん」と思う諸兄は、もうしばらくこの話に付き合って欲しい。 もともとマイナポータルは日本を代表するITベンダーと通信キャリアの3社が開発したんだけど、大臣からの叱責を受け「ちゃんとお金を払うから直してよ」
ご主人様、小難しいDDDやクリーンアーキテクチャはお忘れになって、”削除しやすい設計”から始められてはいかが？ - Qiita
ご主人様、小難しいDDDやクリーンアーキテクチャはお忘れになって、”削除しやすい設計”から始められてはいかが？LaravelDDD設計アーキテクチャCleanArchitecture ある日夢の中で設計に詳しい悪役令嬢が現れてこんなことを言い放ったので、考察してみましたという設定のポエムです。 問題提起 ドメイン駆動設計、オニオンアーキテクチャ、クリーンアーキテクチャといった考え方はもちろん重要なものの、僕は難しく考えずに「削除しやすいように機能を作る」のが第一歩として重要ではないかと考えています。 本記事では「削除しやすい設計」について持論を展開してみます。 ※議論のスコープはWebサービスに限定し、例示としてPHPのフレームワークであるLaravelを用います 削除しやすいことがなぜ重要か 一度開発した機能は、それで終わりではなく、改修、改善を繰り返し、そして場合によっては仕様が廃止さ
メルペイ立ち上げの裏側 – 決済サービス開発のゼロイチ話
はじめに こんにちは。メルペイのPayment PlatformチームでPaymentServiceの開発を担当するエンジニアの @foghost です。この記事は、Merpay Advent Calendar 2019 の21日目の記事です。 3年前、ソーシャルゲーム業界からメルカリに転職してから、幸運なことにゼロイチで決済サービスの開発に関わることができて、エンジニアとしても人生としてもとても充実の3年間を送りました。 そして、今、日本ではすでにキャッシュレスブームが始まっていて、これからFinTechの領域で様々な革命が起きていくと思っています。この記事では私がエンジニアとしてこれまでに決済サービスの開発に関わってきたことを振り返り、これからFinTechに関わりたい方への参考になればと思います。 社内向け決済基盤の検討 メルカリに入社してすぐ、当時社内ID基盤を開発していたPlat
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
大企業アジャイルの勘所（ver1.1） #アジャイルマネジメントセミナー
