テスト駆動開発とマイクロサービスのせいで短命に終わったスマホゲームの話
「悪い方が良い」原則をご存じだろうか？ プログラミング言語「Common Lisp」の開発に携わったことでも知られるソフトウエア技術者リチャード・ガブリエル（Richard Gabriel）氏が1990年に発表した有名なエッセイ「The Rise of ``Worse is Better''」で主張したソフトウエア開発の考え方だ。 このエッセイでガブリエル氏は、美しく完全に設計・実装されるより、単純で雑に設計・実装されたソフトウエアの方が良いと説く。彼は前者を「正しいやり方」「MIT/スタンフォード式」、後者を「悪い方がよい原則」「ニュージャージー式」と呼び、ニュージャージー式がいかに優れているか様々な事例を挙げて説明する。 これは一見とても奇妙に聞こえる。 ソフトウエア開発では通常「美しい設計」や「美しいコード」が尊まれる。「車輪の再発明はするな」とか、「階層構造に分けて、要素をいつでも
二択で決めるマネジメントに明日はない
前回は籠城戦の話を書きました。「援軍の来ない籠城戦は全滅を意味する。だから打って出なければダメだ」という話です。 自分で書いておいて、今さら何をいうのかと言われそうですが、マネジメントの観点からすると、このストーリーはダメなマネジメントの典型だと思います。 ITproの最近の記事を見ると、クラウドを使わないITビジネスにはみじめな未来しか残されていないような印象を受けます。これに限らず、ITの世界では輝かしい理想の姿をもてはやし、「そこへ行かなければ明日はない」とする二択の論調が以前からよく見られます。 読者のみなさんの日々の職場でも、こんな議論が日々繰り広げられているのではないでしょうか。 クラウド市場の成長を取り込まなければ、明日はない DevOpsをやらなければ、明日はない グローバル市場で活躍できる会社でなければ、成長はない 若手の活躍がなければ、明日はない 明日はないと言われ続け
「もんじゅ」はなぜ廃炉に追い込まれたか
政府は、2016年12月21日、長らく懸案事項だった高速増殖原型炉「もんじゅ」の廃炉を正式決定した。「もんじゅ」は結局、設計通りの定格出力運転を一度も達成せず、廃炉に至った。日本どころか世界的にも歴史的な不祥事である。産業技術者は、二度と同じ過ちを犯してはならない。何が原因なのか、歴史から学ぶことは、あまりにも多くある。 私は「もんじゅ」廃炉の真の原因は、ナショナル・プロジェクトの発足からの半世紀もの間に蓄積した矛盾にあると考えている。この矛盾が長期にわたり、ボディブローのように効いてプロジェクト自体の体力を消耗させてきた。事故や不祥事は限界点に達した組織を崩壊させる引き金を引いたにすぎない。それを説明する前に、まず、もんじゅプロジェクトの前段階から話を始めたい。
Part3 ［事例］IT現場で実践するポスト「モダンPM」
出典：日経SYSTEMS，2016年5月号 p.57-62 （記事は執筆時の情報に基づいており、現在では異なる場合があります） 第一線のIT現場ではどんなポスト「モダンPM」を実践しているのか。PART3では、プロジェクトマネジャー6人に、独自のポスト「モダンPM」を聞く。いずれも変更を受け入れるものだが、そこには独自の工夫がある。 その1 岡田 大祐氏 小さく早くつまずく「失敗マネジメント」 関西に拠点を置くある流通業のIT部門に、2012年からプロジェクトマネジャーとして赴任したケンブリッジ・テクノロジー・パートナーズの岡田大祐氏（ディレクター）。当時、岡田氏の大きな悩みは、たった1人のメンバーの進捗遅れが、複数のプロジェクトに一気に及んでしまう状況だった。 というのも、この企業では小規模の複数プロジェクトが同時並行して進む上に、ほとんどのメンバーが各プロジェクトを掛け持ちしていた。「
UMLやSysMLを活用できないエンジニアのための実践的活用術（前編）
UMLやSysMLを活用できないエンジニアのための実践的活用術（前編）：プロジェクトを成功させるモデリングの極意（1）（1/6 ページ） モデリングの手法やツールの基礎を覚えるだけでなく、モデリングの目的やその本質をつかんで、ソフトウェアの開発現場で実際に役立つように基本を学んでいきましょう。 はじめに 本連載ではソフトウェア設計を行うために必要不可欠な技術であるモデリングについて紹介していきます。第1回である今回は「モデルとは何か？」から始め、モデルの目的からモデルに求められるものを前編で、モデリング手法やツールを後編で紹介したいと思います。 モデルとは モデルとは物事を分かりやすく説明するために、不要な部分を捨て、注目するところのみを記述したものです。このモデルという用語は広く使われている用語で、「マクロ経済モデル」や「流体モデル」などのように一般の用語となっています。 ソフトウェア開
ソフトウェア開発プロジェクトが大ごけする“カラクリ”
ソフトウェア開発プロジェクトで致命的な失敗を引き起こす、「仕様の誤解」が発生するメカニズムを詳しく解説します。 ソフトウェア開発プロジェクトが失敗する2大要因が、「見積もり」と「仕様」のミスや誤解です。両方で失敗原因の95％を越えます。 オフショア開発など、こちら側で仕様を書き、その仕様を外部の組織に送って外部のプロジェクトで開発する形態では、「見積もりミス」はこちら側の責任ですが、仕様関連の失敗は、こちら側と向こう側の両方が原因となります。 「レバーを90度回してください……」 仕様書を読んで、「ここは、十分に理解できない」とか、「この機能を実現するには、複雑な処理が必要になりそうだ」という箇所は、お互いに注意をするのでミスは意外に多くありません。ですが、「自信を持って誤解する機能」は非常にタチが悪く、致命的な大問題に発展する場合も少なくありません。 例えば電車のドア付近に「非常時は座席
炎上した「20億円プロジェクト」、なぜオルビスは火を消せたのか
化粧品通販大手のオルビスは2014年3月から、公式サイトの機能を大幅に強化した（画面）。アクセスしてきた顧客の属性や購買履歴を分析し、表示するWebページを動的に生成。表示する化粧品やサプリメントの価格を、リアルタイムで変更しているのだ。 ある化粧水の場合、過去に同一商品を購入した経験のある顧客には1500円を提示し、ない場合は「特別価格」として1300円で販売するといった具合だ。価格だけではない。ダイエット食品の購入経験に応じて、関連商品が当たるキャンペーンサイトに誘導したり、「美白に興味がある50代女性」に絞ってクーポンを配信したりしている。 「顧客一人ひとりの属性や嗜好に合った情報を、素早く提示できるようになった」と、オルビス情報システム部長の前山純男は自信を見せる（写真1）。消費増税前の駆け込み需要を割り引く必要があるが、購入単価の向上などで手応えを感じているという。 以前は、顧客
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
