そりゃまるっきりダメですヨ。 ぜんぜんそんなこと考えられない人でしたヨ。 （藤森照信「焼け跡のプレハブ住宅：前川國男とプレモス」）建築家・前川國男（1905-1986）について、前川建築事務所で働いたキャリアを持つ建築家・大高正人は、こう証言しています。この証言は、戦後日本を代表する建築家・前川の設計による木質パネル量産住宅「プレモス」がなぜ売れなかったのかを語る場面での言葉です。精魂込めて日本の復興を託し設計した「プレモス」は、100万人の住まいをめざした高いクオリティを持ちながら、惜しいことに「売ること」へ関心が及ばず、広く普及することはなかったと語るもの。 同じくプレモスに関わった建築家・田中誠も、次のように証言します。 ああいう量産住宅を工場でちゃんと生産するには毎月必ず一定量の受注が確保されなければいけない。ところが、プレモスには販売体制がないから受注が安定しない。だって、前川さ

週刊少年ジャンプで（以下TPGW）が最終回を迎えた。 ぶっちゃけあまり面白い話ではなかった。 終盤の数話なんかもう予想を一切外れない展開が続くばかりだった。 ……そう、終盤の数話は予想が完璧についてしまったのだ。 なぜ予想がついたかと言うと、この漫画、エンタメとしての面白さほぼ全てと引き換えに異常なまでに布石伏線の張り方が丁寧なのだ。 やるべきことを殆ど全部事前に口にしている。怖い。 殆ど自己言及だけで構成されていると言ってもいい。 毎話のクリフハンガーと辻褄が合っていくと言う部分の面白さだけでやっていこうとでもしてんのかってぐらいだった（まあ結局やっていけなかった訳だし打ち切りは残当である）。 正直連載中めちゃくちゃ怖かった。 何が怖かったかって、振り返ると次々と辻褄が合いまくっていくのに、それが全然解ってないのか整合性に文句言う感想をかなりの量見かけたことだ。 いやこれはアンチは目が曇

目的AWS CodeBuildのbuildspec.ymlをローカルでテストできるようにします。 手順概要1. CodeBuildで利用するDockerイメージをビルドする 2. codebuild_build.shを設定する 3. buildspec..ymlを記述 4. ビルドを動かす 手順詳細1. CodeBuildで利用するDockerイメージをビルドするAWS CodeBuildで提供されているDockerイメージをビルドするために、aws/aws-codebuild-docker-imagesをcloneします。 $ git clone git@github.com:aws/aws-codebuild-docker-images.git公式githubリポジトリからのclone 今回は、aws/codebuild/amazonlinux2-x86_64-standard:3.0

プログラミング上達したいんだったら、四の五の言わずに、 ・クリーンアーキテクチャ ・レガシーコード改善ガイド ・アジャイル・サムライ ・リファクタリング 系のどれか を、全部最低5回読み返して欲しい。それでプログラマとしては圧倒的に成長できるんだから、マジで読んで — Next.js + Hasura 最速プロトタイピング本 @技術書典9 出す予定 (@erukiti) July 27, 2020 先日、こういうツイートをしたらバズってしまいまして。これらの本を理解できるまで読みこめばプログラマとして成長できますよーというもので、 ・ クリーンアーキテクチャ ・ レガシーコード改善ガイド ・ アジャイルサムライ ・ リファクタリング 系のどれか（例えばリファクタリング第二版） の4冊を挙げました。いろいろな人の感想を読んで、補足が必要そうだなと思ったので記事として書きなおしています。 追記

ちょっと前に1兆円の大台にのったB2BのECの雄、MonotaRO（モノタロウ）。時価総額1.1兆円、東証一部上場ランキングは106位。祖業のB2BのEC一本でひたすら拡大し、コングロマリット化している楽天1.3兆円に肉薄しつつあります。 株式会社MonotaRO（モノタロウ）は、兵庫県尼崎市に本社を置く事業者向け工業用間接資材のEC/通信販売会社。wikiはこちら 売上成長率20%、営業利益成長率23%と、絶好調が継続です。年間1500億円規模の売上でこのスピードがすごい。すごいというか、ありえないです。スタートアップ初期の10億円や上場直後規模の100億円ではなく、1000億円を超えていて、まだこのペースが落ちないのですよ。成長の率を維持するから、冒頭のグラフのとおり世界中の投資家に愛される「綺麗な二字曲線」です。（だから1兆円を突破しています） なぜこんな離れ業が出来るのか。長年不思

前回、成功したエンジニア組織の施策について書きましたが、今回は失敗編です。失敗のほうが多いのでどうしても文量が多いのですがご勘弁下さい。 説明用に前職の関係記事がガンガン出てきますが、貶めたり咎める意図は全くありません。あくまで僕が責任持って実施した施策で失敗したことについてのノウハウ共有と反省についての記事です。 組織施策プレゼン大会 ※元記事がお亡くなりになっているのでWayback Machineより [概要] 組織施策についてチームごとにプレゼン。プレゼン毎に担当役員＋組織責任者(僕)が点数評価。点数が一定以上の場合施策実行をその場で採択。 内容は、課題提起→施策内容→実行体制→スケジュール→予算→まとめ。 [導入背景] エンジニア組織の人数が増えて組織硬直が進んでいたこと、全員の目線を合わせる機会があまり無かったことから、メンバーの不満が見えないレベルでたまり続けていました。 メ

この文書は、ある組織において、ある一つの Ruby on Rails で書かれたサービスの全部または一部を、(言語A) で書き直したい、という proposal に対して qsona が表明した意見の文を、一部手直ししたものです。このサービスは、現在担当しているチームとは別の人が初期実装をしたものであり、現在はまだ小規模ですが、今後新しいチームの手により発展していくもので、現在の規模のうちに要件や新しいチームメンバーに最適な言語で書き直すという選択は十分合理的です。また、この組織内のコードは、Ruby on Rails で書かれているものが大半であり、さらに組織としてマイクロサービスアーキテクチャの方向を目指している、という前提の上でお読みいただければと思います。もちろん文責は qsona 個人にあり、qsona の属する組織の意見とは関係ありません。 ------------------

はじめにまずこの話をするのにあたって「正しい見積り」という伝承を語らねばならない。 次の章は、筆者が観測してきた100社ほどの開発関連会社におけるトレンドを雑に集約したものなので、当然ながら観測者バイアスがかかっている。 したがって、ITエンジニアのみなさんご自身の体験とはだいぶ違う事もあるかもしれない。その点はご了承願いたい。 ところで、カンブリア爆発のように、ある事柄がきっかけて急激に世界が変わっていくことは産業界にもよくある。 たとえば蒸気機関の登場が産業革命を引き起こしたように。 また、システム開発にも古代と現代を区切るほどのエポックメイキングな出来事が一つあると思っている。 それは「GitHubの台頭」。 本論では、この古代のことを「前GitHub時代」と呼ぶことにする。 ※厳密に言えばGitHub以外にも様々なソースコード共有サイトやリポジトリシステムは存在した。が、それらをコ

（この記事はVPoE handbookの目次＆サマリパートです） 以下で書き始めを宣言してから進捗が悪思わしくなかったhandbookですが、ようやく書き終わりました。 数えるといつの間にか合計30,000字ほどになり、意外とボリュームが増えてしまったので、少しずつ読みやすいように章ごとに記事にしています。 目次はこの記事の目次部分、もしくはこちらのマガジンの一覧からご覧ください。 この記事自体ではその目次と簡単な解説をつけ、ざっくりと全体像を知り、詳しく読みたい気になる記事を見つけやすくするような構成で書いていきたいと思います。 （この7月からは開発マネジメントのキャリアとはまた違った方向に進みだしたので、賞味期限切れギリギリ?!になりましたがなんとか整理も終わりました。） VPoE handbookを書こうと思った理由まずはなぜ書こうと思った？の問題意識から。 この記事にあるように、三

LeanとDevOpsの科学［Accelerate］は、数年にわたる科学的で厳密な調査研究を基に、組織のパフォーマンス向上を促すケイパビリティを示した書籍です。 LeanとDevOpsの科学［Accelerate］ テクノロジーの戦略的活用が組織変革を加速する impress top gearシリーズ www.amazon.co.jp ■デリバリーパフォーマンス(Four Keys)●従来の評価尺度の問題 組織レベルの目標達成に役立たない「忙しいが価値のない、見せかけの作業」を大量にこなした者を報奨するやり方では、混乱の壁を招いてしまう。作業量ではなく、グローバルな成果に焦点を当て、チームの協働を報奨する新たな尺度が必要。 ●望ましい尺度 ・デプロイの頻度 ・変更のリードタイム ・MTTR ・変更失敗率 ●2017年時点の統計値※書籍を参考に作成 ●2019年時点の統計値※State of

数年前にQiitaに書いた記事の大幅アップデート版です。 このシリーズは情シス何もわかんないけど、1人目の情シスを採用し、一緒に情シスを作り上げていく、そんなマニュアルです。1人目の情シスが採用できたあとは、一緒にこれを読んで実行に移してみてください。 全部で4つの記事に別れています。 - 採用、マネジメント　→　この記事はコレ - 戦略づくり（ルール、業務基盤） - 戦略づくり（セキュリティ） - 戦略づくり（BPR / 業務改善）→ ※内容薄すぎた場合作成しないです そして、本記事をレビューしてくれた某分家コミュニティの人たち、そしてより良いものにしようとコメントくださった、おかしんさん、ゆりねえの二人に感謝を。 想定読者 * 情シスがいない企業で情シス立ち上げを行おうとする人（CTOなど） * 1人目の情シスとして入社して、これから立ち上げを行っていく人 ※世の中のすべての情シスを知

全国1000万人のITエンジニアのみなさん、おはこんばんにちわ。 最近「わかりやすい絵を書け」とデザイナーにいじめられて四苦八苦している、はまあです。 以前のエントリの「スキルが上がれば報酬は上がるのか？」がいまいち伝わりにくかった気がするので、ほとんど主旨は同じですがもう一回語っていきます。 素敵な世界おそらく多くのITエンジニアの皆さんは、給与とスキルの関係はこんなイメージを持っているのではないでしょうか？ スキルが上がるとどんどん給料が上がる。素敵な世界観ですね！ 世の中こんな感じだったらいいんですけどね。 現実残念ながら、現実はこう。 見ての通りですが、どんなにスキルを磨こうとも、あなたがその会社にいる限り、なにをどうしようとF社の給料ほどはもらえません。 この「能力に応じて給与が払える幅」を俗に給与レンジ（給与テーブル）と言い、ほとんどの国内企業は社員の評価（役職、スキル、経験年

こんにちは、ネコ派メタラーです。ナビタイムジャパンで地点検索基盤の開発マネジメントを担当しています。好きなバンドは Arch Enemy です。 システム運用に関わる人であれば、「システム障害」というと耳が痛い方が多いかと思います。システム障害は起こさないに越したことはないですが、万が一システム障害が発生したとき、その行動選択はサービスの信頼性を大きく左右することになります。 迅速に復旧させることはもちろんですが、適切な情報公開によってユーザーの不安を払拭するといったコミュニケーションも重要なポイントです。しかし、緊急事態というプレッシャーを受けながら最適な行動を選択することは容易ではありません。 私が所属しているチームでは、Web API サーバソフトウェアから全文検索ミドルウェアまで含めた開発・運用を行っており、幅広いトラブル対応スキルが必要になります。トラブル対応のスキルを持ったベテ

視座が高いってそもそもなんやねん問題 1on1で「視座を上げてほしい」って言われたり、マネージャー陣の集まりで「視座高い人がいいよね」って会話をしたりするけど、じゃぁ「視座の高いってなんぞ？」「どう見極めればええのん？」ってなりますよね。 自分も前職でエンジニアリングマネージャーしてた頃から、現職にて横断組織の一環として採用にかかわるようになって良くそれらのセリフを聞いております。 で、これが正解ってわけじゃないんですけど、自分はいつもこんな感じで可視化してますよってのを紹介してみます。 「視座が高い」を端的に言うと 自分は「視座」ってのは一言でいうと「どのレベルの課題まで、当事者でいられるか」っていうスタンスの度合いだと解釈しています。 ここで言っているレベルというのは難易度ではなく対象のスコープのことです。個人の課題なのか、チームの課題なのか、はたまた所属する会社の課題なのか。 で、「

3万円台で買えるThinkPad E495を知ってるか？？によってユーザーが一気に増えた気がするThinkPad E495ですが、実機がようやく私のもとに届きました…。 My new gear... 早速換装をしたいそう、皆さんあえてダウングレードをして安く買っているため、別途メモリーやSSDを購入しているかと思います。 まだ買ってなかった人はこのあたりから見繕ってね ・8GBメモリー 8GBx1構成にした人はこれ1つで8GBx2=16GBへ メモリーは速度が2400以上の物を選んでください。 Crucial ノートPC用 メモリ PC4-21300(DDR4-2666) 8GB SODIMM CT8G4SFS8266【永久保証】 [並行輸入品]amzn.to

パソコンというモノは不思議なヤツで突然生えてくるんです…困ったもんだな。 今回はレノボで今最もアツいThinkPad E495の魔の手にとうとう私も堕ちてしまったので紹介します。ほら、給付金もあるし。 ThinkPad E495ってどういうマシンなのか 執筆時点で簡単に言えば ・ThinkPadシリーズで一番安いクラス、テンキー付きのE595もある。 ・在庫限り ・AMD APU（第2世代Ryzen Zen+ / 12nm）を採用していて速い。 ・後継機種のThinkPad E14 Gen2価格コムモデルが発売、でもまだ買える。 ・拡張性が失われつつあるThinkPadの中で自由度が高い（M.2+2.5inch / メモリー2スロット）。 ・重量1.75kg～と持ち運びは無理ではないがちょっと重い（MacBookPro 15インチクラス相当） 久しぶりにE495について調べる人向けな情報と

この記事は自分が予備知識ゼロで無線LANを最新のWIFI6換装して起きたトホホを知見として共有しようと思って書いた記事です。 ■はじめに事の発端はebayを眺めていたら802.11axの規格のカードが安く売っているのが目に止まったからであった。 自分はMINIPCを所有していてAtheros AR5B22というカードが乗っていたのだが802.11a/b/g/nまでしか対応していないのであまり使う気がしなく有線でつないでいた。 最近の802.11axの規格のカードINTEL AX200 NGWが売られているのをみて載せ替えができそうだと思い付きで換装しようと思った。 AX200はインテル販売の純正品も技適マークはパッケージの箱にのみ印刷されているだけでモジュール自体には印字されていないようです。

前回のQAとお医者さんに続き、これも何かの結論がでるような感じではなく、ポエムですが。。。 ISQTBのFLシラバスでのQAについての記述JSTQBのFL2018シラバスにて、「1.2.2品質保証とテスト」という節があります。そこでは冒頭以下のように書かれています。 品質保証（または単にQAともいう）という用語がテストを意味するために使われることがある。しかし、品質保証とテストは、関連してはいるが同じではない。 While people often use the phrase quality assurance (or just QA) to refer to testing, quality assurance and testing are not the same, but they are related. 上記は、QAとテストは同じじゃないって書かれている該当節の冒頭部分です。

こんにちは！SUGAR株式会社のCTOをしている杉谷と申します。SUGARという生放送システムを作っています。 “SUGAR is 何” については社長の鎌田(UUUM社長でもある)が https://note.com/sugarcorp/n/n2f3a0fe1a107 で解説していますので、よろしければご覧ください！ はじめに昔(もう13年前)にも生放送システムを作ったことがあったんですが、当時は技量と知見が足りず今みたいに便利なサービスやツールも無かったので負荷に弱く、数万人のユーザーが殺到すると落ちる、なんてことが頻繁にありました。 それから11年後、いろいろあって人生2度目の生システムであるSUGARを作ることになりました。今度こそはとガッチガチに負荷対策をしたところ某人気俳優の方の配信で三十数万人が一瞬で殺到してもなんとか死なない※システムを作ることができました。 ※正確には最初

DX（デジタルトランスフォーメーション）という単語について、巷で多く聞かれるようになり、自分のもとにも様々ご相談をいただくことが増えてきた。また、マーケティングワード的な使われ方に対する批判など色々と聞かれるようになってきている。こうしたバズワードを強く押し出した記事を書くことはあまり好まないのだが、多くの企業においてソフトウェアがより導入され生かされる好機であると見てDXについて書いてみようと思う。 下記の元同僚のツイートが執筆のきっかけとなるが、自分なりのDXについての解釈を整理し簡単に示しておくことで、今後DXについてご相談に来られる方やDX推進される方々の参考になれば幸いである。 俺たちがちゃんと継続的リファクタをできていればDXなんて不要で、もっと緩やかなイテレーションでトランスフォームしていたはずなのだ。 — Seiji Takahashi - timakin (@__tima