読まれない名著「人月の神話」を本気で読み込んでみた（まとめ） - GiXo Ltd.
まじめに読まれない”40年前に書かれた古文書” 人月の神話【20周年増訂 新装版】 本日は、田山花袋の蒲団と同じくらい、知られているけど読まれていない名著「人月の神話」についてご紹介します。 人月の神話とは？ 人月の神話というのは、ソフトウェア開発の”単位”である「人月」という概念が、神話に過ぎない（つまり、意味をなさない）という悲しい真実を軸に、ソフトウェア開発が如何に困難を伴うものであるかを説いた名著です。一言でいえば、10人月の仕事＝1人で10か月かかる仕事は、「人月という単位が絶対であれば”10人で1ヶ月”でできるハズ」だが、そんなことは起こりえない、というお話です。そして、この状況を打破し、遅延したプロジェクトに100人投入して一瞬でシステムを完成させるような「魔法の道具（＝狼男に決定打を与える”銀の弾”）」は存在しない*と結論付けられます。 本書は、1975年（40年前！）に初
シリコン・バレーの空気｜中島聡
この文章は、私が週一で発行している「週刊 Life is beautiful」からの引用です。ここ数年、日本の大企業の人から「どうやったらうちの会社でもイノベーションを起こせるか」という相談を受けることが増えています。 質問が「なぜ、日本の大企業はイノベーションを起こせないのか」であれば、終身雇用制、サラリーマン経営者、合議制、多すぎるミーティング、天下り、出る杭を打つ文化、膨大な時間をかけたエビデンス作り、など箇条書きにして明確な答えを示すことも可能ですが、「どうやたらイノベーションを起こせるか」の答えは簡単ではありません。 突き詰めて考えれば、イノベーションを起こすのは「こんな世界を実現したい」「こんなライフスタイルを人々に提供したい」という誰かの「熱い思い」なのです。 しかし、イノベーションのアイデアは、先進的であればあるほど、大半の人にとっては「突飛すぎて理解できないもの」であり、
「出世して取締役」の勘違い おかしな日本の企業統治 | NIKKEIリスキリング
プロ経営者の松本晃氏がカルビーに招かれてトップに就くと決めたとき、最も重視したのは経営の執行役と監視役の分離でした。経営陣と取締役会が互いに独立し、それぞれの役割をきちんと果たすというコーポレートガバナンス（企業統治）の概念は、資本主義経済ではごく当たり前の発想です。ところが、松本氏は「日本では、全然当たり前ではない」と指摘します。日本企業への企業統治の導入について聞きました。 ＜＜（6）女性管理職の比率4倍に 活躍の道、トップが力ずくで （8）改革はトップの覚悟から 抵抗勢力も「納得」で変わる ＞＞ 招いてくれた人への最初の言葉 「辞めてください」2018年に亡くなったカルビー元社長の松尾雅彦氏は創業者の三男で、カルビー中興の祖といわれた人物でした。社長を辞めた後も会長や相談役として大変貢献した。僕はその雅彦氏に引っ張られてカルビーに入ったんです。 経営を受け継ぐとき、僕が雅彦氏に言った
テスト駆動開発とマイクロサービスのせいで短命に終わったスマホゲームの話
「悪い方が良い」原則をご存じだろうか？ プログラミング言語「Common Lisp」の開発に携わったことでも知られるソフトウエア技術者リチャード・ガブリエル（Richard Gabriel）氏が1990年に発表した有名なエッセイ「The Rise of ``Worse is Better''」で主張したソフトウエア開発の考え方だ。 このエッセイでガブリエル氏は、美しく完全に設計・実装されるより、単純で雑に設計・実装されたソフトウエアの方が良いと説く。彼は前者を「正しいやり方」「MIT/スタンフォード式」、後者を「悪い方がよい原則」「ニュージャージー式」と呼び、ニュージャージー式がいかに優れているか様々な事例を挙げて説明する。 これは一見とても奇妙に聞こえる。 ソフトウエア開発では通常「美しい設計」や「美しいコード」が尊まれる。「車輪の再発明はするな」とか、「階層構造に分けて、要素をいつでも
GAFAに人材流出防げ NTTコムの新キャリアパス | NIKKEIリスキリング
GAFAに人材流出防げ NTTコムの新キャリアパスNTTコミュニケーションズの山本恭子ヒューマンリソース部長2019 / 3 / 27 若手の人材が、グーグルやアマゾンなど「GAFA」と呼ばれる米IT（情報技術）大手4社に流出してしまう――。こんな悩みを抱える日本のIT企業は多い。通信やインターネットのプロバイダー事業を手がけるNTTコミュニケーションズもそのひとつ。人事全般を担当する山本恭子ヒューマンリソース部長は「多様なキャリアパスを用意する必要がある」と危機感を募らせる。今後の対策を聞いた。 道は「管理職」だけではない 若手の選択肢増やす――日本のIT大手からGAFAへの人材流出が増えています。 「当社は離職率の低い会社として有名でしたが、この10年で上がってきています。まだ世の中の平均よりは低いですが、エンジニアだけでなくコンサルティング系の職種でも増えてきています」 「社員は6千
クックパッドのモバイルアプリ開発が「機械に人が合わせる」リリースフローに行き着いた理由
「毎日の料理を楽しみにする」ことを目指し、料理レシピの投稿、検索サービス「クックパッド」を中心にさまざまなビジネスを展開してきたクックパッド。創業20周年を経て、全世界のレシピ数は500万品、月間利用者数は約9200万人に達するほどに成長している。 クックパッドのビジネスの中心はiOSやAndroid向けのアプリだが、他にも料理という切り口から派生したさまざまなアプリやサービスを提供している。これらのリリースを適切に管理し、ニーズに応じて迅速にアップデートしていくため、同社のモバイルアプリ開発では、「機械が人に合わせるのではなく、機械“に”人が合わせる」という新しいアプローチを採用した。 2018年12月14日開催「＠IT ソフトウェア品質向上セミナー AI／機械学習、自動化で開発現場にも訪れるシンギュラリティーにどう備えるか」の基調講演では同社 技術部 モバイル基盤グループ グループ長の
NO HARD WORK!を読んだ - toyoshiの日記
NO HARD WORK! 無駄ゼロで結果を出すぼくらの働き方 (早川書房) 作者: ジェイソンフリード,デイヴィッドハイネマイヤーハンソン 出版社/メーカー: 早川書房 発売日: 2019/01/31 メディア: Kindle版 この商品を含むブログを見る この本を読んだ目的、ねらい 私はこの本を書いた人の所属するBasecamp社（旧37signals）のファンで、数冊出ている著者はこれまでも読んできました。私の創業したMisoca社が残業0だったり、リモートワークを取り入れているのもこの会社の影響です。 特に「Getting Real」や「小さなチーム、大きな仕事〔完全版〕: 37シグナルズ成功の法則」発表された時は、「小さく、より速くソフトウェアを作る」という考え方に大きく影響されて個人サービスを作る原動力になりました。 また早くからリモートワーク（強いチームはオフィスを捨てる）を
技術者よ、設計しよう、仕様書を書こう | 宇宙科学研究所
私は、昨年度、工業標準化事業に対する貢献により経済産業大臣から表彰を受けました。編集委員会から私に与えられたテーマは、それについて解説せよというものです。しかし、その技術的な内容については既に本ニュースの2004年6月号において「宇宙開発における標準化と情報化」という題名で執筆しています。そこで、今回は、私が標準規格などの文書の作成に力を入れている理由についてお話ししたいと思います。なぜならば、その理由をお話しすることは、「人工衛星のような複雑なシステムをいかに効率的に開発するか」という私のシステム工学的な研究の成果を解説することになるからです。 人工衛星のような複雑なシステムの開発は、必然的に大人数のチームで行うことになるのですが、効率的に開発を行うための一つの原則は、「チーム構成員の誰もが何かしら具体的な作業を担当し、その作業結果を文書などにまとめ、プロジェクトの中で機能させること」だ
2018年11月14日(水)“社内通貨”で働き方が変わる！？｜おはBiz NHKニュース おはよう日本
「社内通貨」とは耳慣れない言葉ですね。「通貨」とは言っても、会社の中だけで使えるポイント制度のようなものですが、この仕組みを取り入れることでさまざまな効果が得られると、最近、企業の間で注目を集めています。
ITエンジニアの仕事環境ってどうするのがベスト？相談したら逆に混乱した｜TECH PLAY Magazine［テックプレイマガジン］
こんにちは。ヨッピーです。今めちゃくちゃ悩んでおります。 今日はITエンジニアのマネジメントをしているえらい人たちと一緒に「ITエンジニアの仕事環境はどう整えるのがベストか」みたいな話をしているのですが、 議論が多すぎて全然話がまとまりません。 おかしい……！ 「やっぱこういう環境がいいよね！」みたいにすんなり決まるかと思ったのに……！ とにかく、悩んでいてもしょうがないので、今日はこのド散らかった議論を包み隠さず出すことにしました。 ITエンジニア ITエンジニアをマネジメントしている人 ITエンジニアを採用したい人 なんかの人たちには有意義なものがたくさん含まれているので、ぜひ読んでいただきたいと思います。議論に参加してくれたのは、こちらの3名の方です！ ▲バリューコマース株式会社 執行役員 最高技術責任者 伊藤信敬さん 2002年4月エー・アンド・アイシステム株式会社（現株式会社ラッ
入社2年目の若手エンジニアがものすごく優秀だったので上司が『彼を課長待遇に』と提案するも即座に却下されてしまうという日本企業の“常識的”マネージメントについての話
極端流形式仕様 初代𝕍𝕚𝕖𝕟𝕟𝕒𝕋𝕒𝕝𝕜𝕖𝕣 @tomooda 入社2年目の若手が、普通は専門エンジニア10人以上が専任で何年かかけてつくるものをほぼ一人で半年ぐらいで作ったのを上司が驚いて「彼を今すぐ課長待遇に」といっても即座に却下されるのが日本の「常識的」なマネージメント層なんですよ。初心者と同じ扱いを続けるのが日本の技術系企業なんですよ。 2018-06-30 10:16:59 極端流形式仕様 初代𝕍𝕚𝕖𝕟𝕟𝕒𝕋𝕒𝕝𝕜𝕖𝕣 @tomooda そいつが実際に課長になったのは20年以上経ってから。年収は1,000万なんて到底届かない水準。つきあい長いオレから見ても、オレが雇う側なら2,000万までなら即答で出すぐらいの専門技術者がその待遇。へー、その会社、よく技術系を名乗れるねー、と思いながら聞いてたよ。 2018-06-30 10:20:
残業手当はすぐになくしたほうがいい カルビー・松本会長
日本を代表する「プロ経営者」として、これまでにさまざまな経営改革を推進してきたカルビーの松本晃会長兼CEO。インタビュー記事の前編ではカルビーでの9年間を振り返ってもらった。今回は働き方改革にまつわる日本企業の問題点などを聞いた。 残業手当という悪しき制度 ――日本企業が取り組んでいる働き方改革を見ると、その多くは残業規制のための制度作りに注力しすぎている気がします。この点はいかがですか？ 日本の働き方において何が一番悪いかといえば、言うまでもなく残業ですよ。残業手当てという制度がある限り、問題は解消されません。 働き方改革に関しては、あながち政府が言ってることも間違ってるとは思いません。裁量労働制にしたらいい。特にオフィスで働いている人たちは、「時間」ではなく「成果」で働いているのですから。 ところが、そうした人たちに残業代を払うとなれば、そんなのするに決まっているじゃないですか。 例え
6ページの長文メモ、ベゾスも認めるアマゾンの｢奇妙な会議ルール｣
ジェフ・ベゾス氏は4月20日、ジョージ・W・ブッシュ大統領センターで開催されたイベントに登壇、自社のちょっと変わった会議について語った。 同社の会議では、練り上げられた6ページの長文メモが用意される。そして会議の冒頭で全員がそれを黙って読む。 ベゾス氏はもう何年も前にパワーポイントの使用を禁止した。同氏が考える、メモを使った会議の方がはるかに優れている理由を見てみよう。 アマゾンで幹部として働くなら、専門分野が何であろうと、文章を書くことと読むことが得意でなくてはならない。仕事に必要な会議をうまく取り仕切るために。 アマゾンCEOジェフ・ベゾス氏は4月20日、ジョージ・W・ブッシュ大統領センターで開催されたイベントに登壇した際、このやり方が｢奇妙｣に聞こえることは承知していると語った。 ｢アマゾン社内ではパワーポイントは使われていない｣とベゾス氏。 ｢外部から新たに幹部を採用したときは、『
アジャイルエンタープライズに驚いた - L'eclat des jours(2018-03-11)
_ アジャイルエンタープライズに驚いた 翔泳社からアジャイルエンタープライズが送られてきたのでありがたく読み始めた（他にもいろいろあるのだが、紙質（表紙の固さ）とか字の大きさとかが妙に具合が良かった）。 1章を読み始めていきなり衝撃をくらわされた（注）。 アジャイルという言葉に対してのすでに持っている概念とエンタープライズという言葉から、大規模開発に対してアジャイルのメソドロジーを適用するための方法論の本かと思っていたからだ。 全然違った。 一言で本書の内容を言えば、常に変化に対応することで生存し成長する企業をつくるには、どのような文化がふさわしく、いかにそれを構築するか、について説明したものだ。 注）節題が「1.1 本書の革新性」とくるので、あまりの自信たっぷりっぷりに斜に構えて読んでいたからかも知れない。 冒頭の「最も高い顧客価値に目を向けている企業を想像してください。」が額面通りだっ
L'eclat des jours(2018-01-23)
_ はじめよう！ システム設計 技術評論社さんから（というか、羽生さんから、かな？）「はじめよう！ システム設計」をいただいた。 いきなりあとがきから読んだわけだが、問題意識が興味深い。 2017年はIT投資に企業の目が向いた年として規定される。AI、IoT、RPAの3つのキーワードと（個々人は貧乏街道まっしぐらだが資本はどんどん膨らんでいる）経済状況が背景にある。 ところが、SIerは人材流出の結果としてプロジェクトの全体構想を立案し着実に遂行する能力をほぼ失い、個々のPMの属人的な能力、つまり経験と知見だけで動くようになった結果、失敗が多い。 一方の発注側は、ITは虚業という言葉に散々踊らされた結果のIT軽視のツケと、これまでのコスト部門の弱体化（というか低予算化戦略）の結果として、これまた人材がいない。 結果として口が巧みなコンサルタントによる実現不可能な夢をトップがもって突っ走りま
口の悪い人間をエンジニアとして採用するべきか
旧帝大の情報系の研究室を可もなく不可もない業績で出て、今年の4月からまあまあ大手のIT企業で働いている。 来年あたりから採用面接で学生と話すことになるかもしれないんだけど、表題の件についてインターネットの人達に聞いてみたい。 研究室でも、あるいはTwitterでも優秀（ここでは、たとえばトップカンファレンスにほぼ毎年論文を採択される程度の能力を指す）で口が悪い人はそれなりにいる気がする。そういう人ともし面接で話すことになったら、どう評価すればいいんだろうか。技術的に色々知っていて、日夜最新のトレンドに追いつくどころか更に先を行くために勉強/開発/研究に取り組んでいるが、自分がよくないと思ったものに対して「それゴミでしょ」などとバッサリ否定するような人を。 たとえば研究室にいる優秀な後輩は（その人が認めている）優秀な人とは普通に会話しているが、自分のような冴えない人間には冷淡で、Twitte
TechCrunch
Husk Power Systems, a clean energy company at the forefront of fueling rural electrification since 2008 and that announced plans to launch 500 solar mini-grids in Nigeria over the next five years, has Much has been made of AI-powered videos which can either make a real person speak different words or other languages, or generate a synthetic person which can speak on-demand. A few years ago former
テストがなかった無法地帯にテストを導入して開発速度を1.7倍にした話 - Qiita
テストがなかった無法地帯のプロジェクトに自動テストを導入して、開発速度を1.7倍にした話をします。 自動テストがなぜないのか 自動テストのないプロジェクトには、そうなる理由が必ず存在します。よくみる理由は、「時間がないから1」「テストの書き方がわからないから」「無理やりテストを書いたつらい経験があったから2」といったものです。今回のプロジェクトの場合は、以下の2点でした： 自動テストの書き方がわからないから レビューがテスト代わりだったから まず、チーム編成が変わって私ともう一人がチームに加わるまで、実装者の中に自動テストの経験者はいませんでした。このような状況では、自動テストは困難になります。なぜなら、何をどうやってどこまでテストするかを決めるには、多少の慣れが必要だからです。この慣れがないと、何をしたらいいかわからないという状態に陥りがちで、結果として自動テストが後回しにされてしまいま
「ゼルダの伝説 BotW」にバグが少ない理由
素晴らしいオープンワールドゲームならいくらでもある。「The Elder Scrolls V: Skyrim」、「ウィッチャー3 ワイルドハント」、「グランド・セフト・オートV」、「Fallout 4」など、巧妙に作り込まれた膨大なスケールのゲームは特に海外のタイトルが多いように思う。それらと比べても遜色のない国産タイトル「ゼルダの伝説 ブレス オブ ザ ワイルド」（以下、BotW）だが、他のオープンワールドゲームより優れている点があるとすれば、バグの少なさなのではないだろうか。僕はハイラルの世界を150時間以上冒険しているが、バグらしいバグに遭遇したのは片手で数えられる程度の回数しかないのだ。 では、なぜBotWはこんなにもバグが少ないのか。「何年も入念に開発してきたからだ」とか「細かいところを丁寧に作り込む日本人の職人魂が備わっているから」とか、そんな理由でも片付けられそうな気がするが
SRE サイトリライアビリティエンジニアリング
サイトリライアビリティエンジニアリング（SRE）とは、Googleで培われたシステム管理とサービス運用の方法論です。GoogleのSREチームの主要メンバーによって書かれた本書は、ソフトウェアのライフサイクル全体にコミットすることで世界最大規模のソフトウェアシステムがどのように構築、導入、監視、維持されているのかを解説します。 はじめにリスク管理やサービスレベル目標、リリースエンジニアリングなどSREの行動の基礎となる原則について解説し、次にインシデント管理や障害の根本原因分析、SRE内でのソフトウェア開発など大規模分散コンピューティングシステムを構築し運用するSREの実践について詳述します。さらにSREのトレーニングやコミュニケーションなどの管理について紹介します。 急速にスケールするサービスを高い信頼性で運用する方法を解説する本書はエンジニア必携の一冊です。 本書への推薦の言葉 監訳者
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
