システム開発の現場から元気が失われているーー。元凶は大量生産時代の名残ともいえる開発手法に縛られているからだ。どんな組織も因習から脱し、元気を取り戻せる。この道40年の筆者が指南する。

 システム開発の現場が元気になり、自信を取り戻す――。このテーマの下、前々号まで連載した「現場を元気にするチーム運営術」に続き、今号からは装いを新たに新コラムとしてより実践的な変革手法をお伝えします。

 これまでの「現場を元気にするチーム運営術」ではトヨタ自動車の生産方式(TPS)やマネジメントを基にした「TMS(トヨタ・マネジメント・システム)」に基づき、現場が自ら考え、自律的に行動することで、元気を取り戻す事例を紹介してきました。現場を「見える化」する様々なボードも解説してきましたが実は決まった形はありません。

 新連載ではまず、TMSで使うツールや仕組みを解説します。TMSを正しく導入できると自ずと現場が自律的に行動できるようになるからです。

 現場で今も当たり前となっているウォータフォール(WF)型開発やプロジェクト管理手法などの発想を変えていく方法も解説します。さらに「DevOps2.0」を使ったシステム開発の全体最適によって開発スピードを3倍に高め、ビジネスへの貢献度を上げた事例を基に、開発現場の理想像を考察します。

DevOpsの進化版「2.0」

 DevOpsは社会や業務の変化に柔軟に対応するためのシステム開発・運用手法だと知っていても「DevOps 2.0」は初めて聞いたという方も少なくないでしょう。先の連載でも触れましたが改めて説明します。

 2000年に誕生したアジャイル開発は今や欧米の95%の開発現場で利用実績があるとされ、日本でもネットサービス系の開発を中心に広まっています。目まぐるしく変わるビジネス環境の変化に対応するため、システム開発に求められるスピードは格段に増しています。

 ITサービスは作っただけでは意味がありません。運用して何らかの価値やメリットを利用者に提供して初めて意味があります。

 つまり運用段階に入ってからの機能追加などのリリースやITサービスの適切な運用についても、スピードや柔軟性が求められるのです。そうした背景から、開発と運用を一体として考えるDevOpsが生まれました。

 DevOps 2.0はITサービスの企画から開発、運用、そして耐用年数ともいえるEOL(エンド・オブ・ライフ)まで、システムのライフサイクル全体を対象範囲としています。従来のDevOps(DevOps 1.0)より範囲が広いのです。

 ITサービスについてはフロントエンドのSoE(システムズ・オブ・エンゲージメント)だけではなくバックエンドのSoR(システムズ・オブ・レコード)もカバーします。DevOps 1.0はSoEのみを対象にしていました。

 範囲をライフサイクル全体に広げる狙いはビジネスの成長スピードを社会変化よりも速くして、ビジネスに永続性を持たせることにあります。そのため、企画段階では運用目線の評価やROI(投下資本利益率)の評価を組み入れて、開発段階では適切なITサービスマネジメントを実行するのに最低限必要な情報を提供できるようにしています。

 開発と運用の活動状況を鑑みてEOLを決定しやすくもなります。一連のプロセスを実装するために、アジャイル開発やTPSといった様々な技術や考え方を融合しています。

 DevOps 2.0ではITサービスに関する全ての基準を「ビジネス価値」に統一します。ビジネスへの貢献度が下がればITサービスを更新し、貢献できなくなったと判断すればEOLにして廃棄します。

 このEOLの概念は今までの開発方法論にはありませんでした。度重なる機能の追加・修正によってプログラムが読みにくくなったり、メンテナンスが属人化したりすると、開発スピードが落ちるのでビジネスに貢献できなくなってEOLとなる可能性が高まります。ROIを評価するため、不要なITサービスの開発を抑制する効果も期待できます。

図 従来のDevOps(DevOps 1.0)とDevOps 2.0の違い
システムの誕生から寿命までビジネス視点で素早く開発
図 従来のDevOps(DevOps 1.0)とDevOps 2.0の違い
[画像のクリックで拡大表示]

大量生産時代は終わったのに

 日本でアジャイル開発やDevOpsが広まっているとはいえ、多くの開発プロジェクトの現場はいまだにWF型を採用しています。日本の高度経済成長時代に使われ始めてから何十年も変わっていません。

 WF型の管理手法の基礎となるのは米国の技術者でありコンサルタントでもあったフレデリック・テイラー氏が100年以上も前に提唱した「科学的管理法」です。同氏はインダストリアルエンジニアリング(IE)の祖と言われています。

 科学的管理法は大量に同じものを効率よく生産するための手法です。「計画通りに物事は進められる」「局所で最適を求めれば、全体最適につながる」「計画と実行の役割を分離したほうが効率が良い」「実行部隊とは別に独立した品質管理部隊を設ける」といった決まりを守って工場を管理します。

 高度経済成長時代は物を作れば売れる時代でもあったので、科学的管理法が重宝され、ソフト開発にも適用されました。しかし、今はモノ余りの時代。時間とアイデアでビジネスの勝敗が決まる時代です。そろそろ従来のやり方や習慣から、新しい時代に適応する手法に改革すべきではないでしょうか。

 テイラー氏の科学的管理法や思想がもてはやされた高度経済成長時代に、これとは異なる思想で活動する企業がありました。トヨタです。

図 フレデリック・テイラー氏が提唱したIEの定義と課題
工場の生産性を高める手法はソフト開発には適用できない
図 フレデリック・テイラー氏が提唱したIEの定義と課題
[画像のクリックで拡大表示]

アジャイルの源流はトヨタ

 科学的管理法による米国型大量生産に対抗するために編み出したのがTPSです。まとめて大量に作るよりも、注文に応じて一つひとつ作って売るという「一個流し」のほうが効率的であるという考え方がベースです。資金的にもすぐに回収できるので、資金効率(資本回転率)も良いです。

 TPSの代表的な特徴は次の通りです。

  • 顧客に価値を提供することが最優先で、それを阻害するモノはムダ
  • 局所最適よりも全体最適を優先する
  • 仕事をまとめないほうが効率が良く、一個流しを基本とする
  • 計画は常に変更し、計画の中身より計画作りが大切
  • 知恵は現場に存在する「現地現物」であり、従って作業手順や標準は現場で作る
  • 人のやる気(モチベーション)で業績を含む全てが決まる
  • 仕事の完了は顧客に価値を提供したとき
  • 仕事は顧客の価値に結びつく「正味作業」と正味作業の遂行に必要な「付帯作業」に分ける。仕事の時間には正味作業をする「正味時間」と付帯作業をする「付帯時間」、さらに何の価値を生まず、必要の無い時間である「ムダ」がある
  • 異常が誰にでも分かるようにすることが「見える化」であり、見える化は作業者の説明責任である
  • 品質の課題は現場でしか解決できない
  • 全ての作業が正しく行われなければムダが発生する(自工程完結)
  • 異常を検知したら全てのライン(プロセス)を停止する。異常はその場で、全員で対応する

 トヨタの快進撃に興味を持った米国がTPSを研究し出してから、様々な米企業が取り入れ始めました。米国生まれのアジャイル開発は、TPSの影響を強く受け、システム開発手法に適用したものなのです。TPSの特徴を見て、アジャイルに通じると感じた方も多いと思いますが、こういった背景を知れば納得できるでしょう。

盲目的にRFPに従う開発チーム

 筆者は現場を元気にするにはTPSやTMSをルーツとするアジャイル開発や、さらにビジネス価値を主眼に置いたDevOps 2.0がカギを握ると考えています。ただ、前述した通り、日本のシステム開発現場は何十年もWFを常識としています。

 筆者にはもう一つ、開発チームが悪しき常識から抜け出せていないと考えていることがあります。

 それはRFP(提案依頼書)や発注者との関係に関するものです。具体的には「RFPを絶対に順守する」「RFPに記載された計画通りにプロジェクトを遂行する」「各工程で仕様は凍結する」「発注者は神様であり、その意向は絶対である」といった考え方です。

 長年現場を縛り付けてきたWFやRFP、発注者との関係といったいわば古い常識をどう覆せばいいのでしょうか。筆者が数年前にPMO(プロジェクト・マネジメント・オフィス)のマネジャーとして参加した、ある上場企業の基幹系刷新プロジェクトを紹介しましょう。

 この企業は外部のコンサルタントに依頼して、1年間をかけて数十ページのRFPを作り、それを基に複数の開発受託ベンダーから提案と見積もりを募りました。筆者が所属するベンダーは現場開発者を伴って訪問し、次のように説明しました。

 「RFPを100%満たそうとすれば数年と数億円の投資が必要となり、上場企業といっても負担は少なくないはずです。アプリケーションの根幹部分を6カ月と7000万円をかけてアジャイル開発で早く安く完成させ、根幹機能をベースに成長させていくほうがリスクを低減できます。根幹部分は機能数にして120程度に絞れます」。

 発注元の社長は「ほとんどのベンダーは数年と数億円という見積もりを出しています。納得はできないが、それほど掛かるものかと認めざるを得ません。この提案の通りにできれば嬉しいのですが……」と漏らしました。情報システム部長のK氏は「数億円と言いますが、2~3億円だとしても弊社には大きな負担です」とこぼしました。

 筆者たちは「これまでの経験に基づけば、RFPに記載されている内容を100%実装する必要はありません。本質を読めば根幹を絞れます。ここにいる開発者は御社のプロジェクトを受託した際には中核となるメンバーです。御社では初めてとなるモバイル系の開発経験もあります」と説明。彼らが開発したモバイル系アプリケーションをデモンストレーションしました。

 後日、K氏から「正直、提案内容に驚愕(きょうがく)している。失礼な言い方ですが、弊社をバカにしているのかという疑問もわいた」と連絡がありました。「真意を確認したいので、提案根拠を説明いただきたい」と付け加えてきました。

 筆者らはK氏にRFPの何を本質(根幹)と、本質をどう判断したのかなどを説明しました。K氏は「まだ採用ベンダーを決めていませんが、実現性を確認したいので、しばらく質疑応答を続けていただきたい」と相談を持ち掛けてきました。

 実はK氏は「RFPに要求が的確に表現されているものか」と疑念を抱いていました。アジャイル開発のメリットを密かに期待していたのです。K氏との何度かのミーティングで仕様(RFP)を精査した結果、根幹部分が120機能に収まるメドが立ち、筆者らが受注しました。

図 見積もりや提案方法の違い
言われた通りには作らない
図 見積もりや提案方法の違い
[画像のクリックで拡大表示]

自らコミットして成長する

 アジャイル開発はイテレーション(繰り返し作業)ごとに完全に動作するアプリケーションをリリースして、それを繰り返すことで全体を完成させていきます。ここではイテレーション期間を2週間と決めました。

図 実践したイテレーションサイクル
ユーザーの負荷を配慮して開発サイクルを決める
図 実践したイテレーションサイクル
[画像のクリックで拡大表示]

 一方、リリースしたアプリケーションに対するユーザーのフィードバックを、次のイテレーションの半分を過ぎたあたりに実施するという変則的な進め方にしたいと、開発チームのリーダーが提案してきました。ユーザーの負荷を下げるのが目的と言います。

 筆者はこの提案に不安を覚えました。1つのイテレーションに開発とフィードバック対応作業が詰まり、余裕が無いと感じたからです。

 ただ、リーダーは「最初のイテレーションは悪い結果になります。第4イテレーションまで寛容に見て下さい」と自信のある様子で話します。結局、その言葉を信じることにしました。

 開発チームは自身の宣言にコミットするために、ボードなどで作業の透明性を確保していった結果、第4イテレーションには宣言通りに成長しました。計画通りに作業が進むようになり、開発期間を12日間から9日間に減らしたにもかかわらず、開発量を示す消化実績は136時間から2.8倍の381時間に増えたのです。発注元のシステム部門からの信頼も高まり、開発スピードに呼応するかのように利用部門への仕様確認や要望整理も速くなりました。

 イテレーションで作成した機能(サービス)に関する指摘事項の受付期間を2週間と決め、2週間を過ぎても返答が無い場合は「認可した」と判断するルールも決めました。全ての関係者が適度な緊張感を持った真剣勝負でありながら、お互いの責務や立場を尊重してプロジェクトを運営できたといえます。

 開発チームはどれだけの機能追加や変更を加えたかの足跡を見るために管理表を作り、ユーザーとベンダーがお互いの目線で重要度や難易度を明確にしながらプロジェクトをかじ取りしました。最終的には416件の追加要件があり、開発期間は10カ月まで延長し、開発費用は1億円となりました。実装した機能のほとんどはRFPとは全く違ったものになり、開発チームは運用後も維持管理を引き受けています。

 K氏は開発チームに過度なプレッシャーを与えず、不安事はPMOである筆者に相談し、開発チームのスピードを上げることに協力的でした。「三井さん、色々と心配事や要望の話をしていますが、私は開発チームの作業を止めようと思ったことはありませんよ。だって開発チームが作ったアプリケーションが当社の今後のビジネスにとって何よりの財産ですからね」というK氏の言葉が今でも心に残っています。

 この事例から学べるのはRFPに対する提案や開発手法など、開発現場で長い間良いと考えられ、習慣にしてきた行動を根底から覆しても、ユーザーが困るどころか、より信頼を寄せて協力的になってくれるという事実です。

 現場が全員で課題を探して解決に当たり、ユーザーを巻き込みながら成長していく。それこそが現場を元気にするのではないでしょうか。

図 バーンダウンチャートが示す開発チームの成長実績
イテレーションを重ねて生産性が向上
図 バーンダウンチャートが示す開発チームの成長実績
[画像のクリックで拡大表示]
三井 伸行 氏
戦略スタッフ・サービス 取締役
ソフト開発ベンダーやユーザー企業、外資系ソフトベンダーを経て、2007年に戦略スタッフ・サービス入社。基幹系システムのアジャイル開発導入支援や、トヨタ流マネジメントであるTMS(トヨタ・マネジメント・システム)をベースにしたソフトウエア生産技術力の向上、ホワイトカラーの職場改善などのコンサルティングに従事する。社団法人TMS&TPS検定協会の認定TMS講師としてDevOps2.0も使っている。働き方を変える「TMS塾」の講師も務める。