以前XP祭りでLTしたものの10分版。 「せっかく作った物が喜んでもらえない」 「仕様だ、バグだ、の不毛な争い」 「振り回されて疲弊するエンジニア」 など、受託開発でうまくいかない局面は多くあるが、ある一つのことを意識的に行うようにしたら、自分たちの受託開発が180°変わった、という話。
○○したら受託開発が180°変わった(10分版)
以前XP祭りでLTしたものの10分版。 「せっかく作った物が喜んでもらえない」 「仕様だ、バグだ、の不毛な争い」 「振り回されて疲弊するエンジニア」 など、受託開発でうまくいかない局面は多くあるが、ある一つのことを意識的に行うようにしたら、自分たちの受託開発が180°変わった、という話。
「コードの読まれ方が分かった」、工数見積もり精度向上に寄与
「コードの読まれ方が分かった」、工数見積もり精度向上に寄与：奈良先端科学技術大学院大学 森崎修司氏らが発表 「ソースコードの読まれ方の傾向がまた1つ明らかになった。これで派生開発、保守開発の工数見積もりの精度が向上する」――奈良先端科学技術大学院大学 森崎修司助教らの研究グループは、2009年9月～11月にかけて行ったソースコードリーディングのオンライン・ハンズオン、2010年1月、2月に行ったイベント「ソースコードリーディングワークショップ」、ほか3回におけるハンズオンの分析結果を発表した。 総計126人に、保守／派生開発プロジェクトを模した形式で複数のソースコードを読んでもらい、それぞれにかかった時間を計測、分析したところ、「ソースコードの読解時間はソースコードの行数だけで予測することは難しい」「大規模な変更の場合、コードレビューの経験があるとソースコードの読解時間を短縮できる」ことな
「バグ数には興味ないのだよ」――顧客が喜ぶテスト仕様書とは？
「バグ数には興味ないのだよ」――顧客が喜ぶテスト仕様書とは？：誰にでも分かるSEのための文章術（11）（1/2 ページ） 「提案書」や「要件定義書」は書くのが難しい。読む人がITの専門家ではないからだ。専門用語を使わず、高度な内容を的確に伝えるにはどうすればいいか。「提案書」「要件定義書」の書き方を通じて、「誰にでも伝わる」文章術を伝授する。 メーカーが機械を納入する際は、耐久試験や性能試験などの結果を添付して、問題がないことを顧客に確認してもらいます。同様にシステム開発においても、テスト結果を顧客に提示してシステムに問題がないことを確認してもらう必要があります。 今回と次回の2回にわたって、「テスト仕様書」の書き方と表現のポイントを説明します。 今回は、「顧客にとって良いテスト仕様書」とは何か、「顧客にとって良いテスト仕様書」にするためには何を記述すればよいのか、テスト仕様書のおおまかな
鈴村さんが指南する業務フロー図の上手な書き方
まずは，業務フローの例を見てみよう。UMLのアクティビティ図で書いたのが（図1）である。スイムレーンに役割を書き，上から下（または左から右）に向かって業務の進行を書いていく。かどの丸い四角形で示したアクティビティが業務プロセスに対応し，矢印で示したフローが業務の流れになる。「誰が何をするか」が明確になる。 よほど定型化されたものでない限り，業務とは複雑なものである。厳密に書こうとすると，業務フローも複雑になりがちである。しかし，分かりやすさを重視するなら，一つの業務フローに登場するアクティビティはせいぜい10～15程度にとどめるべきだ。 複雑なフローを表現したければ，一部の業務フローを別に切り出して，サブ業務フローとして記述すればよい。親の業務フローのある業務プロセスの内部が，サブ業務フローとなっているというように階層化する。 スイムレーンには顧客や営業担当など役割を設定する。「松山さん」
「有能な人がコードを書くべき」「意志決定はできるだけ先延ばし」「契約を変えるのは難しい」アジャイルの専門家の答え － Publickey
日本での開発プロジェクトのほとんどではウォーターフォール型の開発手法が採用されており、アジャイルソフトウェア開発手法の採用はまだ数％程度といわれています。12月8日に都内で開催されたイベント「Agile Conference tokyo 2009」では、米国でアジャイルソフトウェア開発のコンサルタントなどを行っているThoughtWorksのマネージングディレクター、Xiao Guo氏が会場からの質問に答えるトークセッションが行われました。 このセッションでは、多くのエンジニアが現場でアジャイル開発ソフトウェア手法の導入や運用で悩んでいること、疑問に思うことを率直にGuo氏に投げかけています。セッションでやり取りされた質問と回答の一部を紹介しましょう。 意志決定を先延ばしすること 質問 日本のSIerに務めています。日本では、設計書をエクセルを使って画面や処理などの書類を作成しています。海
バッドシグナル通信 記事一覧 | gihyo.jp
運営元のロゴ Copyright © 2007-2025 All Rights Reserved by Gijutsu-Hyoron Co., Ltd. ページ内容の全部あるいは一部を無断で利用することを禁止します。個別にライセンスが設定されている記事等はそのライセンスに従います。
情報システム関係の人とかこれ見とくといいよ - チョコっとラブ的なにか
こんなの出てたから、見ておくといいかもね。 経済産業省では、情報システムの取引において、現行の「人月方式」以外での価格決定方法を模索するため、情報システムの付加価値に着目して価格を決定する「パフォーマンスベース契約」について検討を行ってまいりました。 今般、「情報システムのパフォーマンスベース契約に関する調査研究」報告書として取りまとめましたので、公表いたします。 「情報システムのパフォーマンスベース契約に関する調査研究」報告書の公表について - 経済産業省 本文のさわりにはこんなことが書いてあったよ。 1 はじめに 1-1 背景と目的 我が国の情報システム市場は、現在、主として「人月ベース」の価格表示を行っており、それに伴う価格の根拠がユーザ側の価格への不信感につながっていることは従来から多数指摘されている※が、残念ながら、この課題は現在まで業界全体として抜本的に解決されるには至っていな
開発工程でSEが書く文書の基本 − ＠IT自分戦略研究所
「提案書」や「要件定義書」は書くのが難しい。読む人がITの専門家ではないからだ。専門用語を使わず、高度な内容を的確に伝えるにはどうすればいいか。「提案書」「要件定義書」の書き方を通じて、「誰にでも伝わる」文章術を伝授する。 SEはさまざまな文書を作成する必要があります。その中でも、提案書や要件定義書の作成に悩むSEは多いようです。なぜなら、これらは「顧客に読んでもらわなければならない文書」だからです。 本連載では、「誰にでも分かる」提案書や要件定義書を作成するための文章術を解説します。ただし、分かりやすい文書を作成するには、文章術だけでは十分ではありません。必要な情報を顧客から引き出すためのコミュニケーション、文書全体の構成も重要です。 第1回では、SEが作成する文書はどのようなものかを概観します。第2回では、情報を引き出すための顧客とのコミュニケーションのポイントを説明します。第3、4回
最近SIerがだいぶヤバくなっている件 - GoTheDistance
via IT業界から思ったことを。 Twitterでつぶやいたら結構こんな感じで厳しい状態になっているSIerが増えているようなので、僕なりに現状をまとめてみる。 よくわかるSIer涙目の構図 サブプライム、金融危機でSIerのお得意様の金融・メーカー様が大打撃を食らう。 2008年はとりあえず様子見で予算編成は据え置きだったが、今年に入って財布にチャックがかかる。 先行き不透明なので、GW明けぐらいの今期のIT予算が相当カットされた数字になった所が続出。 計画していた新規案件を中止するなどする。運用でなるべくカバーする方向へお客様が動く。 その結果SIerは新規案件がなくなる。案件自体がなくなっていく。予算が無いから当たり前。 大手がプロパーの仕事がなくなってきたのでプロパーで人数減らしてまわし始める。 プライムで食い込んでいるお客様の仕事が減ってきたので、外注に仕事が依頼できる余裕がな
システム開発に欠かせない契約の基礎知識まとめ - GoTheDistance
先日識者の方に色々教わったのでメモっておきます。知ってそうで知らない、元々よくわからない、そういう方に向けてまとめてみました。 僕がSIにいた頃は大抵｢基本契約｣と｢個別覚書｣ってのがありました。納期とかお金とかそういうのは個別覚書に書かれたりしていました。 開発の契約体系 ｢仕様策定〜開発まで｣と｢保守運用｣で別契約にすることが多い。 ｢仕様策定フェーズ｣で1つの契約にして、別に新しく契約を締結しなおせるほうが望ましい。リスクが低減できる。 仕様策定までは準委任、開発は請負、保守運用は準委任という契約が多い。 ちなみに準委任は｢事務作業の代行｣という意味合い。委任は｢法的効力がある作業｣の代行。サムライビジネスは後者が多い。 別に運用が事務作業とイコールじゃないけど、成果を問わないタイプの契約の場合は役務提供という位置づけになる。 かといって契約で｢僕らのコンサル案を僕らが実施し成果が出
DB設計時のサイズ見積もり - よねのはてな
ここのところ、javaccとawsに魅了されている米林です。 よく使うDB(Oracle/MySQL/PostgreSQL/SQLServer)における設計時のサイズ見積もりで使うサイトの備忘録。 あとは、OracleからのPython情報。 Oracle Oracle 物理設計 http://www.oracle.com/technology/global/jp/columns/skillup/oracle9i/index.html 領域サイズ見積もり http://otn.oracle.co.jp/document/estimate/index.html OTNにログインする必要ありますがオンラインで見積もりが出来ます。 アカウント持っていない人は、この見積もりツールを使う目的でアカウントを作ってみてはいかがでしょうか。 OLTP系とDWH系においてブロックサイズを考慮し、DWH系はブ
エンジニアがタイトル買い、著者買いすべき本 - Fight the Future
著者買いすべき本！ ファウラー、ジョエルは知名度もあり、改めて僕がどうこう紹介する必要はないと思うけど、ここではスティーブ・マコネルを特に推したい。 読んだ人には非常に高い評価を得ているけれど、その分厚さや価格もあってなかなか広まっていない。 特にCode Completeはすべてのエンジニアが必ず読むべき本だと思ってる。 これを読んで理解する／しないが(職業プログラマとしての)初級と中級の境界だと言えるくらい。 タイトルにはCodeとあるけど、別にコーディングをターゲットにした本ではない。 設計、テストも含めてコーディングを考えている。当たり前だがコーディングだけではコーディングはできないからだ。 上下巻1,200ページの大作だし、2冊で12,000円だがその価値は大いにある。 スティーブ・マコネル ソフトウェア見積り―人月の暗黙知を解き明かす 作者: スティーブマコネル,久手堅憲之,S
GT Nitro: カーレーシング・ドラッグレーシングゲーム - Google Play のアプリ
GT Nitro: Car Game Drag Raceは、典型的なカーゲームではありません。これはスピード、パワー、スキル全開のカーレースゲームです。ブレーキは忘れて、これはドラッグレース、ベイビー！古典的なクラシックから未来的なビーストまで、最もクールで速い車とカーレースできます。スティックシフトをマスターし、ニトロを賢く使って競争を打ち破る必要があります。このカーレースゲームはそのリアルな物理学と素晴らしいグラフィックスであなたの心を爆発させます。これまでプレイしたことのないようなものです。 GT Nitroは、リフレックスとタイミングを試すカーレースゲームです。正しい瞬間にギアをシフトし、ガスを思い切り踏む必要があります。また、大物たちと競いつつ、車のチューニングとアップグレードも行わなければなりません。世界中で最高のドライバーと車とカーレースに挑むことになり、ドラッグレースの王冠
そろそろバグ管理についてひとこと言っておくか - 平凡なエンジニアの独り言 はてなブログ出張所
ひとことどころか、バグ管理について367ページにわたって書いてしまいました。「実践バグ管理」です。なでしこなどで有名なid:kujirahandさん（クジラ飛行机さんのブログ）との共著です。 実践バグ管理―プロジェクトを成功に導くための 作者: クジラ飛行机,あかさた出版社/メーカー: ソシム発売日: 2009/03メディア: 単行本購入: 6人 クリック: 148回この商品を含むブログ (21件) を見る 本書の特徴 本書の特徴を伝えることには非常に苦労しています。「バグ管理なんて何について書くの？」とかよく言われるわけです。バグ管理のやり方なんてあたりまえ・・・なのかもしれませんが、大抵のプロジェクトに参加すると以下のような現象に遭遇するものです。 Tracなどの運用を始めると、「バグレポートに何を書けばいいのか？」と質問される バグレポートに書かれている内容が意味不明 とある案件では
実践バグ管理（ソシム刊）
2009年3月17日 ■著者 クジラ飛行机／あかさた ■定価 2,940円（本体価格 2,800円） ■プロジェクトに失敗は許されない！根性だけでバグはなくならない。デスマーチが始まる前に絶望を希望に変える管理術。 はじめに 本書はバグ管理に関する本です。システム開発におけるバグ管理の重要性と、そのやり方に関す るノウハウを共有する目的で書きました。 最近では、使いやすいオープンソースのバグ管理システム（BTS）が複数登場しています。それ により小さな開発プロジェクトや個人でつくっているソフトウェアでも、バグ管理システムを活用 するようになっています。そこで本書では、バグ管理システムを利用して、どのようにバグの管理 を行っていくのか、バグレポートをどのように書いたらよいのかなど実践的な内容を扱います。 本書では著名なバグ管理システムの使い方を紹介することよりも、ツールに依存しない本
プログラマの誇りを減衰しないビジネスモデルを - GoTheDistance
アツいエントリなんで思わずTBうってみる。 この業界の問題、それはプログラムが、新人〜3年目の作業と位置づけられていることだ。 プログラマーの誇りを見せ付けろ - 山本大＠クロノスの日記 正確に言うと上級プログラマも初級プログラマも同じ値段で評価されるってことが弊害である、ってことだと思います。予めXXX万円で作ってねという予算が決まっていて、その予算をオーバーしないことだけが成果の基準にあることが問題だと考えます。このルールにおいては、極論ですがコード品質が高くても低くても大差が無くねっていう力学が働きます。 基本的にニッポンの受託開発のプロジェクトの場合は、大きく２つのプレイヤーがいます。 案件を立ち上げてお客さんへのコミット権限がある人・会社 立ち上げた案件をシステム化してデリバリする人・会社 ですが、今の流れでは工程が分断されちゃっているので、案件を立ち上げる人とシステム化してデリ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Amazon.co.jp: ソフトウエア・クリエイティビティ: ロバート・L・グラス (著), 平鍋健児 (監修), 高嶋優子 (翻訳), 徳弘太郎 (翻訳), 森田創 (翻訳), 平鍋健児 (読み手): 本
Amazon.co.jp: アート・オブ・アジャイル デベロップメント ―組織を成功に導くエクストリームプログラミング (THEORY/IN/PRACTICE): James Shore (著), Shane Warden (著), 笹井崇司 (翻訳), 木下史彦(監訳) (読み手), 平鍋健児(監訳) (読み手), 木下史彦(監訳) (監修), 平鍋健児(監訳) (監修): 本
Amazon.co.jp: 実践バグ管理: プロジェクトを成功に導くための: クジラ飛行机, あかさた: 本
Amazon.co.jp: Release It! 本番用ソフトウェア製品の設計とデプロイのために: Michael T. Nygard (著), でびあんぐる (翻訳): 本
