InfoQ

InfoQ

News

マイブックマーク

ブックマークするためにログイン または 会員登録 する

ブックマークされました!

ブックマークがエラーになりました。もう一度お願いします。

フォレスターがビジネス向けリーンに関する無料の調査報告を公開

作者 Deborah Hartmann Preuss , 翻訳者 川本 史生 投稿日 2009年10月21日

セクション
プロセス/プラクティス,
エンタープライズ・アーキテクチャ,
設計/アーキテクチャ
トピック
Business Process Management ,
顧客要求 ,
Delivering Value ,
ビジネス ,
Business Process Modeling ,
Agile
タグ
Lean

原文(投稿日:2009/10/01)へのリンク

世界中にオフィスを持ち、アメリカに本拠地を置く独立調査会社の フォレスターリサーチは来週 ビジネス・テクノロジ フォーラム 2009をシカゴで開催する。 テーマは"リーン、新たなるビジネス・テクノロジ規範"である。イベントに先んじて発表された 調査報告 は同じタイトルで、現在無料でダウンロードできる(ただし、無料のウェブ登録が必要)。 フォレスターによると、とても広範な経営手法で次の3つを行うのがリーンの戦略である。無駄をなくし、顧客価値をつくり、会社を柔軟にして顧客の要求にすばやく答えられるようにするものである。 テクノロジ向けというよりはビジネス向けに書かれたこの報告では、フォレスターのアナリスト6人がビジネス全体の規範としてのリーンについて、またITへの影響について議論する。そしてこれは大切な警告で終わる " 価値の創造と柔軟性の増加を忘れて、無駄の排除に没頭してはいけない。これら3つは同一歩調をとって進めなければならない。 "

今年InfoQのアジャイル記事を読んでいる人は、リーンソフトウェア開発と、世界的に広まる カンバン方式に関する記事何度も目にしている。 しかしリーンの動きは新しいものではなく、製造業から生じて近年は他分野にも適用されており、ITの外の世界では20年以上にわたって知られていた。 この報告は業務全体に適用するリーン手法を選ぶ際にビジネス上起こりうる混乱を認めており、長年にわたって使われているリーン、シックスシグマ、TQM全てのアプローチの要点を"CliffsNotes" で提示している。

リーンが焦点を合わせる商品の価値体系全体(すなわち消費者から "生産現場" まで)において、価値の流れに対する視野を絶えず広めていくことが求められており、 これにより局所最適化を避けることができる(局所最適化とは、例えばある部門が局所的に無駄を取り除くが、他の部門の工程に悪影響を与えてしまう)。 いくつかの事例では、IT部門からリーンやアジャイルなソフトウェア開発プロセスが始まり、それに刺激された他のビジネス部門も工程改善を導入する。 リーンは業務全体に関わり、アジャイルなITを補完する。 他の事例では、価値の流れを内部に広げていったビジネス部門がそのリーン手法をIT部門に持ち込む。

リーンの導入ではほとんどの場合、無駄を減らそうという一連の短期的な取り組みが業務レベルから始まります。しかし無駄のみに集中してもリーンの効果は完全には発揮されません。 戦略的レベルでは、リーンは短期的な結果ではなく長期的な価値をもたらすことを中心とした視点を持って会社を経営することです。 これは工程がどこに価値を付加するか評価し、完璧を目指してどこまでも品質を追求し、これらの評価に基づいて報酬を与えるという継続的な学習と改善に集中することです。 リーンは思考を指揮統制するのではなく、チームワークと共同作業に重きを置きます。
-- Connie Moore氏 フォレスター研究部門 VP ディレクター

フォレスターの報告では" ...ITが組織に適合しているか、どう評価し、商品を作り、社員を管理し、技術を用いているかを組織が徹底的に再評価しています。" フォレスターはこれを次の様に再考する

ITがその評価のされ方を変え、新しい技術や手法(クラウド、仮想化、オープンソース、アジャイル、改良されたビルド管理、テストプロセス等)を利用し、ビジネス価値を開発サイクルに取り入れる好機です。 さらに、ITにソフトウェアを うまく早く、そして安く 作るだけではなく、的確に開発する機会を与え、これがリーンを導入する際重要になります。

報告はいつITがリーンの価値体系に組み込まれ、アプリケーションの開発と納入が変わるか述べている。すでにアジャイル手法を使用している者には、リーンがITに与える影響は珍しくはないだろう。

私たちは契約的でビジネスを敵とみなすような関係から、より協力的なものへとなる原理の転換を見ているのです。これはソーシャルメディアや協力戦略よりも、ソフトウェアをより頻繁に納入することによって起こります。 動作するソフトウェアを早い段階で納入すると、ビジネスとIT間のフィードバックループが短くなり、より効果的に協力できるようになるのです。

ビジネスがITにリーンを用いることについて、この報告ではリーン技術の準備戦略を支持するために内部を直視する方法を薦めている。これらは、必要なものを発見するため従業員に関するマーケット調査を行う、要員のシナリオを使ってビジネス支援の確立や問題解決を行う、そして継続的な変更管理に投資を行う。 ここには注意事項もある。このような内部プログラムを実践しているときでも、ビジネスはリーンの焦点が "本物の 顧客、つまりは最終的で外部に存在し代金を支払う顧客である"ことを忘れてはならない。


さらに リーンソフトウェア開発についてのニュース、記事やビデオを見る:  InfoQ.com/jp/lean

特集コンテンツ一覧

GAE開発の落とし穴

Googleのクラウド環境をつかったGoogle App Engineによる開発するにあたり、初めての試みで苦悩する開発者達の経験をもとに、各開発フェーズにあわせて問題点やどう解決したかをご紹介します

イベントレポート:「Coqチュートリアル#1」

去る1月12日、定理証明支援系ツールCoqの初心者向けチュートリアルが開催さ れた(http://kokucheese.com/event/index/23667/)。今後も2月2日 (http://kokucheese.com/event/index/23744/)、2月9日、2月16日と引き続き開 催されていく予定である。本記事では、開催の様子をレポートする。

Javaの未来についてのNeal Gafter氏とのディスカッション

Choosing Options

Neal Gafter氏はOracleによるJava買収の影響に関する議論、Javaにセグメンテッドスタックやメタオブジェクトプロトコルを追加することについての主張、そしてJavaとC#との比較について話をしてくれた。

Google Dartのエッセンス:アプリケーションの構築、スナップショット、Isolate

GoogleはVMをともなう新しい言語であり、JSコンパイラでもあるDartをプレビューした。 InfoQはDartのアプリの構築に貢献する文法の裏側を探った:スナップショット、Isolate、モジュール方式

CSPベースのモデル検査ツール「Process Analysis Toolkit」

本記事ではCSPベースの「マルチドメイン・モデル検査ツール」である、PAT(Process Analysis Toolkit)について紹介する。モデル検査は、形式手法(Formal Method)という方法論を基礎とする技術であり、複雑さが増大しながらも安全性を求められる、現在のソフトウェア開発の状況に対する処方箋の1つとして注目されている手法である。

Jenkinsによる継続的インテグレーションのススメ(4) ~CloudBeesでJenkinsをサービスとして使う~

前回まで、Jenkinsの幾つかの側面に注目して解説をしてきました。シリーズ最後の今回は、Jenkinsをサービスとして使う方法を紹介します。

書籍『抽象によるソフトウェア設計-Alloyではじめる形式手法-』の紹介

Alloyは、MITにて開発された仕様記述言語であり、ツールによる自動解析を使い、インクリメンタルに形式仕様が書けることが特長である。筆者らはAlloy開発者による、Alloyを使った形式手法入門書を翻訳、今夏にオーム社より刊行した。本記事では、Alloyの簡単な概要と、翻訳書『抽象によるソフトウェア設計』(「Alloy本」)を紹介する。

Windows デバイスで開発するタッチユーザーインターフェイス

スマートフォンを中心としたマルチデバイスにおけるタッチユーザーインターフェイスへの対応は、既に必須の項目となりつつある。本記事では、Windows デバイスにおける UX のベースとなっている「メトロ」というデザイン言語を掘り下げながら、既存環境を意識しつつもどのようにタッチユーザーインターフェイス開発に取り組んでいくべきであるかについて解説していく。