ソフトウェアの世界からプロジェクトの所要時間の見積をなくそうとする#NoEstimatesムーブメントについて、Mediumの記事が紹介している。所要時間を正しく見積もることは困難であり、時間の無駄だとプログラマーたちは主張する。一方、他のプロジェクト関係者は、計画を立て、プログラマーに責任をもって仕事をさせるために見積が必要だと考えている。妥協点はあるのだろうか。 記事によれば、「ソフトウェアプロジェクトの見積は誤っていることがあまりに多く、見積を作るのに時間を使えば使うほど、実際にソフトウェアを作成する作業時間が減ってしまう。また、マネージャーは開発者が適当に作った見積を契約上の締め切りのように扱う習慣があり、見積時間内に完成しなければ大騒ぎする。それだけではない。そのような結果を恐れる開発者は、より多くのエネルギーを見積という兎の穴に注いでいく。見積はヤクの毛刈りのように、実際の仕事
こないだスロットマシーンで5700万ドル（45億円弱）大当たりの鐘がじゃんじゃら鳴って天にも昇る思いで換金に行ったらカジノに｢あ〜ソフトウェアの不具合で鳴っちゃったみたいですね｣とドン底に突き落とされた男性がオーストリアに約1名いましたが、いやあ、上には上ですね。 ソフトウェア品質保証の英SQS社が｢今年最も被害額が高くついたコンピュータの不具合｣を5つ集めてくれました。 1. 証券投信投資顧問会社のアクサ・ローゼンバーグは、投資モデルのソフトウェアの不具合で、投資家のお金2億1700万ドル（170億円弱）がパーに。その損失プラス、顧客にバグのことをひた隠しにしていたことで米証券取引委員会に2500万ドル（20億円弱）の罰金。1%の金持ちも大変ね。 2. ホンダは、駐車しても車体が動いたりエンストする不具合で250万台リコール。コード何行か書き損じるだけでこれは...痛い。 3. みずほフ
「見積もり」は、ソフトウェア開発における大きなテーマであり、ソフトウェア工学における最重要課題の1つでもあります。 前回からお届けしている“見積もり・シリーズ”では、「見積もりの目的（正確に見積もるだけでは不十分）」「見積もりの具体的な方法（精度を上げるため、少なくとも2つ以上の方法で見積もる必要がある）」「見積もりの応用（見積もり値に合わせる制御と再見積もり）」「見積もりの調整（状況に応じて開発量とスケジュールを再見積もりしなければならない）」について、具体的に解説していきます。 シリーズ2回目となる今回は“昔の見積もり技法”を解説します。見積もりを含めたプロジェクト管理は、過去30年以上、ほとんど進歩しておらず、
元GE技術者・菊地洋一さん講演 「命はほんとうに輝いている」の一部をパロってみた。 いろいろやってきたわけですけれども、実際に働いてみますと、システム開発の技術というのは全然確立していなかった。もう詳しい話は技術的な専門的な話になりますのでいいませんけれど、とにかくハチャメチャなんですね、施工で。施工というかシステムを造っていく開発の段階で。開発のミスが出るということは人間のやっていることですから、よく起こることですけれども、問題なのは設計そのものも十分検討されていない、いいかげんな感じで開発が進められていました。ですか ら開発中にしょっちゅう変更がある、そのことにもびっくりしましたけれども、送られてくるモジュールのインターフェースがあちこちぶつかっていたり、そういうことにもびっくりしました。自分でチェックしてみて余りにもぶつかっているので、びっくりしましたけれども、とにかく確立された技術
ソフトウェア工学の祖の一人である、トム・デマルコが、最近IEEE Software 誌に、過去のソフトウェア・メトリクス賛美を悔い改める記事を書いている。 「ソフトウェア工学」というコンセプト－その時が来た、そして、その時は去った。http://www2.computer.org/portal/web/computingnow/0709/whatsnew/software-r 1982年に、デマルコは有名な「計測できないものは制御できない」という一文から始まる、『品質と生産性を重視したソフトウェア開発プロジェクト技法』という名著を書いている。このドグマは、ソフトウェア工学の考え方に強く根ざしている。むしろ、すべての「工学」という活動は、科学や経験から得た知見を使って自然現象をコントロールし、人間の役に立てることをその定義としており、そこでは測定を元にしたコントロールという概念はその中核にあ
正しいシステムを作ることがゴールである この“正しい“という意味をちゃんと定義しなくてはいけないのだが、これも一見”正しい“ように思えます。ここには二つの間違いが潜んでいます。その正しいののは誰にとって正しいのかということと、作ることが目的なのかということである。 前者の誰のために正しいかについては、往々にして作り手側すなわち開発ベンダーや開発者にとってではないでしょうか。データベースの設計は技術基準にしたがってやりました、コードは社内のコード標準であり、プロジェクト管理はPMBOKに則りやりましたとなる。 そして、ユーザの要求からシステム要件に落としてその通りに開発をして、テストでも問題ないことを確認しましたである。ここには、そのシステムが役に立つものであるのか、ビジネス要求に応えるものであるのか、事業に貢献できるもにになっているのかという視点がないのである。だから、正しいではなく役に立
システム化プロジェクトは開発するもの 前回は、はなからITシステムを入れるということではなく、それぞれの会社の事情や成熟度に応じて、場合によってはITを使わないでシステム化をする方がいいケースもあるというようなことを書いた。ここでは、システム化プロジェクトで開発をしてしまうという間違いについての話です。 こう言うと、怪訝な顔をする人も多いと思います。だれしもが、普通に”システム開発“と言います。しかし、業務アプリケーションのことでいえば、業務の仕組みを開発するのですかとツッコミたくなる。ソフトウエアやツールであれば確かに開発ですが、業務の場合、開発するとはいったいどういうことなのだろうか。 そのまま字句通りに解釈すると、業務の仕組みあるいは業務プロセスをそうしたプロジェクトで開発すなわち新たに作り出すことを意味する。そんなことをシステム化プロジェクトでやるんですか。そもそも何とか管理システ
いまあらためて確認したい、情シスのイロハ（前編）：何かがおかしいIT化の進め方（47）（1/2 ページ） IT現場の課題や悩みは尽きることがない。問題は、その悩みや課題が解決されることも、時代とともに変わっていくこともなく、いつまでも同じ問題を引きずっていることだ。今回は基本に立ち返り、情報システム部門としてあるべき発想・行動のポイントを整理してみた。 もう一度「情シスの基本」を振り返っておこう 先日、ユーザー企業数社の中堅、若手のマネージャが「IT部門の在り方」を研究している勉強会に呼んでいただいた。主催者が本連載の第24回『情報システム部は、もうその役割を終えてしまったのか』を読んで下さったらしく、「その次を知りたい」「答えを知りたい」ということのようであった。2時間の予定が3時間を超えるディスカッションになってしまった。 この中で大変気になったのは、数年前にも感じた「IT部門の役割」
日米で異なるソフトウェアの作り方 私がシアトルに来たのは1989年なので、こちらに来てもう20年以上になる。最初の10年をMicrosoftのソフトウェアエンジニアとして過ごし、後半の10年は起業家としてソフトウェアベンチャーを3つほど立ち上げている。こうやって1年の大半を米国西海岸で過ごしながらも、日本には毎年数回仕事で帰国しているし、日本語でブログや記事を書いてもいて、ある意味で「日本のソフトウェアビジネスを、一歩離れてちょうどよい距離で見る」ことができる立場にいる。 そんな私が常々感じているのは、日本でのソフトウェアの作り方が米国のそれと大きく違っていること。そして、日本のソフトウェアエンジニアの境遇が悪すぎること―そして、それが「日本のソフトウェアが世界で通用しない」一番の原因になっていることである。 そもそもの成り立ちが違う日米のソフトウェア業界 日米のソフトウェアの「作り方」の
文・稲葉 崇志（NTTデータ経営研究所 情報戦略コンサルティング本部 コンサルタント） 情報システムやサービスにおけるパフォーマンスベース契約（PBC：Performance Based Contracting）とは、サービス･システムの対価の一部、または全部について、サービスやシステムによって創出されるパフォーマンスにもとづいた価格設定を利用する契約の手法です。 経済産業省は2007年度より、新たな見積・契約額決定の手法として、情報システムから創出される価値、実績に着眼したプライシング（『パフォーマンスベース価格設定、契約』）の調査研究を実施しています。 情報システムやサービスの調達におけるパフォーマンスベース契約の具体的なイメージとして、以下に3つの例を紹介します。 1.利益やコストを分配する契約 情報システムの開発や運用だけでなく、企画・設計・運営業務までを含むアウトソーシングにおい
2007/09/03 日記: 望ましいソフトウェアの構造 , Java言語について思うこと [いがぴょんの日記v2,diary,igapyon] ふと 望ましいソフトウェア構造などを 徒然に書いてみました。 広告: BlancoEclipseDistribution 最新安定版 (3.4.1-20080925) リリース 10/01 最新版の Eclipse である Eclipse Classic (SDK) 3.4.1 一式 (日本語化済み) が Windowsインストーラを用いてインストールできます。 BlancoEclipseDistribution は Eclipseディストリビューションのひとつに該当します。 ふと 望ましいソフトウェア構造などを 徒然に書いてみました。現在 一気に書き下ろした状態なので、あまり一貫性や論理性は無いかも知れません。後日 ふりかえって添
「ソフトウエアの品質をどう測るのか」「リスク要因を見積もりにどう反映すればよいか」。多くの現場では経験を積んだベテラン技術者の頭の中にあるだけだろう。ジャステックでは，それを“指標”という形にまとめて業務の中で回している。ベテラン技術者の暗黙知を，指標の項目とその基準値という形式知に変換している。 考えられるあらゆる現場のノウハウを指標に落とし込む。「見積もりの精度を測る指標」「テストの精度を測る指標」――。 どのような指標を設定するかは現場のノウハウの固まりである。それは通常，ベテラン技術者の頭の中に暗黙知として存在しているものだ。ジャステックの開発現場では，その暗黙知を指標という形で形式知化している。指標をすべての現場で共有することで，現場から現場へ技術の伝承が図られているのである。 ここにジャステックの現場のすごみがある。現場の技術者たちの指標への執念が，営業利益率11％（2006年
昨日読んだ本。いろいろ考えさせられる本だった。 「派生開発」を成功させるプロセス改善の技術と極意 作者: 清水吉男出版社/メーカー: 技術評論社発売日: 2007/10/27メディア: 単行本（ソフトカバー）購入: 10人 クリック: 127回この商品を含むブログ (28件) を見る 当書籍では、「派生開発」という用語を「新規開発」以外の開発すべてを指す用語として使用している。「派生開発」は、改修や機能追加のすべてを含む。 ※「派生開発」は、著者が作成した用語である。 よく知られている通り、ソフトウェアライフサイクルの殆どはこの「派生」に属し、費用も新規開発の何倍もかかる。従って、この部分をどれだけ効率よくできるかが、TCOの削減に大きく寄与する。また、当然のことながら、「派生」で障害が発生すると業務に支障が出、顧客に迷惑をかけることがあるため、重要度はとても高い。 にも関わらず、「派生」
シリコンバレーのAgile開発者メーリングリストに届いた求人広告。Moody'sの子会社。 Company: Moody's Analytics Position: Senior Software Engineer Location: San Francisco, CA Moody's Analytics, a subsidiary of Moody's Corporation, is the world's leading provider of market-based quantitative credit risk products for credit risk investors. Moody's Analytics is recognized as the pioneer & market leader in credit risk measurement & managem
当初ははっきりとしていたシステム構築の目的が，徐々にすりかわり，完成したときは異なるものになっていたということが往々にしてある。しかし計画変更そのものが当初の目的と比較してどうだったのか，最終的に出来上がったシステムは何を実現しているのかを明確にしておくことは極めて重要だ。最初の目的と，それをチェックするための評価基準は，必要とする者が常に確認できる形にしておかなければ意味がない。 本記事は日経コンピュータの連載をほぼそのまま再掲したものです。初出から数年が経過しており現在とは状況が異なる部分もありますが，この記事で焦点を当てたITマネジメントの本質は今でも変わりません。 玩具メーカーのT社では，1年前に物流システムを再構築して，製品・半製品の倉庫を自動化した。受注から出荷までのリードタイムの短縮と，在庫管理・配送管理の徹底が目的である。自動倉庫ではすべての製品にバーコードを張り付けて，工
散歩に行ってはいけない？ どうして業務中に散歩に行けないんだろう？という疑問から考えてみた。 僕は協力会社としていろいろな会社のプロジェクトに参画している。 でも、いまだかつて散歩に行けたプロジェクトはない。 10分散歩していいですかと聞いてOKと言われたことはない。 システム開発業界に喫煙者が多いのは、明らかにこれと関連がある。 つまりタバコを吸いに喫煙室にでも行かない限り、気分転換の口実は与えられていないってことだ。 肉体労働は いったい日本のシステム開発は、いつまで肉体労働での成果物の考え方に縛られているんだろう。 僕の考えはドラッカーに影響されてるけど、もしも肉体労働であれば就労時間と成果物の量は比例するので散歩なんてさせられないのはわかる。 たとえば、工場のベルトコンベアで何かを作るとして、同じ人であれば時間が長い方が多く作れる。 同時に、肉体労働での生産性の個人差というのは何十
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く