向上心より危機感と地道さが残業を減らすのだ - 勘と経験と読経
残業削減などのコンサルティングで有名な小室淑恵さんのセミナーを聴き、著書「ほんとうの豊かさを手に入れる 人生と仕事の段取り術 (PHPビジネス新書)」を読んだのでその感想など。個人的には生産性向上は力を入れてきたテーマで「7つの習慣」から始まり「GTD」などのLifeHack系や手帳術の道も一通り歩んできたつもり。けれども、小室さんの説明は向上心に訴えるというより、危機感を持たせ、シンプルな方法で残業を減らすというものだ。こういった取り組みのほうが地道に効果が上がるのだと思ったことなど。 photo by Joriel "Joz" Jimenez これまでの生産性向上遍歴 割とまあ一通りという感じ。他にも色々読んだけれど、心には残っていない。 7つの習慣-成功には原則があった! 作者:スティーブン・R. コヴィーキング・ベアー出版AmazonはじめてのGTD ストレスフリーの整理術 作者:
エンジニアの中高年危機について考える1：モダンエルダー - 勘と経験と読経
中高年になってしまったので、中高年危機について勉強したり考えている。というわけで何回かに分けて調べたことや考えたことをアウトプットしていきたい。明確な構想を立てているわけではないので、先に進むにつれて考え方も変わるかもしれない。今回は「モダンエルダー」を読んだ感想を中心に書いていく。 モダンエルダー 40代以上が「職場の賢者」を目指すこれからの働き方 作者:チップ・コンリー日経BPAmazon 中高年とは 最初に中高年の定義について明確にしておこうと思う。 法制度の定義をみると、例えば「高年齢者等の雇用の安定に関する法律」では、「中高年齢者」を45歳以上、「高年齢者」を65歳以上とに分けて設定されている。また「21世紀における国民健康づくり運動」の中でも、45歳から64歳までが中高年として提示されている。 本書においても、中高年の開始年齢をめぐっては、概ね40代後半頃からであると想定してい
ソフトウェア犬小屋とビル建築 - 勘と経験と読経
ソフトウェア開発におけるメタファーの話。某所でイケていないソフトウェア開発のことを「犬小屋づくり」に例えている文章を読んだ。わりと昔から目にする例えなんだけど、現在もその通りに使えるのかというと微妙だと考えた事。 photo by ClicPhoto Studio 犬小屋のメタファーの原点 犬小屋とは、「ひとりで試行錯誤しながらつくる小さなものづくり」という事を指している(のだと思う)。犬小屋というメタファーの原点は、ソフトウェア開発の名著である「Code Complete」にあるようだ。というわけでちゃんと調べてみた。 たとえば、犬小屋のような単純な構造物を組み立てるとしよう。材木店に出かけて適当な材木と釘を買ってくれば、夕方までには愛犬の新居が完成するだろう。うっかり入り口を作り忘れたといったミスを犯しても、たいした問題ではない。修正すればよいし、何なら最初から作り直したってかまわない
産業安全についての神話（Some myths about industrial safety）について調べた - 勘と経験と読経
The DevOps ハンドブック 理論・原則・実践のすべてで紹介されていた「産業安全についての神話」（補章E）が面白そうだったので調べてみた。ソフトウェア開発に限らず、工学全般の話。 The DevOps ハンドブック 理論・原則・実践のすべて 作者: ジーン・キム,ジェズ・ハンブル,パトリック・ボア,ジョン・ウィリス出版社/メーカー: 日経BP社発売日: 2017/07/04メディア: Kindle版この商品を含むブログを見る 複雑なシステムに対する数十年の研究の結果、危険への対応策はいくつかの神話に基づいていたことがわかった。 原文はおそらくこれ Some myths about industrial safety(PDF) なお以下私の誤読の可能性もあるので、興味があれば上記の原典論文を参照のこと。 神話1：事故やインシデントの唯一最大の原因はヒューマンエラーである 原因をヒューマ
社内勉強会をやらない理由 - 勘と経験と読経
ときどき「社内勉強会をやってほしい」という事を言われることがあるのだけれども、基本的には断るようにしている。その理由について。 社内勉強会は言われて始めるものじゃない 「社内勉強会をやってほしい」と人に言われても基本的には断っている。こういったことを言うのは自分の上司や関連部門の偉い人に多い。言う人は、きっとこんな期待をしている。 メンバーの底上げやレベルアップ 生きた知識を現場間で情報共有する メンバー間の交流でより良い結果が得られるようになる でも実際に言われるがままに勉強会を企画しても、 人が集まらない 発表者が偏る 発表者の負担が増えていき、開催されなくなる ということになるのがわかっているから、実施しないのだ。 どうしてこんな事が起こるのかというと、単純にマーケットが小さすぎて、企画が成立しないのだからだと思っている。そもそも、コミュニティ活動を真っ当に実施できているエンジニアは
デス・マーチ著者Ed Yourdonさんの『ソフトウェア工学で大切な10の考え方』を再読する(後編) - 勘と経験と読経
前々回、前回記事の続き。デス・マーチ著者のEd Yourdonさんが先日(2016/1/22)亡くなったとのこと。合掌。これを機会に同氏が2009年に公開し平鍋さんが和訳を公開している『ソフトウェア工学で大切な10の考え方』を再読してみた。この後編では「9.一貫性は才能+デスマーチに勝る」から後に関して記載。勉強不足により誤読、勘違いをしているかもしれない。指摘やフィードバックは大歓迎。 Top Ten SE Concepts V11.1 Jp from Kenji Hiranabe デスマーチ 第2版 ソフトウエア開発プロジェクトはなぜ混乱するのか 作者:エドワード ヨードン発売日: 2013/09/12メディア: Kindle版 9.一貫性は才能+デスマーチに勝る グローバルな不況は、少なくともここ数年、デスマーチプロジェクトを増加させるだろう…… SEI-CMM, ISO-9000,
エンプラ技術者の知識継承がうまくいっていないかも、という話 - 勘と経験と読経
最近読んだ「Web世代が知らないエンタープライズシステム設計」はとても刺激的で良い本だった。企業の情報システム部門およびエンタープライズシステムを受託開発するSIerの中堅技術者は必読だと思う。ただ、書籍タイトルは中身を分かりにくくしている気がする。「エンタープライズシステムアーキテクトが知るべき16のこと」という感じの本だ。 さて、同書の冒頭で書かれている、エンタープライズシステム設計に関するノウハウ継承が世代間でうまくいかなたったのではないか、という問題提起が気になったので、考えたことを書いてみようと思う。 何がエンタープライズシステム開発のノウハウ継承を阻んだのか？ 「Web世代が知らないエンタープライズシステム設計」では、2つの要因によって00年前後にエンタープライズシステム開発のノウハウ継承が阻まれたという仮説が提示されている（ノウハウ継承の場であるワイガヤが失われたという文脈）
読書ノートのこと - 勘と経験と読経
継続学習力というエントリで技術書やビジネス書などに関する読書について書いたのだけれども、自分は単に読むだけではなく読書ノートをつけている。というわけで、読書ノートに関するメモ。 読書の効果を100倍にする「読書ノートの作り方」：読書で得た知識をスキルに変えろ！ - U-NOTE[ユーノート] - 仕事を楽しく、毎日をかっこ良く。 - 自分の読書ノート 基本は目次をぜんぶ打ち込んで、あとは気になる箇所について文章を抜き書きする 気になる箇所は付箋などをつけておいて、まずノートを取らずに本を読み終える 2周目は付箋の箇所を中心に「気になる箇所」を抜き書く。付箋を貼った箇所＋αのメモを取る もちろん気になる箇所が無くて「目次だけ」の読書ノートもある。 「メモを取る価値なし」と判断した場合だけ、読書ノートはとらない。 いまのところGoogle Driveに集約している 以前は単なるテキストファイル
いまさら「Project Retrospectives: A Handbook for Team Reviews」を読む - 勘と経験と読経
同僚と「アジャイルレトロスペクティブズ 強いチームを育てる「ふりかえり」の手引き」の話をしていたところ、同書で紹介されていた類書「Project Retrospectives: A Handbook for Team Reviews (Dorset House eBooks) (English Edition)」に気が付いた（自分が読んだ時には気づかなかったなぁ）。未翻訳だけど、そういえばO'reillyで原著が読めるので、興味の向くままに読んでみた。2001年の本である。 Project Retrospectives: A Handbook for Team Reviews (Dorset House eBooks) (English Edition) 作者:Kerth Norman L.発売日: 2013/07/15メディア: Kindle版 そういえば平鍋さんのブログでも紹介されてい
複雑なシステムはどのようにして失敗するのか(How Complex Systems Fail) - 勘と経験と読経
How Complex Systems Fail – Perspectives の記事で紹介されていた「複雑なシステムはどのようにして失敗するのか(How Complex Systems Fail)」という論考が興味深かったので紹介する記事。 How Complex Systems Fail(PDF) 詳細はリンク先のPDF参照だが、紹介されている18条だけ簡単に紹介しておく(DeepL翻訳)。 複雑なシステムは本質的に危険なシステムである 複雑なシステムは故障に対して重く、うまく防御されています 大災害は複数の失敗を必要とする - 一点の失敗では十分ではない 複雑なシステムには、その中に潜んでいる欠陥の変化する混合物が含まれています 複雑なシステムは劣化モードで動作する 破局は常に角を曲がったところにある 事故後の事故を「根本原因」に帰属させることは根本的に間違っている 事故後の人間のパ
教育心理学はソフトウェア開発に活用できるか（教育心理学特論を読み終えて） - 勘と経験と読経
数年前からアジャイル開発コミュニティで話題になっていた放送大学のテキスト「教育心理学概論」というものがある。その増補改訂版である「教育心理学特論」を、放送大学大学院の講義15回を通じて読み終えた。そこで、本記事ではソフトウェア開発という観点から同書の感想などについて触れてみたいと思う。 教育心理学特論 (放送大学大学院教材) 作者:芳雄, 三宅,始, 白水発売日: 2018/03/01メディア: 単行本なお世間的には「教育心理学概論」が有名なようですが、私は特論のほうをお勧めします。理由は以下の記事を参照 「教育心理学概論」と「教育心理学特論」を比較してみた - 勘と経験と読経 本書は（ソフトウェア開発関係者に）お勧めなのか？ 自分にとって本書を通じた学びは知的好奇心を満たしたのみならず、今後の仕事への刺激も大きく、満足の高かったものだった。ではソフトウェア開発関係者（私の同僚や同業界人）
Googleマネジメントの元ネタでもあるインテル経営の本を読んだ - 勘と経験と読経
ちょっと前に目に付いた「1 on 1 で 何を話すのか？ マネージャ/ソフトウェアエンジニアの立場から」というブログ記事で紹介されていた「インテル経営の秘密―世界最強企業を創ったマネジメント哲学」を読んだメモ。かなり以前から気になっていたのだけれども、現在は絶版で古書がプレミア価格になっている。さすがに買えないので公立図書館で借りて読んだもの。普通の管理職、マネジャーとして非常に勉強になる良い本だった。 経営陣 or 上司が 1 on 1 の価値を分かってくれない インテル経営の秘密―世界最強企業を創ったマネジメント哲学 をプレゼントしよう 1 on 1 で 何を話すのか？ マネージャ/ソフトウェアエンジニアの立場から - サンフランシスコではたらくソフトウェアエンジニア - higepon blog インテル経営の秘密―世界最強企業を創ったマネジメント哲学 作者:アンドリュー・S. グロ
WBS類とコンウェイの法則、組織の枝振りは変化する - 勘と経験と読経
ＷＢＳはプロジェクト組織を規定する : タイム・コンサルタントの日誌から、というブログ記事を読んで考えたこと。コンウェイの法則の別バージョンとしてこの記事はちょっと面白い。ソフトウェア開発プロジェクトは個別性が高いので、それぞれに適したマネジメントを組み込む必要がある。手抜きの計画や、お仕着せの社内標準WBSを流用すると痛い目に合ってしまう。 そして、プロマネであるあなたは、自分のプロジェクトをどのようにマネージしたいかによって、どちらのＷＢＳをとるか判断するべきなのである。たとえば、モジュール間の関連性が強くて、全体が密結合のシステムを作る場合は、プロセス中心型で進めたいだろう。逆に、たとえばすでにあるシステムに、新規機能をいくつか追加していくようなプロジェクトならば、モジュールができた順にリリースしたいから、成果物中心型を選ぶだろう。もしもこれが逆だったら、いかに仕事がやりにくいか、想
「The Art of Monitoring」で紹介されてた時系列データ可視化のコツ - 勘と経験と読経
先日読んだ「The Art of Monitoring」で紹介されていた時系列データ可視化の参考資料について調べたこと。Datadogの資料はすごく参考になる。 The Art of Monitoring (English Edition) 作者: James Turnbull発売日: 2016/06/08メディア: Kindle版この商品を含むブログを見る 2.4 Visualization We've drawn most of our ideas from Edward Tufte's The Visual Display of Quantitative Information and throughly recommend reading it to help you build good visualizations. There's also a great post from
手書きメモについて。プログラム以外を写経したっていいじゃない - 勘と経験と読経
ちょっと前に書いた記事に、普段書いている手書きの読書メモをついでに貼り付けておいたらそっちへのツッコミが多かったでござるの巻。というわけで手書きメモについて。 はてなブックマーク - いまさら「ドメイン駆動設計」を読み終えた - 勘と経験と読経 photo by dmelchordiaz 手書き読書メモがキレイと言われるとびっくりする。分厚い本は何度も読み返すのが嫌だからメモをとる。メモはあとで見るために書いてるので丁寧に書く。読書をするのにPC持ち歩くのは不便だから手書き。ただそれだけ。メモとりながらじゃないと整理もできないという性格もあるけど。— Kent Ishizawa (@agnozingdays) 2014, 4月 30 写経、視写 プログラマの勉強法のひとつに写経というものがある。技術書などに書かれているサンプルプログラムをそのまま入力して動かしてみるというやり方だ。 写経で
「システム設計の謎を解く」の感想 - 勘と経験と読経
書籍モニターキャンペーンに当選してプレゼントいただいた書籍「システム設計の謎を解く 強いSEになるための機能設計と入出力設計の極意」を読了したのでその感想など。自分にとっては恐ろしいほどに有用な本だった。ただひたすらにソフトウェア開発の基本設計について考える本。 以前に書いた記事はこちら 「システム設計の謎を解く」を読みながら設計について考える - 勘と経験と読経 アジャイルフリーでテクノロジーフリーな基本設計の本 本書は一言で言うとそんな感じ。 要件定義の領域は扱っていない（ただし、基本設計の前にやるべき事は整理されている） アプリの基本設計が中心でアーキテクチャ設計は軽く触れる程度 詳細設計についても範囲外 オブジェクト指向設計については軽く触れる程度 アジャイル開発も触れる程度 この割切り（？）は顧客の立場に立って考えるととても実践的だと思う。 顧客の立場からすると アーキテクチャの
いまさら「ドメイン駆動設計」を読み終えた - 勘と経験と読経
今さらなのだけれども、「エリック・エヴァンスのドメイン駆動設計 (IT Architects’Archive ソフトウェア開発の実践)」を読んだ。仕事で活用できるかと問われると微妙だけれども読んで良かった。避けていたのはいろいろな誤解があった。複雑なソフトウェアを作る為の考え方。 エリック・エヴァンスのドメイン駆動設計 (IT Architects’Archive ソフトウェア開発の実践) 作者:エリック・エヴァンス発売日: 2011/04/09メディア: 大型本 Eric EvansがDDDのアイデアを著書のドラフトというかたちでWeb上で公開し始めた2002年以来、この知恵の書は多くの識者の間で話題の中心となり、「徹頭徹尾有用な書籍（most thoroughly useful book）」とまで評された。記述されている内容の一言一句すべてにおいて役に立つことしか書かれていない、と賞賛
もしもソフトウェア開発のPMがTRPGのGMだったら - 勘と経験と読経
妄想妄言の類い。工程の区切りで正気度チェック！という話ではなく。InfoQで「ロールプレイングゲームのダンジョンマスタとして学んだことをアジャイルコーチングに活用する」という記事を読んで考えたことなど。ちなみに「TRPGのGM」は、「テーブルトークロールプレイグゲームのゲームマスター」のこと。 テーブルトークRPG - Wikipedia ゲームマスター/ダンジョンマスターの役割 TRPGのGMの役割は、わたしの理解ではざっとこんな理解である。 物語りの背景と舞台、大まかなシナリオを用意する メンバーの振る舞いに応じて少しずつシナリオを進めて、メンバーと一緒に物語を作り出す メンバーの行動を指示することは出来ないが、舞台設定である程度行動の方向性に影響を与えることはできる 「轟音とともに洞窟の入り口は崩れた岩によって塞がれてしまった。どうやら後戻りはできないようだ」 この「メンバーの行動を
朝会は文字通り朝にやれ - 勘と経験と読経
アジャイルではないソフトウェア開発プロジェクトでも一般化しつつあるプラクティスの一つに朝会（デイリー・スタンドアップ・ミーティング、デイリー・スクラム)がある。正しい読み方は知らないけれど、「ちょうかい」ではなくて「あさかい」って言うのが通例のような気がする。要は毎日プロジェクトメンバーが集まって、簡単に現在の状況や問題点を共有するショートミーティングをやるということ。時間を短く保つために立ってやるため、デイリー・スタンドアップ・ミーティングと呼ばれることもある。http://capsctrl.que.jp/kdmsnr/wiki/bliki/?ItsNotJustStandingUpの解説がお薦め。 朝会が朝会じゃなくなってしまうとき 朝会はアジャイル開発のプラクティスの一つだけど、ツールや既存の開発プロセスとも親和性が高いので導入もしやすい。日本の会社社会ではもともと朝の訓示や連絡など
チーム内でやる進捗会議はムダ - 勘と経験と読経
ソフトウェア開発プロジェクトでは、顧客への定期的な進捗報告を行うために、当然のことだが進捗を管理しなければいけない。中規模以上のプロジェクトではプロジェクトはいくつかのチームに分かれていて、さらにチームごとに担当する会社が異なることもある。ありがちな事だが、チーム別にプロジェクト内の進捗会議を行うようになってくると、これが壮大なムダになっていく。 チームリーダーはソフトウェア開発プロジェクトのボトルネック ソフトウェア開発プロジェクトは、ウォーターフォール形式であれアジャイル開発プロセス型であれ、膨大なコミュニケーションと意思決定を行うことで進んでいく。ソフトウェアの仕様や構成について決定するのは、たいていはチームリーダーの仕事だ。また、各開発担当者の仕事の結果が正しいのかをレビューやインスペクションによって判定するのもチームリーダーの仕事であることが多い。そして、チームリーダーはチームメ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
