おっさんITエンジニアの後輩に勧める10冊の本 2025年版 - 勘と経験と読経
いわゆるエンタープライズ向けソフトウェア開発技術者向けにお勧めする本をまとめてみた、というか10年くらい前に書いた記事を見直したもの。後輩から「後輩に勧めたい本を教えてください」という相談を受けることがあって（白目）記事が古くなっていたことに気づいたのだった。10年前の記事と同様にSIer勤務でお固めのドメインの受託開発に従事しているエンジニア向けになっていると思う。なお学生、新人、初心者向けにはなっていないのであしからず。 10年以上前に書いた記事はこちら agnozingdays.hatenablog.com ソフトウェア開発ライフサイクル全般 IPA 応用情報処理技術者試験 プロジェクト管理 デッドライン 人月の神話 アート・オブ・プロジェクトマネジメント 見積もり ソフトウェア見積り ～人月の暗黙知を解き明かす～ アジャイルな見積りと計画づくり ～価値あるソフトウェアを育てる概念と
ドキュメントとしての詳細設計書と、プロセスとしての詳細設計 - 勘と経験と読経
「ソフトウェアの「詳細設計書」とはなんなのか」というブログ記事を読んで考えたこと。設計に関するプロセスとドキュメンテーションの関係性についての考えの整理。SI屋的な視点で。 2024/8/18追記：文中にあった雑な文系disが不愉快というご指摘を受けました。ご指摘の通りだと思いましたので訂正しています。大変失礼しました。 「詳細設計書」とはなんなのか nowokay.hatenablog.com こちらの記事では詳細設計書とは以下のようなものであると整理されている。 表現を変えたコーディング（の一種） 机上プロトタイプ（の一種） 分析資料 保守（のための）資料 （水平作業の場合の）作業指示書 （委託している場合の）契約資料 上記以外で考えられるのは次のようなものがあるだろう 利害関係者が要求している たとえば受託開発において発注者が要求している場合 ほかには連携している相手先システム側から
実践要件定義入門 - 勘と経験と読経
最近ネットを見ていると要件定義入門的な記事とか、あと要件定義は不要みたいな記事が目についたので思ったことを書いてみる記事その２。ITシステム開発における要件定義に関するあれこれ。本記事には前編があります。 目次 要件定義以前 要件定義の進め方 IPAユーザのための要件定義ガイドをベースにする 決め過ぎない 機能を定義するのではなく、機能要件を定義する 関係者をすべて洗い出す 利用者マニュアルの目次が作れるようになっているか ビジネス要件定義 前提事項、制約事項とリスクを定義する 優先順位の決定を忘れずに システム化要件定義 不安定な要件を構造で支える おまけ：本記事の元ネタ 要件定義以前 要件定義というプロセスが本当に必要なのか、ということなどは以下の記事に書いたので省略。 実践要件定義入門以前 - 勘と経験と読経 要件定義の進め方 IPAユーザのための要件定義ガイドをベースにする 前編に
実践要件定義入門以前 - 勘と経験と読経
最近ネットを見ていると要件定義入門的な記事が目についたので思ったことを書いてみる記事。ITシステム開発における要件定義に関するあれこれ。 【2023/10/10追記】続編の記事を書きました。実践要件定義入門 - 勘と経験と読経 目次 要件定義に関するおすすめ書籍 その要件定義は必要か 要件は決められるのか 要件定義をすることがルールで定められているから要件定義をする必要がある 要件は定義できるのか 現行の業務マニュアルをベースに要件定義をするつもりのあなたへ 現行システムをベースに要件定義をするつもりのあなたへ 外部業者を呼ぶ前に考えるべき事 どこから外注するかを考える 要件定義の作業期間を見積もる 要件定義に関するおすすめ書籍 この後に何度も引用することになると思うので、最初に要件定義のおすすめ書籍を紹介しておく。と言っても紹介するのは1つだけだ。 ユーザのための要件定義ガイド第2版 作
CCPMを使って組織にアジリティを注入するのは冴えたやり方 - 勘と経験と読経
先日公開された「NTTデータはどうやってCCPMを導入したのか？」という資料を見ての感想。アジャイルという言葉を前面に持ってこずに、しかし結果として主にスクラムを中心としたプラクティスを現場に注入している(ような気がする)。CCPMを使って組織にアジリティを注入するのは冴えたやり方だなぁと思った。 そういえば、技術士の二次試験の口頭試問で自分のプロジェクトの進め方を説明した時に試験官から「制約理論を勉強されたのですか？」と聞かれたことを思い出した。自分としては(制約理論は知っていたけれども)プロジェクトの特性に合わせてアジャイルプラクティスをつまみ食いして運営していたつもりだった。結果としてCCPMに近いことをやっていたのかもしれない(ごっちゃになっていたのかも)。 部分最適が現場を悲惨にしている 制約理論(TOC)というとピンと来ないかもしれないが、10年以上前にベストセラーになったゴー
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
