残念なレビュー、あるいはレビュアー心得 - 勘と経験と読経
ソフトウェア開発におけるドキュメントレビューについて最近考えていること。漫然としたレビュー、残念なレビューにより生産性が大きく損なわれていることが多い。とはいえ、自部門組織でもうまく改善できているわけではなく、どうしたらよいか悩んでいるのだけれども。 （良い）レビューの想い出 ソフトウェア開発におけるレビューはいろいろと経験しているが、折に触れて思い出す出来事がふたつある。こんなことを書くと老害認定されるかもしれないけど書く。老いててすいません。 ひとつは社会人になったばかりの駆け出し時代（一部脚色しています）。社会インフラ的な基幹系システム（ホスト）の開発に参加したのだけれど、ドキュメントもコードもとても丁寧に厳密にレビューしてもらっていた。もちろん学生時代にレポート類のレビューを受ける経験はあったけれども、段違いの精度でのレビューに衝撃を受け、ソフトウェア開発を仕事にするというのはこう
ソフトウェア要求 第３版は何が変わったのか - 勘と経験と読経
いつか読もうと思っていた名著「ソフトウェア要求 第3版」を読んでゐる。割といろんな人から「この本は良い本だ」という話を聞くのだけれども、皆が読んでいるのはだいたい第2版だ。10年を経て更新された第3版は何が変わったのかというのは実は明確ではない。残念ながら第2版は手元にないけれど、ウェブで詳細な目次が閲覧できる。というわけで目次を眺めながら、何が変わったのかについて考えてみた。第2版しか読んでいない人は第3版を購入するかどうかの判断の目安にできるかも。 ソフトウェア要求 第3版 作者:カール ウィーガーズ；ジョイ ビーティ日経BPAmazon 参考とした旧版の目次は以下 http://ec.nikkeibp.co.jp/item/contents/mokuji/m_580500.html 大きく追加された点は何か 変更点が明確ではないと書いたけれども、大きな変更点は「はじめに」でざっくりと
IT人材白書2015ナナメ読み - 勘と経験と読経
無料だし、自分が属する業界に関する分析記事なので読んだのだ。「自分の仕事を憎むには、人生はあまりにも短い（ジョエル・スポルスキ)」だからこそ。 http://www.ipa.go.jp/about/press/20150422_1.html IPAが「IT人材白書2015」を発行。国内のIT系人材は約112万人、IT企業の人手不足が生じる構造の分析など － Publickey IT人材白書2015をガリガリ君を食べながらナナメ読んだ | 「世界」旅と子育てを愛するアジャイルコーチのブログ 以下にAmazonの書影を貼るが、IPAのサイトで簡単なアンケートに答えれば全編ダウンロードできる。 IT人材白書2015 独立行政法人 情報処理推進機構Amazon ちなみに興味のある受託開発まわりしか読んでおらず、組み込み、ビッグデータ、ベンチャー関連は完全に無視しているのでご注意いただきたい。 メッ
後輩に勧める10冊の本（SIer勤務で固めドメイン・受託開発やってるエンジニア向け） - 勘と経験と読経
いわゆるエンプラ（笑）技術者向けにお勧めする本をまとめてみた。というか某方面からピックアップの依頼を受けて考えたもの。SIer勤務でお固めのドメインの受託開発に従事しているエンジニア向けになっていると思う。世の中的には「エンタープライズ」とか言われている領域をイメージしていただければよいかと思う（一部で、「エンプラ（笑）って何だ？」みたいな議論もあるみたいだけど、いまいちピンときていない）。なお、初心者向けにはなってはいない。 ソフトウェア開発ライフサイクル全般 共通フレーム いろいろと批判があることはわかっているけれども、ソフトウェア開発のゆりかごから墓場までに実施すべきタスクを全方位に把握するならまず共通フレームがお勧め。注意を払うべき様々な標準についてのインデックスとしても有用である。ただし、読んでて面白い本ではない。そして分厚い。なおIPAの有償セミナーで参加すると一冊貰える場合が
社内勉強会をやらない理由 - 勘と経験と読経
ときどき「社内勉強会をやってほしい」という事を言われることがあるのだけれども、基本的には断るようにしている。その理由について。 社内勉強会は言われて始めるものじゃない 「社内勉強会をやってほしい」と人に言われても基本的には断っている。こういったことを言うのは自分の上司や関連部門の偉い人に多い。言う人は、きっとこんな期待をしている。 メンバーの底上げやレベルアップ 生きた知識を現場間で情報共有する メンバー間の交流でより良い結果が得られるようになる でも実際に言われるがままに勉強会を企画しても、 人が集まらない 発表者が偏る 発表者の負担が増えていき、開催されなくなる ということになるのがわかっているから、実施しないのだ。 どうしてこんな事が起こるのかというと、単純にマーケットが小さすぎて、企画が成立しないのだからだと思っている。そもそも、コミュニティ活動を真っ当に実施できているエンジニアは
開発者向けのソフトウェア設計書は必要か？ - 勘と経験と読経
時々組織の内外で盛り上がるネタの一つに「設計書は必要なのか」談義がある。今回も後輩の一人から設計書不要論がぶつけられてきたので、現時点での個人的見解をまとめておくもの。個人的には、ソフトウェアの設計書は必須でもないし、開発戦略を練る段階で作成するかどうかを決めればいいと思っている。 議論の前提：仕様書と設計書 議論を簡単にするために、まず「仕様書」と「設計書」という言葉を再定義しておきたい。今回の整理は以下としている。 仕様書 … 開発者とユーザー(仕様決定者)が、ソフトウェアの振る舞いや動きに関してコミュニケーションするために必要な文書類のこと。 設計書 … 開発者どうしがソフトウェアを作成するにあたっての、構造や仕様についてコミュニケーションするために必要な文書類のこと。 要は今回議論しようとしている「設計書」は、ユーザー(仕様決定者)とは無関係なものであるという前提である。また、ここ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
