InfoQ ホームページ Business Value に関するすべてのコンテンツ
-
アジャイルとリーンを組み合わせる
アジャイルとリーンはソフトウエア開発を改善する方法だ。マネージャはどちらが自分たちの組織に適しているか判断しなければならない。しかし、解決しなければならない問題によっては複数の方法を組み合わせることもできる。
-
アジャイルのレトロスペクティブに目標と仮説を加える
アジャイルレトロスペクティブを正しく実施することによって，チームは自ら学び，向上することができる。さらに目的を設定し，仮説を使ってレトロスペクティブ活動が改善に結び付いているかを評価することにより，レトロスペクティブはより効果的なものになる。
-
CMMIを使用した成果主導の改善プロセス
CMMIを基盤とするプロセス改善プログラムは多くの場合，特定の成熟度レベルの達成を目標に据える。組織としては，成熟度レベルとビジネス上の目標との関連性を見通し，改善によって期待できるビジネス上のメリットを知ることが重要になる。CMMI成熟度を基準としたものから成果主導アプローチに改善プログラムを変更することについて，Michelle Krupa氏にインタビューした。
-
スクラムを使ってFloraHollandのビジネスを変える
FloraHollandは日々の業務と平行してビジネスユニットのゴールを変えたいと考えており、スクラムを使って変革を実行した。XP Days Benelux 2013カンファレンスのセッションで、Job Demands-Resources modelを使って複数のビジネスユニットにスクラムとアジャイルの要素を適用し、仕事の仕方を変えたことが紹介された。
-
エンタープライズ領域にリーンスタートアップの手法を導入する
どの製品を作るのか、既存製品にどんな機能を追加するのか決定するのは難しい。リーンスタートアップの手法は顧客のニーズを理解し、ニーズにあった製品とサービスの周囲に持続可能なビジネスを構築することを手助けする。企業がより革新的で競争的になるには、どのようにしてリーンスタートアップの手法を導入すればいいのか。
-
リアルオプションを使った意思決定
Pascal Van Cauwenberghe氏によれば、プロジェクトも製品開発も困難な意思決定の連続だ。そして、リアルオプションは正しい決定を正しいときにすることを支援してくれる、という。Agile Tour Brusselsカンファレンスで、Pascal氏はリアルオプションを使った意思決定のついて自身の経験を発表した
-
アジャイルのレトロスペクティブは省略可能か？
チームは時にレトロスペクティブの省略を考える。時間的なプレッシャを感じているとき，直接的なメリットが感じられないときなどだ。彼らは自問自答する – レトロスペクティブを続ける必要があるのだろうか？ しかしアジャイルのレトロスペクティブは，チームが継続的に学び，進歩するために必要なものだ。チームの成熟のためにも，継続するだけの十分な理由がある。
-
イノベーションのための時間を作り出す
競争力を維持するために企業は，組織内部でイノベーションを行う方法を探している。その最初のステップは，新たな製品やサービスについて考え，アイデアを議論し，概念を生み出すための時間を確保することかも知れない。そのためのアプローチには，”フルタイム"の専任チームの設置，イノベーションのための十分な時間の確保，あるいは短時間かつ集中的なイノベーションワークショップの編成など，さまざまなものが考えられる。
-
アジャイルの柔軟性 : 短所か長所か
“計画に従うのではなく変化に対応する”ことは実践では役に立たないアジャイルの強みなのだろうか。例えば、過度の柔軟性を期待する顧客と変化を管理しなければならないプロジェクトの難しさはどうだろう。アジャイルは期待される効果を発揮できないのだろうか。それとも、チームや組織がアジャイルを導入する方法に問題があるのだろうか。
-
正しいもの作りのためのシンプルさ
GOTO Amsterdam 2013のhard things made easy（難しいことを簡単に）というトラックにおいて、Russ Miles氏が5つの問いによる正しいもの作りについてライトニングトークした。彼はインパクトマッピングから4つの問い「Why? Who? How? and What?」を引用しつつ、「すべての根拠になっている仮説は何ですか？」という問いを加えた。InfoQでは、シンプルさによる正しいもの作りについて、Russ Miles氏にインタビューした。
-
-
ITプロジェクト失敗でどれだけの費用が発生しているのか？
ITプロジェクトは、世界経済に大きな影響を与えているが、IT関係者にはあんまり認識されていません。いったいどれだけの無駄がITプロジェクトの失敗で発生しているのでしょうか？2009年には6兆ドル以上と想定されていますが、そのような結果に疑問を持っていたMichael Krigsman氏は二人の専門家と共に分析を行い、その無駄の規模が"たった"3兆ドルであることに気づきました。
-
「２月革命」ビジネス価値に基づいたソフトウェアを届けることを目指す
2013年2月、著者、スピーカー、コンサルタント、現場開発者たちが、ビジネス価値に基づいたソフトウェアを届けるためのアプローチにある共通要素を明らかにしようと集まった。彼らは、組織やチームがビジネス価値を最大化するために「正しい製品を作る」のに役立つ、いくつかの原理と実践的ステップを明らかにした。
-
ソフトウェアエンジニアリングのビジネス ー スループット会計と制約の理論
Steve Tendon氏が最近の彼のブログで、「制約の理論とソフトウェアエンジニアリング」と題する投稿で、なぜソフトウェア開発組織においては、コスト会計よりもスループット会計の方を好ましいかを、述べている。彼はまた、ソフトウェアエンジニアリングに適用可能な Throughput Accountingと呼ばれるコスト会計のための単純なモデルも提供している。
-