1: ノチラ ★ 2018/02/10(土) 04:40:26.02 ID:CAP_USER
略 【1】経営陣がアジャイルを理解し、企業文化を醸成すること まず、イノベーション文化を醸成するには、企画・開発が一体化した組織のあり方、現代のソフトウエア文化を支えるアジャイル開発を理解する必要がある。これは、「働き方改革」の文脈で捉えることもできる。エンジニアたちにできる限り自己組織的なチーム運営を任せる。働きやすい環境を与える。ツールやマシンを買い与える。
よく誤解されるが、アジャイル開発は「無規律」ではない。むしろタイムボックスに沿って強く(自律的に)マネジメントされている。定期的な自己改善と計測を行いながら、市場にフィットした製品やサービスを作り出すための、ビジネスとエンジニアリングのコミュニケーション手法である。これを経営は戦略として利用しない手はない。イノベーションは「内的モチベーション」から発生する。世界を変えたい、と思っている人たちに権限と裁量を与えるのが一番だ。
【2】既存の情報システム部門と別に、イノベーション部隊を建設すること これまでの情報システム部門は、どうしてもベンダーをコントロールして計画どおりの成果を予算以内で作る(QCD)に注力してしまっていた。イノベーションの世界では「つくるべきもの」の定義を、ニーズ探索と小さな製品づくりを繰り返して行う(鶏と卵を同時に育てる)のだから、このやり方ではうまく行かない。
これからは、別途インハウスのイノベーション部隊を新しく組織する必要がある。そこに固定枠の予算をとる。新子会社を作ったり、社長直轄の部署を作ることもあろう。とにかく、小さなチーム(10名以内程度)を、必要であれば複数作る。そして、そのチーム単位で投資する。それをまとめて1つの部署にするのもよい。また、既存事業部署との関係を強くもつチームがあってもよい。むしろ、企業の強みを生かすためにはそうすべきだ。既存事業はその企業の強みであるはずで、そこを生かしながらイノベーションの外部関係を模索して行くのがよい。
また、その部隊は「内製」を目指すべきだ。そのためにはソフトウエアエンジニアが社内に必要になる。まず社内から募ろう。きっとよい人材がみつかる。見つからなくても、外部に単純に委託せず、ともに考えてくれるベンダーと準委任契約することを考えよう。イノベーションは、QCDの達成が目的ではない。ベンダーにリスクを負わせてはいけない。コストや営業力、プレゼンのうまさで選ぶのではなく、ともにアジャイル開発ができるよい人材を持つベンダーを選別し、信頼して付き合える関係を築こう。
【3】イノベーション部隊を既存の進捗管理から切り離し、企画と開発を一体化すること そういったイノベーション部隊を、計画達成度の進捗管理のもとに置くべきではない。そもそも計画できないのがイノベーションである。また、新しいアイデアが10出たとして、そのうち成功にまでたどり着くものはせいぜい1つあるかないかだ。これを計画対比で進捗管理してしまったら、確実につぶしてしまうだろう。ファンドを運営するように、小さな投資を複数に行うべきだ。
そのチームは、開発と企画の一体となった組織横断でつくり、品質保証やユーザー体験(UX)づくり、データ分析部隊も含めて一体化させる。そして生き残っていくものにさらに投資する。意思決定を細かく行い、ステージ管理をして少数のイノベーションを育てる必要がある。
新しい製品やサービスが、既存のシステムと連携することはよくある。いわゆるMode-1とMode-2の連携である。その場合でも、種となる人材を既存部隊から移動し、連携を含めて企画していく必要がある。 従来型のチーム http://jbpress.ismcdn.jp/mwimgs/0/e/670mn/img_0ef4a34ee6e186426e051cc219a2e4e527741.jpg DX(アジャイル)型のチーム http://jbpress.ismcdn.jp/mwimgs/6/4/670mn/img_64de4853d2cd0ac4e69e5634e176042f30479.jpg 以下ソース http://jbpress.ismedia.jp/articles/-/52264?page=2
よく誤解されるが、アジャイル開発は「無規律」ではない。むしろタイムボックスに沿って強く(自律的に)マネジメントされている。定期的な自己改善と計測を行いながら、市場にフィットした製品やサービスを作り出すための、ビジネスとエンジニアリングのコミュニケーション手法である。これを経営は戦略として利用しない手はない。イノベーションは「内的モチベーション」から発生する。世界を変えたい、と思っている人たちに権限と裁量を与えるのが一番だ。
【2】既存の情報システム部門と別に、イノベーション部隊を建設すること これまでの情報システム部門は、どうしてもベンダーをコントロールして計画どおりの成果を予算以内で作る(QCD)に注力してしまっていた。イノベーションの世界では「つくるべきもの」の定義を、ニーズ探索と小さな製品づくりを繰り返して行う(鶏と卵を同時に育てる)のだから、このやり方ではうまく行かない。
これからは、別途インハウスのイノベーション部隊を新しく組織する必要がある。そこに固定枠の予算をとる。新子会社を作ったり、社長直轄の部署を作ることもあろう。とにかく、小さなチーム(10名以内程度)を、必要であれば複数作る。そして、そのチーム単位で投資する。それをまとめて1つの部署にするのもよい。また、既存事業部署との関係を強くもつチームがあってもよい。むしろ、企業の強みを生かすためにはそうすべきだ。既存事業はその企業の強みであるはずで、そこを生かしながらイノベーションの外部関係を模索して行くのがよい。
また、その部隊は「内製」を目指すべきだ。そのためにはソフトウエアエンジニアが社内に必要になる。まず社内から募ろう。きっとよい人材がみつかる。見つからなくても、外部に単純に委託せず、ともに考えてくれるベンダーと準委任契約することを考えよう。イノベーションは、QCDの達成が目的ではない。ベンダーにリスクを負わせてはいけない。コストや営業力、プレゼンのうまさで選ぶのではなく、ともにアジャイル開発ができるよい人材を持つベンダーを選別し、信頼して付き合える関係を築こう。
【3】イノベーション部隊を既存の進捗管理から切り離し、企画と開発を一体化すること そういったイノベーション部隊を、計画達成度の進捗管理のもとに置くべきではない。そもそも計画できないのがイノベーションである。また、新しいアイデアが10出たとして、そのうち成功にまでたどり着くものはせいぜい1つあるかないかだ。これを計画対比で進捗管理してしまったら、確実につぶしてしまうだろう。ファンドを運営するように、小さな投資を複数に行うべきだ。
そのチームは、開発と企画の一体となった組織横断でつくり、品質保証やユーザー体験(UX)づくり、データ分析部隊も含めて一体化させる。そして生き残っていくものにさらに投資する。意思決定を細かく行い、ステージ管理をして少数のイノベーションを育てる必要がある。
新しい製品やサービスが、既存のシステムと連携することはよくある。いわゆるMode-1とMode-2の連携である。その場合でも、種となる人材を既存部隊から移動し、連携を含めて企画していく必要がある。 従来型のチーム http://jbpress.ismcdn.jp/mwimgs/0/e/670mn/img_0ef4a34ee6e186426e051cc219a2e4e527741.jpg DX(アジャイル)型のチーム http://jbpress.ismcdn.jp/mwimgs/6/4/670mn/img_64de4853d2cd0ac4e69e5634e176042f30479.jpg 以下ソース http://jbpress.ismedia.jp/articles/-/52264?page=2