ソフトウェアエンジニアリングサバイバルガイド: 廃墟を直す、廃墟を出る、廃墟を壊す、あるいは廃墟に暮らす、廃墟に死す
ソフトウェアエンジニアリングサバイバルガイド: 廃墟を直す、廃墟を出る、廃墟を壊す、あるいは廃墟に暮らす、廃墟に死す
ソフトウェアエンジニアリングサバイバルガイド: 廃墟を直す、廃墟を出る、廃墟を壊す、あるいは廃墟に暮らす、廃墟に死す
上流工程の失敗カタログ - 勘と経験と読経
他のエントリを書いているところなのだけれど、面白い資料を見つけたので紹介。私は失敗談にこそ学びがあると思っているのだけれども、こんなところに上流工程の失敗カタログがあったのだった。 「要求開発・管理ベストプラクティスとその体系化の調査研究」(PDF) (2019/4/19 リンク切れを修正) 「要求開発・管理ベストプラクティスとその体系化の調査研究」を失敗カタログとして読む 「要求開発・管理ベストプラクティスとその体系化の調査研究」はタイトルの通りベストプラクティス集なのだけれども、それぞれのプラクティス毎に想定しているトラブル事例が興味深く、そして胸が熱くなる。 本来あるはずのレアケース、例外に関する要求が出てこない 顧客から要求が出てこない。実はもっと隠された要求があるのに聞き出せていないのかがはっきりしない 顧客との期待とは異なるシステムを開発してしまうことに対して、事前に調整する手
ソフトウェア開発で学んだが使わなかったもの
開発手法など、一通り学んだが実際に使っていないものは多少なりあると思う。それらについて掘り起こしてみたい。 スクラム開発認定スクラムマスター研修には研修会場ホストという立場で数回立ち会った。認定外の研修も幾つか受講した記憶がある。書籍もそれなりに読み、Scrum Gathering Tokyoなどのコミュニティにも顔を出し、まあそれなりに色々考えて捉えてきた。でも、自分のチームでは使っていない。スクラム開発というアイデアに矛盾があるからだ。 そもそもスクラム開発ではチームの自律的な行動を良しとしており、それに対する”フレームワーク”を提供しているということになっている。イテレーション、バックログ、ふりかえり、デイリーミーティング（いまだに「朝会」って言ってる人いないよね？）、そしてそれらのお作法。誰が言ったかわからないが、それぞれの作者の意図を察するためには「守」が大事らしい。守破離の「守
組込みソフトウェア開発のプロセス改善の違和感 - プログラマの思索
先日、組込みソフトウェア開発現場のプロセス改善の講演を聞いてきて、何となく違和感を感じた。 以下は感想とラフなメモ書き。 箇条書きなのでラフなメモ。 【1】こんな講演ストーリー。 【1-1】組込みソフトウェア開発組織での課題。 経営層がソフトウェア開発を分かっていない。 工場のモノづくりと同じような感覚でマネジメントしようとして、思い通りにならないことに苛立っている。 なぜ、そんなにコストがかかるのか？ コストやロスを見える化できないのか？ これだけの開発規模で、もっと安く作れないのか？ 開発効率を向上できないのか？ 人材を計画的に育成して、もっと良い人材を揃えたい。IOTやビッグデータ、AIなどが分かる技術者を揃えたい。 (感想) メーカーの経営者から見れば、ソフトウェア開発はブラックボックスなのだろう。 モノづくりのように、なぜもっと作業を標準化して、資本(資金)と労働者を大量導入して
ビヘイビア駆動開発 ― ウォーターフォールモデルからのステップ | POSTD
ビヘイビア駆動開発（BDD：Behavior-Driven Development、振る舞い駆動開発ともいう）を実務に沿って簡単に紹介し、ソフトウェア開発プロセスに対してこの手法がどれほど有益かを説明します。 はじめに BDDで重視しているのは、フィードバックループを最小限に短縮することです。BDDはソフトウェア開発手法の進化の中で、理論的に一歩前進したものといえます。本稿ではBDDの概念と、その原型のモデルを説明します。 ソフトウェア開発者や、エンジニア部門のマネージャー職に就いている人ならば恐らく、以下の図のようなウォーターフォールモデルはよくご存じでしょう。 注釈: Waterfall model：ウォーターフォールモデル System Requirements：システム要件定義 Software Requirements：ソフトウェア要件定義 Analysis：要求分析 Progr
品質に厳しい組織で、なぜ品質が劣化するのか？ - 現場のためのソフトウェア開発プロセス - たかのり日記
このエントリーは「Software Test ＆ Quality Advent Calendar 2011」における12/18分として書いています。 12/17は @NoriyukiMizuno さんによる 「ソフトウェアテストの勉強会。1年目。」 というエントリでした。 今回は、以前から感じている矛盾について、私なりの考えをまとめたものです。 特に、マネージャーや経営層と呼ばれる人に読んでもらいたいと思っているのですが、このブログの読者層を、考えると、あまり多くはなさそうなので、以下に示す問題について、悩んでいる／苦しんでいるような人から、うまく伝われば良いと思っています。 矛盾する問題 私は、SEPG（Software Engineering Process Group）という役割上、いろいろなソフトウェア開発のプロジェクトや組織に関わってきました。 絶対数で言えば、そんなに多くはない
「バグ数には興味ないのだよ」――顧客が喜ぶテスト仕様書とは？
「バグ数には興味ないのだよ」――顧客が喜ぶテスト仕様書とは？：誰にでも分かるSEのための文章術（11）（1/2 ページ） 「提案書」や「要件定義書」は書くのが難しい。読む人がITの専門家ではないからだ。専門用語を使わず、高度な内容を的確に伝えるにはどうすればいいか。「提案書」「要件定義書」の書き方を通じて、「誰にでも伝わる」文章術を伝授する。 メーカーが機械を納入する際は、耐久試験や性能試験などの結果を添付して、問題がないことを顧客に確認してもらいます。同様にシステム開発においても、テスト結果を顧客に提示してシステムに問題がないことを確認してもらう必要があります。 今回と次回の2回にわたって、「テスト仕様書」の書き方と表現のポイントを説明します。 今回は、「顧客にとって良いテスト仕様書」とは何か、「顧客にとって良いテスト仕様書」にするためには何を記述すればよいのか、テスト仕様書のおおまかな
プロジェクト・アンチ・パターンの集大成「アドレナリンジャンキー」
一兵卒は必携、プロジェクトの腐臭を嗅ぎとれるようになる一冊。むしろ、「アドレナリンジャンキー」だったわたしに読ませたい 「アドレナリン・ジャンキー」とは、モーレツ社員（死語）、もしくはモーレツ社員で構成された組織のこと。すべての仕事は最優先で、全ての送信メールは、【！緊急！】で始まる。作業の順番は重要性ではなく、切迫度によって決められる。したがって、長期的な見通しは存在せず、全ての仕事は、ある日突然、「緊急」になるまで放置される。 こういう人や組織があることを知っておくと、「そこに染まりやすい」危険性も予測できる。だから、回避も可能だ。そもそも知らなければ、回避する／しないの判断をすることなく、あなたもアドレナリン・ジャンキーの仲間入りとなるだろう。 あるいは、「死んだ魚プロジェクト」。人は結構いるのに、妙に静かなオフィス。入ったばかりのあなたに対し、チームメンバーは気の毒そうな顔で応ずる
品質がスケジュールよりも優先される理由 - プログラマの思索
CMMIを作ったハンフリーが書いた本「ソフトウェアでビジネスに勝つ」を読んでいる。 mgさんのコメントを書きながら、考えたことをメモ。 【元ネタ】 アジャイル開発は受託開発の方が向いている: プログラマの思索 「ソフトウェアでビジネスに勝つ」の本は、経営者向けに書かれたソフトウェア管理に関する考察した本。 第1章に、SW管理の原則が3ついきなりあげられるが、その一つに「品質がスケジュールよりも優先する」という原則がある。 SW開発に従事している人ならば、この原則をいつも実感しているし、逆に、この原則に逆らうような仕事をしているのも事実だ。 設計や開発という工程よりも、テスト工程でこの原則を実行すべきかどうか判断に迷う。 仕様変更が来たけれど、バグ修正を優先すべきか？ バグ修正よりも、目先のタスクをこなすべきか？ 全てのテストをし尽くしてバグをたくさん出してから、バグ修正すべきか？ 今、僕は
「戦略的OS」の開発がことごとく失敗している点に関する一考察
９０年代にIBM、Microsoft、Apple各社が巨額の開発費を投じて作っていた「戦略的OS」がすべて失敗してしまったことを皆さんはご存知だろうか？ IBMが作っていたのはOS/2。元々はMicrosoftとの共同開発だったが、途中で仲違いをしてしまい、最後はIBMだけが細々とサポートしていたことすら覚えていない人が多いとは思うが、Windows95の成功であっというまに市場から消えてしまったのがOS/2。具体的な数値は公開されていないので分からないが、両社が数百人体制で数年間開発していたので、少なく見積もっても日本円で数百億円は投じられたことは間違いない。 Cairoの方は私自身が初期のころにいたこともあるし、最終的には「Chicago(Windows95のプロジェクト名) vs. Cairo」の戦いの最前線にいた私としては知りすぎている点も多いのだが、一つだけ確かなのは、プロジェク
エンジニアにとって働きやすい環境に必要な８つの要素 - ITで世の中をもっと便利に
ふと、独立起業するにあたり、 エンジニアにとって働きやすい環境とはどんな環境なのかを考えてみました。 自分が今働いている会社の環境、そこから導き出される不満、 その不満を解消するにはどういう環境を用意すればいいのかをまとめてみました。 1.給料が自分の納得できる金額である 給料が高いにこしたことはありませんが、 大事なのは自分がその金額に満足できるかどうかだと思います。 給料というのは永遠の課題であり、半分以上の人は満足できていないと思います。 例えば、よくある不満として挙げられるのが 他の人が自分よりも仕事をしていないのに給料が高いという不満。 もちろん、能力が低い（スキルが足りない）から同じ仕事をするにしても 時間がかかってしまい、残業が増える、その結果として給料が増えると いうのはどこの会社でもよくあることです。 能力があり、仕事や開発をサクサクできる人ほど ハイパーフォーマンスなは
レビューはペア作業であるべき - プログラマの思索
SW開発でいつもボトルネックと感じる工程がレビュー。 僕が経験した過去のどのプロジェクトも、レビュー工程は効果的と思えなかった。 少なくとも、開発者の立場では、レビューは嫌なもの。 自分の成果物にケチをつけられ、何度も直しては叩かれる。 今、管理者の立場でレビューに携わっているが、レビューが成果物の品質Upになっているとはとても言えない。 設計レビューは、設計の元ネタとなる要件定義と化している。 レビューアーにひたすら質問しまくって、本来の仕様を聞き出す。 ソースレビューは、コーディングルールの徹底と化している。 CheckStyleで十分なのに、レビューワーは業務ロジックまで分からないから、ただ直すだけ。 いつも思うのは、レビューはペアプロ、ペア作業であるべきだ。 レビューワーが、レビューイーの席の隣に座り、レビューイーのPCで成果物を見ながら、間違っている箇所はその時その場で即修正する
ページが見つかりません｜gihyo.jp … 技術評論社
指定されたページは，サイト内に見つかりませんでした。 以下の手順をお試しください。 URLを直接入力した場合，入力ミスがないかご確認ください。 リンクを辿ってきた場合，リンクミスが考えられます。リンク元サイトの管理者にお問い合わせください。 該当するページについての情報をお持ちの場合，サイト上部にある検索ボックスから検索するか，トップページから該当するリンクを辿ってください。
テストにおけるデザインパターン - 現場のためのソフトウェア開発プロセス - たかのり日記
そういえば、今日のJaSSTのパネルディスカッション（ディスカッションの内容は、「テスト技法からテストメソドロジへの進化を目指して」）で、西 康晴 先生が、「テストでもデザインパターンみたいなものがあると良い」という旨の話をしていたのですが、これはその通りだと思います。 設計においては、設計技法だけでなく、「GoFのデザインパターン」「PofEAA」といった、パターンが多く存在します。パターン自体が重要ではないとは思うのですが、パターンはベストプラクティスであり、それを適切に利用することができれば、設計品質も向上するでしょう。 テストについては、いろいろな技法はありますが、設計におけるパターンのようなものがない。私が知っているものは、「xUnit Test patterns」ぐらい。 「同値分割」「境界値」といった基本的な技法を使っている人は多いと思いますが、「直交表」「デシジョンテーブル
「5億行のシステムでも小規模とみなされる」，Roger S.Pressman氏がJaSST'09 Tokyoで語る
「システムは，今後10～20年で，複雑で多機能化してくる。5億行のプログラムが稼働するシステムでも小規模だとみなされるかもしれない」――。 特定非営利活動法人ソフトウェアテスト技術振興協会（ASTER）が主催するITエンジニア向けイベント「ソフトウェアテストシンポジウム2009東京（JaSST'09 Tokyo）」において1月28日，米国のITコンサルタントRoger S.Pressman氏がこのような見解を述べた。 Pressman氏は，ソフトウエア・エンジニアリング分野で国際的に有名なコンサルタント。「実践ソフトウェアエンジニアリング」（日科技連出版社）などの著書がある。ソフトウエアのテストや品質などをテーマとしたJaSST'09 Tokyoの基調講演で，ソフトウエア・エンジニアリングの今後のトレンドを説明した（写真）。 5億行のシステムすら小規模となるという見解を示したのは，「今後1
Tracに足りない4つの機能 - プログラマーの脳みそ
ITの地殻変動はどこで起きているのか？: プログラマの思索を読んで思い出したことをまとめておこう。 TracなどのBTS(バグ管理システム)を用いたチケット駆動の開発というスタイルで、アジャイル開発を実践されている方も多いことだろう。 私がTracを使っていて感じた不足をここに挙げておく。 インシデント管理 顧客からの要望などのインシデント票と呼ばれるものと、開発の為のタスク（チケット）は別のものだ。私も当初はこれらを混在してつかっていたのだけど、顧客からの問い合わせや要望といったものと、実際の開発作業の間には大きな溝がある。 例えば「Tracにインシデント管理機能をつけてよ」と言われた段階で「インシデント管理機能を作成」というチケットをあげてはいけない。 XPで言うところの計画ゲームをする際のタスクカードと、TODOであるところのTrac上のチケットは分けた方がいい。アイデアとしては出た
ソフト開発の効率化は会計処理改革から - プログラマーの脳みそ
あとで書きなおす。 プログラムをある程度の量書くと、いわゆる共通ライブラリ的なものが生まれてくる。個人ですら生まれてくるわけで、業務でシステム開発やってる会社となれば相応に使いまわされるプログラムというのが生まれている。しかし、ほとんどのSIerはこの使いまわされるプログラムをまったくもって管理できていないのが実態だ。 簿記と会計と財務の違いについてまとめてみた - GoTheDistanceのエントリが人気を博したが、このエントリではシステム開発における資産管理について述べたい。 費用と資産 ここでいう資産とは財務会計上の資産である。 財務会計上の資産（しさん、asset）は、勘定科目の区分の一つ。会社に帰属し、貨幣を尺度とする評価が可能で、かつ将来的に会社に収益をもたらすことが期待される経済的価値のことをいう。 資産 - Wikipedia ソフトウェアの資産の扱いについてはソフトウエ
ITの地殻変動はどこで起きているのか？～チケット駆動開発はなぜ生まれたのか - プログラマの思索
2009年になって、ITの地殻変動がどこに起こっているのか？を考えてみる。 ＃ラフなメモ書き。 【参考】 InfoQ: Martin Fowler氏が語る陥りがちなスクラムの落とし穴を避ける方法 InfoQ: 複数のアジャイルチームでのバージョン管理 チケット駆動開発 … ITpro Challenge のライトニングトーク (4) - まちゅダイアリー(2007-09-07) 【アジャイル開発の問題点】 1990年代後半から、サーバー＋クライアントの2層方式を基本とするVBアプリからMVCを基本とするWebシステムへのリエンジニアリングがあった。 更に、システムが大規模化して、開発期間が短くなるSW開発の現場。 RUPなど、イテレーティブな開発プロセスの重要性が叫ばれるものの、実際の現場で運用するにはハードルが高かった。 2000年頃出現したXPは、ソフトウェアの歴史の中で、オブジェクト
組み込み業界の比較的ポジティブな特徴 - 千里霧中
http://d.hatena.ne.jp/wa-ren/20081130/p2 少し前に上のエントリで組み込みの話が話題になっていてびっくり。ただブコメなどを見ると、やはりというか相変わらずというか、ネガティブな言及が多いようだ。 ついでなので、世間一般でいう(要はエンタープライズ系などの)プログラマの業界にはあまりない特徴のうち、比較的ポジティブというか、学生が興味を持ちそうなものを思いつくままに列挙していこうと思う。だらだらとした乱雑文になっている点はご容赦を。 最上流企業でもコーディングができる エンタープライズ系のSIerなんかとは違い、組み込み業界では最上流企業でも多くの開発や実装を行っている。 もちろん派遣、請負、外注などの外部リソースも積極的に使われているのだけれども、まとまった製品を手がけている企業では、キーデバイスやコア技術に関わる部分を扱う部門や、人材の育成が必要な領
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
テストコードのリファクタリング