「人が増えても速くならない」と素朴概念の問題 - 勘と経験と読経
読むのがホネな技術書やビジネス書を取り上げて２週間の読書期限を課して読んでアウトプットする仮想読書会「デッドライン読書会」の第55回。同僚と読書期日を約束することによって消化が捗るという仕組み。過去記事はこちら。 さて、今回取り上げるのは話題（？）の本「人が増えても速くならない ～変化を抱擁せよ～」である。 人が増えても速くならない ～変化を抱擁せよ～ 作者:倉貫 義人技術評論社Amazon非エンジニア（起業家、経営者、マネージャ）向けに、ソフトウェア開発でよく起こる誤解を解くという目的で書かれた本書である。結論から言うと良い本であった。一方でいくつか気になる点もある。そういった事を書いていく。 ソフトウェア開発における素朴概念との戦い 先ほど「ソフトウェア開発でよく起こる誤解を解く」と書いたが、最近勉強している心理学の用語でいうと、この誤解は素朴概念の一種であると言えるのではないかと最近
エンプラ技術者の知識継承がうまくいっていないかも、という話 - 勘と経験と読経
最近読んだ「Web世代が知らないエンタープライズシステム設計」はとても刺激的で良い本だった。企業の情報システム部門およびエンタープライズシステムを受託開発するSIerの中堅技術者は必読だと思う。ただ、書籍タイトルは中身を分かりにくくしている気がする。「エンタープライズシステムアーキテクトが知るべき16のこと」という感じの本だ。 さて、同書の冒頭で書かれている、エンタープライズシステム設計に関するノウハウ継承が世代間でうまくいかなたったのではないか、という問題提起が気になったので、考えたことを書いてみようと思う。 何がエンタープライズシステム開発のノウハウ継承を阻んだのか？ 「Web世代が知らないエンタープライズシステム設計」では、2つの要因によって00年前後にエンタープライズシステム開発のノウハウ継承が阻まれたという仮説が提示されている（ノウハウ継承の場であるワイガヤが失われたという文脈）
英語技術書を機械翻訳で読みまくる方法 - 勘と経験と読経
ふとしたキッカケで英語技術書を機械翻訳で読みまくれる環境を整備したら非常に快適になったのでご紹介。要約すると、定額制無制限の書籍サイトに加入して、バルクでGoogle翻訳をかけてざっくりと技術書を読む方法について。 https://www.flickr.com/photos/62277986@N00/2904221707 これまでの英語技術書読書環境の問題点 英語苦手 洋書は読めなくは無いけど英語力の問題で読むのが遅いのがツラい 電子書籍（例えばKindle）なら辞書機能があるので単語レベルの問題は解決できるけど、怠惰なので文節単位以上で機械翻訳したい 文書を電子書籍やPDFからコピペして機械翻訳するのはとっても面倒 SREWorkbookが期間限定でPDF無料ダウンロードできたのだけど、読むのが大変 無料公開されたSite Reliability Engineering Workbook
ソフトウェア見積もりと納期のいくつかの真実とウソ - 勘と経験と読経
ソフトウェア開発の見積もりと納期について言及されたブログ記事を見て違和感があったので掘り下げてみた記事。ソフトウェア開発の「見積もり」というと少なからずSIer臭がする。しかしSIerや日本のソフトウェア開発の現状を憎悪するからといって、見積もりというアクティビティの重要性は変わらないし、軽視してよいものではないというのが個人的な考え。 ウソ:ソフトウェアの納期見積もりは、星占いレベルのものである 論点を単純化するための釣りタイトルだと思うのだけれども、ソフトウェア開発における「不確実性のコーン」はスケジュールではなく、スコープ(工数、コスト、機能)の見積もりに関する分析であって、納期、スケジュールに関する分析ではない点には注意が必要である。 この本に「不確実性のコーン」という開発フェーズごとの見積もりの正確性に関する図がある。これを見ると、最初の企画の段階で実施した見積もりは、誤差が何と
ウォーターフォール型開発プロセスの有効性 - 勘と経験と読経
牛尾さんのブログで問題提起している「私はソフトウェアの専門家としてお答えすると、ウォータフォールは何のメリットも無いというのが私の意見である」という件について、自称ソフトウェア開発の専門家として考えたことを書いてみる記事。近しい各方面から意見を聞かれるので面倒なのでブログにまとめている側面もあるのだけれど。結論を先に書くと、計画駆動とアジャイルの扱いはバランスを重視。WFがメリットが無いというのは言いすぎだと思っている(課題はある)。 こちらも合わせて読んだ 日本でアジャイルが流行らない理由 - @ledsun blog 事業会社をIT会社に転生させることが、これからのSIerのミッション - GoTheDistance そもそも批判されるようなWF型プロジェクトは実在するのか 本件に限らず批判されがちな「ウォーターフォール型開発プロセス（以下WFと記述）」だが、実際のところ皆さんそれぞれ
後輩に勧める10冊の本（SIer勤務で固めドメイン・受託開発やってるエンジニア向け） - 勘と経験と読経
いわゆるエンプラ（笑）技術者向けにお勧めする本をまとめてみた。というか某方面からピックアップの依頼を受けて考えたもの。SIer勤務でお固めのドメインの受託開発に従事しているエンジニア向けになっていると思う。世の中的には「エンタープライズ」とか言われている領域をイメージしていただければよいかと思う（一部で、「エンプラ（笑）って何だ？」みたいな議論もあるみたいだけど、いまいちピンときていない）。なお、初心者向けにはなってはいない。 ソフトウェア開発ライフサイクル全般 共通フレーム いろいろと批判があることはわかっているけれども、ソフトウェア開発のゆりかごから墓場までに実施すべきタスクを全方位に把握するならまず共通フレームがお勧め。注意を払うべき様々な標準についてのインデックスとしても有用である。ただし、読んでて面白い本ではない。そして分厚い。なおIPAの有償セミナーで参加すると一冊貰える場合が
「システム設計の謎を解く」の感想 - 勘と経験と読経
書籍モニターキャンペーンに当選してプレゼントいただいた書籍「システム設計の謎を解く 強いSEになるための機能設計と入出力設計の極意」を読了したのでその感想など。自分にとっては恐ろしいほどに有用な本だった。ただひたすらにソフトウェア開発の基本設計について考える本。 以前に書いた記事はこちら 「システム設計の謎を解く」を読みながら設計について考える - 勘と経験と読経 アジャイルフリーでテクノロジーフリーな基本設計の本 本書は一言で言うとそんな感じ。 要件定義の領域は扱っていない（ただし、基本設計の前にやるべき事は整理されている） アプリの基本設計が中心でアーキテクチャ設計は軽く触れる程度 詳細設計についても範囲外 オブジェクト指向設計については軽く触れる程度 アジャイル開発も触れる程度 この割切り（？）は顧客の立場に立って考えるととても実践的だと思う。 顧客の立場からすると アーキテクチャの
「システム設計の謎を解く」を読みながら設計について考える - 勘と経験と読経
書籍モニターキャンペーンに当選したので、今月末に発売予定の書籍「システム設計の謎を解く」を読み始めた。まだ全部は読み終わっていないのだけれども、設計に関して考えた事について。 システム設計の謎を解く 強いSEになるための機能設計と入出力設計の極意 作者:高安 厚思SBクリエイティブAmazon良書の予感(いま3章まで読んだところ)。 ソフトウェアの設計を「考える」 最近の風潮では（あくまで個人的感覚だが）なんというか「設計」は軽視されがちだ。 アジャイル開発のメジャー化に伴って、プログラミングを中心とした方法論やプラクティスは割りと注目されている。 SIerを中心に以前としてあるプロジェクトマネジメントや、要求管理は引き続き注目されている(ような気がする)。 他に、運用関連やテスト(プロセス)関連も割りと話を聞くような。 本来はソフトウェア開発のど真ん中にあるべき「設計」に関する話題で盛り
チーム内でやる進捗会議はムダ - 勘と経験と読経
ソフトウェア開発プロジェクトでは、顧客への定期的な進捗報告を行うために、当然のことだが進捗を管理しなければいけない。中規模以上のプロジェクトではプロジェクトはいくつかのチームに分かれていて、さらにチームごとに担当する会社が異なることもある。ありがちな事だが、チーム別にプロジェクト内の進捗会議を行うようになってくると、これが壮大なムダになっていく。 チームリーダーはソフトウェア開発プロジェクトのボトルネック ソフトウェア開発プロジェクトは、ウォーターフォール形式であれアジャイル開発プロセス型であれ、膨大なコミュニケーションと意思決定を行うことで進んでいく。ソフトウェアの仕様や構成について決定するのは、たいていはチームリーダーの仕事だ。また、各開発担当者の仕事の結果が正しいのかをレビューやインスペクションによって判定するのもチームリーダーの仕事であることが多い。そして、チームリーダーはチームメ
朝会を進捗会っぽくしない - 勘と経験と読経
朝会はコミニュケーションの場であって、スクラムマスターやマネージャーへの報告の場ではない。でも、文化や出自の異なるメンバーで行うプロジェクトだと、いつのまにかミニ進捗みたいになってしまう。雰囲気作りも重要だと思うけど、それ以外にやれることはある。 朝会のミニ進捗会化 デイリースタンドアップ／スクラムはスクラムマスタのためのものではない そもそも朝会のようなコミニュケーションの場は特殊で、（日本人にとって）普通に学校や社会で学ぶような機会はあまりないと思う。いちばん経験するのはトップダウンの情報共有（先生や上司の話を聞く）かボトムアップの報告（上司やリーダーに報告連絡）だから、放っておくと朝会もそうなりやすい。 うまくいっていない朝会だと、そもそもメンバーの会話を他のメンバーが聞いていない。というか、自分が発言するまでは「なにを発言するか」ばかりを気にしているし、自分の番が終わるともう終わっ
ウォーターフォールのほうが楽だという話 - 勘と経験と読経
わたしはまだ本格的な(?)アジャイル開発をやったことは無いけれども、周りのウォーターフォール脳に比べたらアジャイルプラクティスをプロジェクトに取り込むことが多い（プロジェクトマネージャーの立場で、スクラムマスター的に推進）。いくつかのプロジェクトを終えて、結果を振り返ってみるとチームメンバーの平均的な帰宅時間は早まったし、休日出勤することも減ったと思う。QoELは確実に上がったと思っていたけれども、一部のエンジニアからは「キツかった」と言われて驚いた。 アジャイルの前のほうが楽だった？ 「第5回 TFSUG：ウォーターフォールからアジャイル、リーンへ」での発表で、アジャイル開発に挑戦した方がやはり「前のほうが楽だった」というような事を書いている。 http://kaorun55.hatenablog.jp/entry/2012/04/17/001312 第5回TFSUG WFからAgile
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
