ソフト開発の現場カイゼンとチーム力向上は可能か，「スクラム」にみる現場の課題
組み込みあるいは企業情報システムのソフトウエア開発では，仕様変更や開発遅延，バグに悩まされることが多く，現場のエンジニアやチームが疲弊していることがよくある。そんな状況を打開しようとする動きの一つとして，「スクラム（Scrum）」という取り組みがある。スクラムに基づく活動は，日本で発展した生産現場の“カイゼン”に似ている*1。
*1 スクラムの名付け親は，一橋大学名誉教授で経営学者の野中郁次郎氏と一橋大学教授の竹内弘高氏で，当初は生産的な製品開発を説明するときに使われた（ken Schwaber，Mike Beedle，『アジャイルソフトウエア開発スクラム』，ピアソン・エデュケーション，2003年参照）。スクラムはその後，欧米を中心に体系化された（スクラムの解説1，スクラムの解説2）。
2009年12月2〜3日に東京でスクラムの実践手法を習得しようとするエンジニア向けの演習付きセミナー「認定スクラムマスター研修」が開かれた（関連記事 日本でも徐々に広がるソフトウエア開発のカイゼン活動「スクラム」）。講師や参加したエンジニアに，ソフトウエア開発現場の課題を聞いた。
仕事を可視化し2〜4週おきにカイゼン
スクラムでは，仕事の内容や担当，進捗を徹底的に可視化する。プロジェクトは，2〜4週間の小さな単位（スプリント）に分割し，人数も5〜9人と少なくする。開発するソフトウエア案件（プロダクト・バックログ）は，チームの全員が見えるようにしておく。毎朝，メンバー全員が集まり朝会（あさかい）を15分程度開く。すべてのメンバーが，昨日やったこと，今日やること，問題点などを通常は立ちながら話す。
2〜4週間のスプリントが終わったらスプリントをふりかえり，発生した問題点のなかからいくつか重要なものを決めて，次回のスプリントでカイゼンを行う。こうした取り組みをチームが主体となって進める。プロジェクト・マネジャーの指示を受ける形ではなく，チームが自己管理する。
プロジェクトの問題を見つけ調整を行う「スクラムマスター」という職種を設けるが，縁の下の力持ちであり，「チームを管理するのではなく運営することが役目」（永和システムマネジメント サービスプロバイディングスプレイ事業部主任でスクラムマスターの西村直人氏）になる。
前述の「認定スクラムマスター研修」でも，スクラムマスターの役割を演習で何度も解説した。「これまでは問題が発生すると，つい自分で作業をしたり，あれこれ指示したりしてしまうことが多かった。チームを安定化させ，能力を高めていくためには，チームの支援に徹する必要があるということを，研修を通して学んだ」（情報システム総研シニアコンサルタントの原田騎郎氏）。
なお，ソフトウエア開発プロセスや開発手法は別途，プロジェクトやチームごとに採用する。つまり，スクラムはプロセスや開発手法に依存しない。
人事評価など組織としての枠組みが必要
スクラムの課題としてよく挙がるのが，組織のバックアップ，人事評価やエンジニアの目標設定，大規模開発への適用可能性などである。
そもそもカイゼン活動に関心がない，あるいはチームの主体性を引き出すことに慣れていない組織では，スクラムの実施は困難が伴う。「人事評価やエンジニア/組織の目標設定の改革が必要になる」（スクラム研修の講師を務めるOdd-e社Agile CoachのBas Vodde氏）。
会社全体でカイゼンを推進していることで有名なのが，トヨタ自動車である。同社は，現場の作業を可視化し，現場の問題の把握や改善，部下の育成などを，上長の役割として明言しており，それらを常に人事評価の対象にしている。問題発生の際は，上長がラインに入って実際に作業し，やりにくい作業を実地に確認する（堀切俊雄，『トヨタ流の教科書・企業編』，日経ＢＰ社，2009年）。
ただし，カイゼン活動が活発なトヨタ資本のある系列自動車メーカーでも，「エンジニアの貢献を評価するのは容易ではない」という。エンジニアごとに技術力向上やカイゼン活動も含めた具体的な目標設定を行い，達成度を評価しその結果に応じて資格などを上げていく，という組織的な枠組みが必要という。ただし，そのような目標設定と評価には，高い能力とかなりの工数が必要である。制度だけ導入して形骸化による弊害が目立つ企業は多い。だからこそ，トヨタ生産方式やスクラムといった形で体系化・明文化し，うまく運営できているかを常に注意しておくことが欠かせないと言える。
大規模開発と整合性がある
スクラムは大規模開発で使えるのか，という質問はよく出される。これに対しては，スクラム間の調整を行う「スクラム・オブ・スクラムス（Scrum of Scrums）」という取り組みなどがある。
一方で，システムの土台となる基盤やアーキテクチャ整備の重要性を指摘する声もある。設計段階でシステムを疎結合のモジュールに分割できれば，各モジュールを担当するチームは自立的にプロジェクトを進めることができる。例えば，ある大手通信事業者の基幹系システム開発では，システム基盤やアーキテクチャをしっかりと作ることによって，サブシステム分割（モジュール化）を進め，ソースコードの品質や可視性を高めてチームの人数を少なくし，ドキュメント量も最小限に抑えたことがある。これはスクラムの目指している姿とほぼ同じだ。つまり，しっかりしたアーキテクチャがあれば，大規模開発でもスクラムを適用しやすくなると考えられる。
