Comments
Description
Transcript
日経トヨタ流43-57 - 株式会社 豊田マネージメント研究所
楽天の作業ボー ド 利用者の価値 に直結する作業 IE重 弩 ｉ ． ″ キ ・ 憮11 設計やコーディングなど 利用者の価値に直結しない作業 写 真 提 供 :楽 天 左から、 藤原氏、 及部氏 楽天の川口氏、 利用者の価値 への意識を高める工夫 国 楽天の開発現場では、チーム全員で作業一つひとつについて、利用者の価値に直結するかどうかを話 し合って分類 し、ボードで見える化 している。これにより、利用者 の価値への意識がチーム全体で高まったという 森永氏 らのチーム は、 まず テス トエ 程 み上げ、全体の39%に 高めることがで にかかって い る時間の 内訳 を調 べ た。 きた。 に利用者の価値を意識づ けている。 具体的には、1週 間に取 り組む必要 す る と意外 に も、テス トを実施す る 時間仕分け による改善活動の成果 がある作業 をメ ンバー全員で洗 い 出 時間 よ り、テス ト環境構築 な どの準備 は、仕事の成果 として表れているこイ し、付箋紙に書 いて作業ボー ドに貼 り 時 間 の 方 が 長 い こ とが 判 明 した (図 ンシデ ン トを解決する件数が、 トヨタ 出す。その際 に、それぞれの必要な作 (VM) 流 を導入す る以前 の3倍 に増 えた の 業が、価値直結作業であるか どうかを が不足 し空 きを待 つ 時間が発生 してい 「価値直結作業 の時間が増えたか だ。 検討す るのだ た。 テス トエ 程 に、利用者 の価値 に直 らこそ、スピーデイーな対応が可能に 結 しな い 作 業 の 時 間が 多 く潜 ん で い なった」と森永氏は笑顔を見せる。 2)。 また、検証用のllx想 マ シン る。 この ことに気付 いたので ある。 そ こで森永氏 らのチーム は、 テス ト 作業ボ… ドで価値へ の意識を高める (図 3)。 例えば複雑化 してしまった コー ドを 修正す る作業 (リ ファクタリング)は 、 将来的な障害発生を防 ぐために必要だ が、利用者の価値には直結するもので はない、といった具合である。作業に 環境構築 ツール を独 自に開発。 一 度設 時間仕分 けの技 を使 い、価値直結作 定すれ ば、指定 した検証用サーバー に 業 とそ うではない作業 を見 える化 して ついてメンバー同士が話 し合うことで、 テス ト環境を自動で構築 できるように も、そ の後 に何 も手 を打 たなければ開 日々の仕事が利用者の価値に直結 して した。検証用VMの 不足 にも対策 を講 発 スピー ドは向上 しない。見 える化 し いるかどうかを意識するようになる。 じた。現場の物理サーバー を整理 して ただ けで満足 せ ず、改善 につ なげるに 作業 ボー ドに付箋紙を貼る際にも工 仮想化を進 め、以前 より多 くのVMを は、チーム全体 で利用者 の価値 につい 夫 を凝 らす。ボー ドを二つ に分割 し、 稼働できるようにした。一連の改善活 て普段 か ら意識す るための仕掛 けを用 上に価値直結作業、下にそうではない 動に よって、テス トの準備時間を5分 意す る必 要があ る。 作業を貼 る。こうす ることで、メンバー の1に 短縮。VMの 不足 による待 ち時 楽天 の現場 は、 この意識 づ けの仕掛 は日々ボー ドでチームの作業を確認す けを運用 して い る。 同社 でプロセス改 るとき、おのず と「価値直結作業なの この よ うな改善活動 の積み重ね に 善活動 を推進す る藤原 大氏 (開 発 アー かどうかを意識することになる」(藤 原 よって、森永氏 らのチームは価値直結 キテクチ ャ部 新 アーキテクチ ャ・ プロ 氏)。 これによ り、隣U用 者 の価値に直 作業 の時間の割合 を確実 に増や して ヽ 、 った。25%未 満 だった以前の状態か セス 課 アジヤイル グループ グルー プ 結 しない作業を効率化 しようJと いっ マ ネージ ャー)ら が現場 の 各 チ ーム に たアイデアがチーム内で生 まれやす く ら、今年2月 までに14ポ イ ン ト以 _L積 加 わ り、作業 ボー ドを使 って メ ンバー なったとい う。 間をほぼゼロにした。 NIKKEI SYSTE■llS 20135 Ｆ彗 自 Ｆ ト ト ト Ｌ 複雑化したコードの修正、データベースのバックアップなど 作業ばらし 作業を細分化 して 遅れに素早く手を打つ 徘 瘍薮 ■ 扮 トヨタ流では、作業を細分化した上■ 所要時間を計測する。 作業 ごとの問題をきめ細かく把握するためだ。 ITの 現場でも作業を細分化すれば、遅れに素早く手を打てるようになる。 ゃ i トヨタ流の改善活動 に取 り組む生産 高める効果もある。好例 といえるのが、 間を0.1時 間 (6分 間)単 位 で記入す る。 現場 では、工 員が作業す る様子をビデ 富士通 アプリケーションズの各開発チー 作業 を細分化 して い る分、一つ ひ とつ オで撮影す る光景がよく見 られる。映 ムの取 り組みだ。開発工程 のさまざま を毎 日記入す るのは面倒 に思 えるか も 像 を確認 しなが ら作 業 を詳 しく分析 な作業を細分化 し、それぞれにかかっ しれないが、「実際は違 う」 と同社で し、改善の余地を探 り出すためだ。 た時間を日々収集・検証 している。同 プロジェクトマ ネジャー を務める高橋 社 の開発チームが策定 した作業管理表 良明氏 (第 一 開発事業部 事業部長代 れる トヨタ流の技が、作業 の細分化。 である「基準時間シー ト」を参照しなが 理)は 指摘す る。 ここでは「作業 ばらし」 と呼ぶ。 ら、その仕組みを見てみよう この改善策を検討する過程で用 い ら 例えば「 バイ ンダーに収め られた資 高橋氏 も当初は メンバーにとって面 プロジェク トマネジャーは、開発 メ 倒なのではないかと考 えていた。 しか 料 の コピー を取 って枚数 を記録する」 ンバー に作業 をアサイ ンす るに当た し「仕事票に数字を書 き込む時間はせ とい う作業について作業 ばらしをす る り、各工程の作業を細分化する。シス いぜ い5分 で、 リー ダー にどんな作業 としよう。一つの作業に含 まれる動作 テム構造設計 をしたのかをわざわざ報告 しなくて済 に注 目し、「 コピー対象 の資料 三 者 レビュ ー の作 業 を例 に取 る と、 (原 本) (内 部設計)に おける第 をバ イ ンダーか ら取 り出す」「 資料 を 「第三者 レビューを受ける」「第三者 レ 「 コピー機 の 持 って コピー機 まで歩 く」 ビューをする」 「第三者 レビューを受け ボタンを押 し、終わるのを待つ」な ど た後 に修正作業をす る」の三つ に分害￨ と細分化で きる。 す るとい う具合 だ。 むことか ら、メンバーに問題な く受け 入れてもらえた」(高 橋氏 )と 話す。 作業の停滞があればその日に気付く プロジェクトマネジャーは日々、集計 このように細分化 した上で、それぞ プロジェク トマネジャー は、 開発す れの動作にかかる時間を計淑1す る。す るシステムの規模見積 もりを基 に し 実績時間が基準時間をオーバー した作 ると、作業全体を見 ているだけでは気 て、工数見積 もりを行 い、細分化 した 業があれば、その作 業を担当す るメン 付かなかった作業 スピー ドを遅 らせ る 作業一つひとつの「 目標時間」を害1り バーに声 をかけ、状況を把握 してす ぐ 「資料 を取 り出 原因が浮かび上がる。 出す。 この 目標時間に、社内で規定さ に手を打つ。 してか らコピー機 まで歩 く時間が1分 れた4段 階のスキルレベ ルや、同 じよ 実績時間 と基準時間をチェックする 10秒 もかかっている。資料の置 き場所 うな作業 を過去に何回実施 しているの のは、単な る進捗管理にす ぎないが、 とコピー機 の距離 を短 くしよ う」 と 「基準時間」 か とい う習熟度を加味 して 作業 ば らしの効果が ここで生 まれる。 いった改善案を出せる。 を設定する。 第三者レビュ…を三つに細分化 この作業ばらしは、開発のスピー ドを 44 (図 1)。 N KKEISYSTEMS 2013 5 される実績時間と基準時間をチェック。 「一 つ の作業 を1週 間単位や数 日単位 開発が始 まると、メ ンバーー人ひと の大 きさに設定 していると、問題に気 りが、「仕事票」 と呼ぶExcelシ ー トの 付 くのが遅れる」 (富 士通アプリケー 作業報告書 に毎 日、実施 した作業の時 ションズの高橋氏 )。 作業 をば らして 醒 囃 鬱 鵞 あるプロジェク トで富士通アプリケーションズの開発チームが作成 した作業管理表 (2)担 当メ ンパーのスキルをlll 妹 して基準時間を設定 プロジェクトマネジャーは、規模見 積もりの結果を基 に、作業ごとの 「目標時間」を割り出す。さらに、担 当メンパーのスキルや作業習熟度を 加味して「基準時間」を設定する ￨(3)遅 れた作業 を把握 : 開発が始まると、プロジェ 1 ク トマネジャーは日々、実 1 績時間が基準時間を超 え ￨ た作業 (消 化率が100%超 ￨ のもの)が ないかチェック : し、あればすぐ手を打つ *実 績 時 間 は01時 間 (6分 間 )単 位 で計 測 し 入力す る 一． ¨ 式 っ ・つ ´︵ ・一 010 050 (])作 業 を細分 化 プ ロジェク トの計画 フェー ズで、プロジェク トマネジ ャーは、作業を細分化 して メンバ ーにアサインする 第二者 レビューだけでも三 つに分ける B定 義書作成 担当者 (内 部 設 計 )PS:プ ロ グ ラ ム構 造 設 計 PG:プ ログ ラ ミング 開発作業を細分化 して基準時間を設定 し管理 業 田 者 け 富士通アプリケーションズの各チームは、作業 を細分化 した上で担当メンバー のスキルや作業習熟度 を加味 し基準時間を設定。作業遅れをいち早 く把握 し、 手 を打てるようになったという 左から、富士通 アプ リケーションズの 高橋氏、八木橋氏、九山氏 ︵ 一 ．４ ン ¨ バ 一 ヽ 一 ヽ く ■ ７ いるからこそ、 作業が停滞していれば、 ングを十分 に積んで いるかJ「 ○○定義 みだ。従来は、設計担当者によって設 その日のうちに気付いて手を打てる。 書作成 に必要十分 な情報 を前工程か ら 計書の項 目や詳細度に大 きなばらつ き 受 け取 れてい るか」 といった原因の仮 があったとい う。 ボ‖レ ネックの作業も特定できる この取 り組 み を複 数 のプ ロジェク ト で行 い、その結果 を検証す る と、 さら に効果 を高め られるc富 士通 アプリケー ションズの 丸 山富子氏 (取 締役 兼 ソ 説が浮 かぶ。 これ らの仮説 を基 に対策 を打 つ ことで、開発 スピー ドを高める。 標準化で時間のばらつきをなくす 同程 度 の システム規模 で あ るの に、 そ こで設計書 の種別 ごとに標準 ルー ルを定めた。例 えばアプリケーション 処理方式設計書 では、ソフ トウエア構 成図、クラス図、画面遷移・制御 の役 割 を担 う実装 クラスー覧 といった記載 ”工 一八 一 フトウェアエ ンジニアリングセンター セ プロジェク トに よって実績 時 間が ば ら 項 目を定め、それぞれのひな型を示 し ンター長 )は「常 に基準時間 をオーバー つ く作業が見つかることもある。 こう て詳細度が分かるようにした。 してい る作業 を見 つ ける ことで、開発 した「ムラJも 開発 スピー ドを停滞 さ さらにプロジェクトの回数を重ねる プロセス全体 を遅 らせ るボ トル ネック せる原 因だ。そ こで富士通 アプリケー ごとに標準 ルールの改良 を繰 り返 し の作業を特定できる」 と話す。例えば ションズの開発チームは、作業のムラ た。これにより、ある開発チームでは、 をな くす活動 にも力を入れてい る。 設計書 の作成時間や プログラマが設計 Э O定 義書作成」 の作業が いつ も基 準時間をオーバー しているのであれば、 メ ンて 三者 レビュー 第二 者 レビュー 三者 レビュー = SS:シ ス テ ム 構 造 設 計 A 113% 435% 1000% 882% 2118% 1225% 1225% 1765% 387% 00% ンバーが○○定義書作成の トレーニ 一例 は、設計書の書式、記載項 目、 記述す る粒度な どを標準化す る取 り組 書を理解す る時間などを大幅に短縮で きたとい う。 NIKKEISYSTEMS 2013 5 蟷 日経 わ YSTEMs 5 ︲ Ｊ ゝＦ A3レポー ト 問題 と対策を 1枚 に凝綱 チームで素早く共有 1速 の FH寺 間仕分I劃 や2速 の 「作業ばらL」 で問題を特定したら、対策を打とう トヨタ流では、対策を考え実行する技として「A3レ ポー 日 を用いる。 手順に沿 つて問題や対策を整理 し、チームで素早く共有できる。 c 特 集 一〓トヨタ流 一 五つの技 ︲ 開発スピー ドを遅らせる問題に、ど 活用 している現場 の一つが、Ci&Tパ 見つ かって い る問題 を解決す る んな対策を講 じるか。 トヨタ流では、 シフイックの河村博文氏 らのチームで A3レ ポ ー トを作 成 した 論理立てて対策を考 えチーム全体で実 ある。アジャイル開発 のプロジェク ト で は、 そ のA3レ ポ ー トを題 材 施する技 として、 「A3レ ポー ト」を用 において、 リーダーの河村氏が中心 と 成 の流れ を見て い こ う。 いる。A3レ ポー トとは、チームが抱 なって、ユーザーテス トでバ グが多 く A3レ ポー トを作成する基本 える問題、原因、対策な どを、その名 の通 りA3用 紙 1枚 に過不足な く整理 し Ci&Tバ シフィックがアジャイル開発のプロジェクトにおいて たものだ。 ユーザーテストでバグが多く出ている問題 を解決するため に作成したA3レ ポ…ト トヨタ自動車グループの現場改善 コ スタ ッ ンサ ル テ ィ ング 会 社 で あ る0」 Tソ リユーションズの中島輝雄氏 (改 善眼 (1)日 標 設 定 プロジェクトの目標や日標実現に必 要な課題を記入する 推進部 エ グゼクティブ・ トレーナー) は、「現場 の 問題、原因、対策 をチー ム全体で素早 く共有で きる」 とA3レ お客様 の目標 ポー トの効果を説明する。 課 題解 決 をアサ イ ン され たA3レ ポー トの作成者は、1枚 の用紙に問題、 原因、対策などを順に記述する過程で :シ ス ￨(鍛 》醗状錮振 1日 標に対する現状を洗い出す 頭が整理 され、10分 間ほ どで簡潔に説 ´ 一 一一・ 一 ヽ一 一 一 明できるようになる。 リーダーや他の ・ メンバー も、その説明 を聞 きなが ら ´ A3用 紙1枚 を参照すれば、問題か ら対 コ 現■ Ｆ 策までを一通 り把握 できる。これによ り、チーム全体で対策を素早 く共有 し 実行できるようにな り、開発 スピー ド 利用者に価値を提供するために必要 な開発プロジェクトの要素を塔に見 立てて図解したもの。左側の箇条書 きと対応する問題箇所を黄色で表し ている が高まる。 7ス テップで問題と対策を整理 このA3レ ポー トをシステム 開発 に 46 NTKKET SYSTEMS 2013.5 田 (図 1) 現場の問題と対策を手順に沿 つてまとめる「A3レ ポー ト」 問題と対策を一 日で把握 しやすく、チームで素早く共有するのに役立つ。現場が抱え てるようになり、開発 スピードの向上につながる。 トヨタ本家のA3レ ポートでは、(7) 対策を仕組み化 して定着させ横展開する方法を記述する欄 を設けている プは、(1)日 標設定、(2)現 状把握、(3) 卜では、ユーザーテス トで見つ かるバ リーの定義 に時間が かかるのは、開発 問題 の特 定、 (4)要 因解析、 (5)対 策 グの件数が 目標値以内に収 まらなかっ 対象のシステムと連動する既存 のEDI の立案、(6)実 行 スケジュールの策定、 注1。 (7)効 果 の確認一一 の七つで ある た。バ グを防 ぐためにレビューやテス (電 子データ交換)シ ステムなどに関す トを強化すれば開発 スピー ドが遅 くな る知識がないことだと分析した。 (1)日 標設定 で ￨ま 、取 1)組 んでいる 業務 の「あるべ き姿_や あ りたい姿 J り、 スケジュールを守れなくなる恐れ 原因を整理 した ら (5)対 策 の立案 で、 問題別 の対策 と実行者 を決める。 があった。 で きるだけ多 くの対策案 を出 した L 続 く (3)問 題 の特定 では、 日標 と 村氏 は、 プ ロジェク トの1又 支状況 のほ 現状 のギャップを分析 し、解決すべ き で、有力な策 に絞 り込む ことが望 まし か、 プロジェク トの 目標 として、 シス 重要な問題を決める。河村氏は、 シス い。河村氏は、既存 のEDIシ ステムの テム を稼働 させ る時薯、 開発生産性 、 テム要求を表す「ス トー リー」の定義 知識を獲得す るためにミーティングを ユーザ ーテス トで許容 され るバ グの件 に時間がかかっていることなどを問題 増やすな ど、ユーザー企業のシステム 数 な どを設定 した とした。これによってプログラミング 部門 との連携 を強めるといった対策を の時間が短 くなり、それがバグの発生 立案。それぞれの担当者を決めた。 (2)現 状把握 は、 目標 に対す る現状 を洗 い 出す ステ ップた iな るべ くデー タや 図を使 って定量 現状を常に意識し要因や対策を出す ・客観的に記述 (4)要 因解析 は、問題 の原因を記述 たプロジェク するステップである。河村氏は、ス トー 'サ す る。河村 氏 らが担 につ ながっていると考えたのだ。 =し これ ら (3)∼ (5)の 項 目は、 (2) で記述 した現状把握 の内容を参照 しな 「現場 の状況 をイメー が ら作成す る。 ジし、重要な問題の漏れに注意すると ともに、別の観点での対策を考えると 日付:04/04′ 2012 艤》 涸絋聰晰贔 甕〔 ツ ギ ヤ プ 璧 霜 懺 燿 日標とのギヤツプ よい」 とOJTソ リューションズの中島 から、重要な 氏は助言する。 i昌 その後は (6)の 実行 スケジュール 要 因解 析 … の設定 で、対策 の実施時期 を決める。 一 す原因を さらに (7)効 果 の確認 で、対策に よ る効果の実績を記入す る。効果が出て 一 木フ ア ン 蔦こ 疑 ilif鍵 』 す る河 ヽ三 ロ ド マ プ::爾 し警葦受賢fil河 村 ッ 準 ● ス トリ ー 1決 める ll嶺 =:g電 :二 : ]よ ゞレ寺 霧 重 「期を決める : 実行 スケジュール ￨ l舞 巽 幸議 鷲 S。 。効果が出て 効果の実績を記入する いない場合は、 効果を確 確認する場や スケジュールを設定する :ず フオローアツプ いない段階では、効果を確認す る場や スケジュールを決めてお く。 以_Lの ようにしてA3レ ポー トを作成 した河本 す氏 は、す ぐにチームメンバー とその内容を共有。定 めたスケジュー ル通 りに対策 を実行 した。その結果、 バグの発生を目標値 まで抑えることに 成功。開発スピー ドが向上 し、納期 を 「ユーザー 順守できたとい う。河村氏は の信頼 を得 られ、その後 も継続的に開 発を任されている」 と胸を張 る。 Ci&Tパ シフィックの河村氏 注 1)基 本的なステップは…七つである トヨタ本 家のA3レ ポートでは、七つのステップに加 え (8)対 策の仕組 み化・定着と横 展開 という八つ目の ステップを実行する。 一 一 NIKKEI SYSTEA/1S 20135 国目則日目目目□ を検討 し、 日標や課題 を書 き出す。河 浮かび上が り、見落としがちな原因に 掘 り下げてい く (前 ページの図2)。 京都電子計算 のチームは、分析対象 気付 きやす くなる。 続 く「 (3)前 提条件を書 き出す」で の問題に対 し「○○項 目の表示用 コン は、分析すべ き原因の範囲を絞 り込む トロール にコンボボックスが使用 され 手掛か りとなる「前提条件」をリス ト ていた」 とい う原因 を書 き出した アップす る。例えば、今回初めて発生 ぜI)。 さらに 「内部設計書にコンボボッ したのか再発か、問題を起こしたシス テムの仕様は何か、関係者 の経験値は (な ■ (な ぜII)。 ■ 1■ て 二 ■ =´ 1■ : 三 ニー 原因を掘 り下げるに当たって大事な ll∫ ] ■三 ŕ'な った ら「 (5) ■ ― _ こ二ゝ、 発防止 ■ - ` ´ 1 :1■ クスを使用す るように記載 されて い どれだけあるか、問題発生時の環境 は 二1: i「 」■ ‐ た」と続けた ｀ か :よ r■ ・ ― _「 1 1 一 ことである。 因)の つ なが りだ。後者の なぜは前者 _ J の原因でなければならない と同時に、 _ 京都電子計算 のチームは、「 フレー ムヮー クで用意 された コンボボックス 注1の 項 ロリス トで は、 マス ター上 の (原 因の原 0- り 電子 i(者 Б ti三 〕 ￨(り _ 11■ 1 1に のは、なぜ なぜ lt得 で きる も ・ ■ ら 二 普段 と違 っていたのか 一一 といった (原 因)と 十 れ ば問題が 111´ ,△ み って い る 、使り ￨￨す 二」tt条 日1を 1記 載 、をまとめた て つ つ 、 う しヽ と に = _ 1を 決める こと 前者は後者の結果 となっていなければ おか しい。そ こで後ろか ら読み返 し、 _ IDチ ームは、 デー タしか表示 できない」な どの前提 つ じつ まが合 うか どうかを確認するc ‐1‐ ■1を 明記 した 条件を書 き出した。 これにより、 コン 図2の なぜIと なぜIIに つい ては、「 内 ボボックスでCSVフ ァイルか ら取 り込 部設計書 にコンボボックスを使用す る んだデータが表示 されないのは自明の ように記載されていた。だか ら、○○ こととな り、 コンボボックスその もの 項 目の 表示用 コン トロール に コンボ の不具合 に関す る原因分析をす る必要 ボックスが使用 されていた」 とな り、 がな くなった。 適切であることが分かる。 つながり意議 しながらなぜを展開 「 (4)な ぜを 前提条件を整理 したら、 順番に出す」に取 りかかる。分析対象 __ なかった り、論理が飛躍 しているよう に感 じた りした場合は分析が誤ってい たことになる。再検討が必要 だ。 なぜを何回か掘 り下げてい くと、な ぜの内容を見ることで再発防止策が浮 十るJ「 今後J ■ f二 てい る. ほかの開発チームにも横展開 ■ン f■ せ ,}析 の手順で ニニ三「 1 千 、1 逆に読 んだ際に文章がつ ながってい の問題を引き起 こした原因を書 き出し、 それぞれの原因の原因は何か、と順に :二 _ ニ ーム メンバー ′ ■ f■ ― f_‐ ・ 11よ つてチ ー rt i lfi tを 考 え られ ｀ 11 _ ■発が減 った」 二 : _〔 二「 ｀1:程 でバグが ― 二 1 ｀ 「f=::L策 といって ヽ f 二 ■ 「」を″、うJ「 念入 1■ 1_二 、った精神論 に終 ´ C調困■目四D問 題を大雑把に捉えてしまう 「なぜ」 の掘り下げが甘くなる 問題が具体的に表現されていないと、 その原因を追究する ― _ 「]題 が再 そ うため、 = ■ ■￨ヽ った ヽ:￨き ￨11し た 再発防 . Cヨ困目目四Dど の時点の話なのかを踏まえずになぜを出してしまう 過去にさかのぼって原因を分析するはずが、 未来に起こることを誤つて原因とみなしてしまう C調困目目□D知 つているつもりで分析を始めてしまう く __ 11 ]■ _、 1い 実効性 を 1.)、 今後 は 開 の考慮漏れをしてしまう システムの仕様変更があつたことを忘れるなど原因追究の重要なポイント 分析 時 に主語 を書 かな い 一 国 50 役割に応 じた対策が出しにくくなる なぜなぜ分析で lTエ ンジエアが陥 りがちな失敗パターン クスを併 せ持つユーザー NIKKEI SYSTEMS 2013 5 ￢ 議 書 麟 響 >レ 〉なぜを繰 り返すと仕事のスト ドも高 まる エンジニアの方 ir=ぜ 分析 現 を用 いると、問題 の再発防止策 を をする様子 を手察 ンで _て 気 が付 く 検 討 するときはもちろん、普段 の業 務や コミュニケーションに も良い効果 1丁 =ぜ のは、文章 を書 くCi奮 手 =人 いことだ.一 つひ とつ 3 が多 な ぜ」 を 出す際に、主妻 i:=ittら 、論理 をもたらす。 的につながって1■ ,tt,ン すること 業務での伝達ミスを防げる が多 いcそ ん =天 な人 こそ、なぜ 童 そ書 くのか苦 手 方 を入れ て取 り組 んて,ま ノ_[ とい うの も =ゼ そ=丁 票 には、 皆 に分 かりやす .具 τ falえ ば、設計書や仕様書の内容 が、 ダイナミクスの 小倉仁志氏 (社 長) 後 工 程の担当者 に理 解 しやすいもの す」 といった具合 に、明確 かつ論理 になる。仕様書の記述内容が大雑把 的に説明できる。 でどうとでも取れる内容になっていた 相手 の話 を聞 くときも「この点 は、 表現 をす ために、後工程の担当者が間違 えてし まだあやふやだな」 と気 が付 きやす ることが求 められる= 書 .モ が ´ ^容 の人に か 他 分 ろうか」 と まう、といった伝達 ミスを防げる。つ くなるはずだ。話の内容 を確認 しな まり、開発 チーム全体の仕事のスピー がら、具体的に誰 もがイメージしやす チェックすること,こ ド向上 につながるわけだ。 いように表現 してもらうことで、その :′ さらに、 なぜ ==な =_だ =る =ゼ = 三百三 そ三 り 下 げてい く過程 て 更董 こ 文章 だけでな く、会話 でも分 か り 話題 に対する理解 を深められる。 のつ やすく伝 えられるようになる。 例 えば、 なが りも確調 する:こ え らを操 返 ,■ ,た T(表 現す ある事象の原因について説明する際、 「原因は二つあります。一つはこれで 分 かりや す く伝 える力 を身 に付 ける す。 もう一つはこれです。後者の理 の食 い違いをなくし、仕事のスピード 由は、 さらに二 つの要素 に分 かれま を高めてほしい。 =後 :シ すことによtて る力を習得てきる [ 誰 もが具 伝 =`ニ ノ外_シ てきる表 4月 には、 分析 て「平き =´ t■ ■1::11 ニ 策 な どの ノウハ を.=■ 三 ム に も横展開す るII重 :==「 t ≒ニー 大雑 把 な表現 に要注 意 この よ うに問題 1≡ i t11_■ ll「 1つ なぜ なぜ分析 だが、 ￨こ 摯 こえ´ 」て ミ とつ まず きやす い ところ し■ 1 ITエ ンジニアが陥 i;■ ち そ :〔 =・ = ■ こ '一 ンを小倉氏 は四つ 挙 ,こ こ 図3 こ:itて し 第一 は、「問題 を大毛モ 、 tlま 、き→::1」 「 まうJ こと。 こオ 二F' 】 イメージす るとは限 らな .貴 三 を′ t・ ことを意味する."￨え 三 ￨ま バ グ」 とい う表現で ￨ま 、 :ゴ 三兵示 「 三 こ′ 11 表示 されないJ「 正 しい■― ゛■一三し 「間違った‐― ■ jこ か表示 されない」 「 い される」 と った 111可 示 :三 具合 t■ して1ま 、 具体的な問題が考えられる こう 原因の追究が甘 くな りやすい。 この よ うに、 なぜの繰 り返 しは、 ことにつながる。 コミュニケーション (談 ) ない」 とい う失敗パ ターンもある。例 第二 に、「 どの時点 の話 なのかを踏 え￨ゴ 「仕様書の内容 の見間違 い」 と書 まえずになぜを出してしまう」 とい う くと、誰が見間違えたのかが分からな 失敗パ ターンがある。将来起 きること い。プログラマが見間違えたのか、関 が問題の原因になることはないので、 係者全員が見間違えたのかでは、意味 原因を掘 り下げてい くと、時計を巻 き 合いが大 きく変 わる。 戻す ように過去にさかのぼって原因を 分析する ことになるもの。 ところが、 こ れが原因だJと い う思 い込みか ら、 前者であれば担当者にしっか りと確 認す る時間を設ければよい可能性があ る。後者の場合、仕様書 の記述内容が 時計を進めた時点の原因を挙げるケー 分か りにくく、誰 も間違 いに気付かな スがあると小倉氏は指摘する。 かった可能性が高い。主語が曖味なま 知 っているつ もりで分析 を始めて ま再発防止策を導 き出しても、 どの役 しまう」3こ れが第三の失敗 パ ターン 割の人が取るべ き対策なのかが分か り だ:シ ステムの仕様変更があったこと に くくなって しまう。 を忘れていて、実はそれが原因追究の これ らの失敗 パ ター ンに注意 しつ 重要なポイン トだったとい うケースで つ、現場の問題になぜなぜ分析を適用 ある:意 外にも、 これはベテランのIT してみよう。問題対応に追われる時間 ニンジニアが陥 りがちだとい う。 が減 り、利用者にとって価値のある作 「分析時に主語 を書か 第四 として、 業 にかけられる時間が増えるはずだ。 NIKKEI SYSTE,vlS 2013 5 Ｔ鸞 憬 際 Ｆ ト ト ー Ｌ =ぜ 分F ,こ ・ マ ネジメン ト セットベ塚 開発 複数の仕様を同時に検討 徐 々に絞 り手戻りを回避 「手戻 」を防いでいる。 トヨタは独自の技を駆使し、開発スピートを低下させる ベー 「セット ス開発」をトヨタの改善手法に詳しいコンサルタントが解説する。 その技、 霰霧 熙 プ :り 奉 ￢ ⑪ で 荻 彎 S::機 ン 午 後半の別掲記事では、セットベース開発 に通しる現場の工夫を紹介する。(本 誌) ング転■ さ夫 ゴール・システム コンサルティ lE道 コイ 1鰺 「残業 を繰 り返 して仕上げたシステ ムが、ユーザーテス トで 『欲 しかった ものとは違 う』 と言われ、大幅 に作 り 直す ことになった」――。 このような手戻 りこそ、システム開 適用す る。 従 来 の 製 品 開 発 で は、 構 想 111 絞 り込み、す ぐ詳細設計 に移 ろう￨― 一 般 的だった。仕様 を決め打 ちす こそ いえる。開発 のスピー ドを高めるには、 ような進め方 を「ポイン トベース■ t_ 手戻 りを防 ぐことが重要だ。 と呼ぶ (図 1上 )。 製造業では、米国を中心 に、製品開 ポイ ン トベース開発 は最 初 にt・ 1■ 発 の手戻 りを防 ぐ手法 として、 トヨタ 仕様 が適切 な らば、開発 スピー ｀ It 自動車の技に注 目が高まっている。例 いcし か し、 見 当が外 れた とき こ 1 えば米Harley‐ Davidsonや ゴルフクラ 大 きな手戻 りが生 じる な どを大 まか に定めた上て、そf_■ り込めるようになったとい う。 現 す る複 数 の イ￨:様 を同■ 二■て ■ :「 し、その過程 で市場 ニー F′ ´IttfI` ド博士が トヨタの製品開発手法を参考 に体系立てた「リーン製品開発」 と呼 ぶ開発手法の構成要素の一つである。 製造業 の一般的な製品開発 プロセス は、製品の要 求事項 を決める「企画 フェーズ」、要求事項 を具現化する仕 、 様案を検討す る「構想設計 フェーズ」 図面を描 きなが ら細部を詰める「詳細 設計 フェーズ」 と進む。 セッ トベース N KKE SYSTEMS 2013 5 最小限の 試験で早く理解を深める 三二て ::こ となるのは、市場や利用 こllく コス トをかけ = ニ ー ■をいかι ‐ li il■ るかだこ 1里 解 に時間がかか 「 ,す _ま 、1嗣 発スピー ドを損なう。 ■■ 1こ 「 '1,I三 ガスな どさまさま■′ ￨三 ■ ぞれの利点 と欠 ■を■ :こ 構想設計 フニー _ =‐ そ ´ ■― t て =二 =´ 'ギ 「 間 をかけて■ ,「 fl■ 二 二 ■il __=二 段 としては、3次 元プリン を使ったラビッ ドプロ トタイ ■:分 的な試作、量産部品の流 ・考えられる。 ■■ 「あれ も、 これ も」 と 1■ ■ ⊃は、 「 三it■ 、必要最小限の試験環境を作 1■ 二ti書 定の要求 に関す る知識を _t の要素を作 り ときに、それ以クト 1■ _=ま ない=す べ て量産部品を流 11´ て ひとまず試験できるようにす 3́た 方法が考え られる。 1二 ■ 二 iを 採用す るc =手 '一 F2潜 は、プロ トタイプや試 三よ￨)も スピー ドとコス トを で三 ´:_= 発 を例 に取 る と、 トヨ ● I二 ヽ:■ ` ― 料 をガソリンと決 めて t一 て 1■ 二三‐1-=:ヽ = かった とい う:当 tて トベース開発では、さま なるべ く安価なプロ トタイピ 手 1■ 二 Iヨ =:´ _― 詳細度 を徐 々に上げて ト プ リウスの 初代 モテ し 三 ■ て、構 想設計 フェース3■ ■て ,1・ 1 ソリンに絞 てセ .t fI「 そ r´ の理解 を深 めて い く ￨(1て 1)込 Itス ピー ドが高まる3 I=‐ これ に対 しセ ッ トベー スil■ ■ ■ 上に、革新的な要素を従来 より多 く盛 ばれるものだ。米国人のアレン・ウォー 三 ■ま■ 丁二 :で プ ロ トタイビング を行 . 想設計 フェーズ に時 間をか 1)1 その技 は「セッ トベース開発」 と呼 し■ し実際 はそ うではない。 二■ :l― ニ ーズで手戻 りが起 こる確 ‐ ・■ ・ 1■ らだ:結 果 として、プロセ =二 使 うことで製品開発期間を半減させた 仕様の確定をできるだけ遅らせる 」il フェーズの早 い段 階で仕様案 を一 つ こ 発のスピー ドを遅 らせる最大の要因と ブメーカーの米Pingは 、 トヨタの技 を 52 開発 は、 この うち構想設計 フェー ス,こ 三≒ =ま -1先 に、完成度が高まって ■ it著 では、試験をす る意味が乏 議 麟 膠 機 ・ ポイントベース開発 (一 般的な従来の製品開発手法) 仕様 a a 仕様確定 篠ｂ 手戻り(仕 様策定のやり直し ) セツトベース開発 (ト ヨタ流の製品開発手法) 詳細設計フェーズ へ あ 新 術 技 1彎 ￨￨ 協乳駐 や 親ご 1蘊 =否 一 １ １ ′ ド 條ｄ 麟ｅ ヽ 仕様 C ´ ´ 饉 仕様確定 構想設計完了 ￨ 十Ｊ 手Ａ ここ がＬ と■ 一 しい と考 えが ちた ■ ■■ ￨■ 三 :t i==￨、 ン イ 流 的な課題 と解決策 とい う知識 を得 た場 の要求に対す る理解を深められていな 検 証 を短期 間 の 'ち こ■ 「二十 二 ヒ 合は、日標設定、現状把握、問題 の特 いケースは危険である。 で、ニーズヘ の三 手 ,ま ■三 二二ま 1 定、要因の分析、解決策の候補 の立案・ こうした場合は、仕様の確定を急 ぐ 評価 といった項 目をA3レ ポー トに立 と手戻 りにつ ながる。複数の仕様案に てて記入 してい く。 ついてプロ トタイビングを行 い、利用 知 識 の再利用で次の 開発 を高速化 'I li:= セ ツ トベース 開発て ,ま =Iミ it't 製 品 に採 用 す るの ￨ま 一 つ「 作 が、採用 しなかった t31::11■ を て も、 プロ トタイビンクを三 レて ざまな知識 を得 られ る す 仕様変更が非常に発生 しやす く、開発 スピー ドが停滞 しがちだ。特に利用者 を同時 に検討 して任:=を ■三 l it■ l i充 ることが多 い。 `ま て、 レ ￨り 仕様 を早期に決め打ちし詳細設計フェーズに進む「ポイントベース開 発Jは 、大きな手戻りを引き起こしやすかった。 これに対 してトヨタ 流のセットベース開発では、構想設計 (概 要設計)で 複数の仕様を用 意 し徐 々に絞り込むことで、大きな手戻りの発生を防ぎ、結果として 開発 スピードの向上を図れる 例えば、ある仕様案についての技術 階では、正確性 iま ■ ■ ざ まな知識 を得 らt= 三二 え 鵬□ 従来の製品開発手法とセット ース開発 つ、 ,こ こ'´ t■ ニ ■、 そ こで、 獲得 した知議 をミ ￨ま 二t. 再 利 用 しや す い 形 式 に す こ そ て 乏 フオーマ ッ トとして、 米E「 ′ う::二 真.ま 「A3レ ポー ト」 (p「 16を 参■ 者 の反応 を確認。A3レ ポー トを作成 なかにしか残 らなかった「暗黙知」を、 しなが ら、ニーズに対す る理解を深め、 A3レ ポー トに表 した「形式知」 とし 仕様 を固めてい く。そんな開発プロセ て開発部門の全員で共有す る。この形 スを志向したい。 式知 を再利用すれば、次の開発 プロ `ま 「 を使 い捨 てにす るの ￨ま もった これによ り、 これまで開発者の頭の をII::十 ジェクトで理解を深 める時間を短縮で き、さらに開発 スピー ドが向上する。 セットベース開発 の発想は、情報 シ ステムの開発にも参考になる。 システ ム開発は一般に、製品開発 よりも、仕 様変更に対する柔軟性 は高 い。ただ、 稲垣 公夫 (い ながき きみお) ゴール システム コンサルティン グ 顧間、グローバ リング 代表取 l17役 社長 ,NECの 生産技 術 開 発部門、製造統 括 部門を経て、 米国現地法人で経営企画担当副 社長を務める。米国駐 在時代か ノ J■ ■■ らトヨタ生産方式をIT究 .Fザ ト ― ヨタウェイJ(日 経 BP社 )な ど、米国でのトヨタ研究 書の翻訳を多数手掛ける。著書に『開発戦略は「意思 決定」を遅らせろ!J(中 経出版)力 ｀ ある NIKKEI SYSTEIゝ lS 2013 5 セツトベ=ス 開発 >>>利 用者ニザ の理解 を深 める現場 の技 前 ページまでの稲垣公夫氏の解説 =三 にもあったように、セットベース開発 口 き三 二_■ プロ トタイプを提示 し、「 はlTの 現 場 に も応用 で きる。 セ ッ ト が ら利用部門の業務上 の狂 _■ ■モ ベース開発のポイン トは、プロ トタイ ビング を行 い なが ら市 場 や顧 客 の ニーズに対 する理解 を深 め、仕様 を 徐 々に固 めてい くこと。 これと同様 町旧旧目目目Ｈヨ に、 システム開発 では現場 の技 を駆 使 して利用部門の要求の理解 を深め ながら、仕様 を固めてい く。 ≒I言 :広 島 ラ 二 ≡言:門 か lた の は、 ]二 `′基本的 な lIIと ‐ ・ なる業 _ 「 うな業務 を 要件定義 フェーズの タイプを作成 し、利用 ■ ー プロトタイプで要求を聞く =三 ==三 ‐ 二丁 =‐ 二要 '二 り入れ成果 を上 げている開発 チーム ム。ベーカリーショッフを手下=: が存在する。ここでは、ドリーム・アー ンデルセングループの∨CC ツとCi&丁 パ シフィックの現場 の取 り Customer)シ ステム を百発 _■ 組みを紹介 しよう。 ジェク トの様子 を見てみ∫: 二 ロジェク トは、 ドリーム・T― 1■ ニ :=「 ではないが、上記のような発想 を取 両社 の現 場 の アプローチは二 つ。 _ に聞 き出す とい うものct=― ■ 1 利用部門 の ビジネス上 の 二― イ喜 「 求 の価値 を定量化するもCti 対 する理解 を深 めなか ら要 三 1= るのは、ドリーム・アーツC各 雪貴 ニー 実際に、セットベース開発 そのもの ‐ 二 一つは、要件定義 フェース■ =｀ =_ て得 た情 ースの序 盤 ヌイプ を作 /ブ は、対 I「 =争 ■と、聞 き _表 示 で きる 二 二[=: = 三て 三ったJと = ´ jl FJ用 部門 ドリーム・アーツの開発チームが作成 したプロトタイプの自 = VOC∼ お客様の声活用 ∼ [驚 ￨ 腱 二_て すべ てプロ : l三 _て いく :〔 三 ―■tつ てすか? タメなの 1`:,て ハ ▼ ロ ニ デ ヽ 夕 」 タ 、 1、 く 僣ら｀ f生 す ト =ジ ェク マ ス ンヤ 日 要件定義の序盤でプロ トタイプを作成 し要求を ヒアリング 「 要件定義フェーズの序盤でブロトタィプを作成 し、それを基に要求そこT ´ 54 NIKKEI SYSTEMS 2013 5 : 鬱 鬱 機 灯 各要求 とビジネス上の目的の関連性 の キ ーバ ーソンが 新 しい∨OCシ ステ 手戻りは起きず、期限までにシステム ム を具体 的 にイメージ しやす くなった を構築できた」(有 坂氏)。 を、利用部門の考えを聞きながら点 利用部門が重視する価値を定量化 数化する。 「目的の重要性の点数」 ×「各要求 出す ことがで きたこ 例 えは、問 しヽ 合 た七 を受 けたバ ン 一方、Ci&丁 パシフィックの開発チー ムは、利用部門のニーズを定量化 し と目的の関連性の点数」を計算 して、 システム要求ごとに合計。これを、要 の種 類 に よって業 務 フ て理解 しやすくする工夫を凝 らす。 求の 「価値」とする。 この価値 の数 値 が大きいほど、優先順位 が高 いと 考える。この結果、「検索機能デザイ とい う。 その ため有 坂 氏 ら1ま 、業 務 要件 や システム要年 をスムーズに聞 き =一 が 変 わる 定量化の手順 はこうだ。まず、開 こ とが分 か った=こ ■ .こ よ 、商 品 :プ の種 類 に基 づ .ヽ て =董 を切 り替 えな ,す ■ ,ま 発するシステムのビジネス上の目的 を、利用吉6門 のキーパーソンに列挙 し てもらう (図 B)。 例えば「コスト削減」 上 の管理 項 目 ヽことが =ら =し 明 らかにな った .=, ど3管 理 項 目 をどこに配 置 す る こ′ 更 .2丁 し｀か と 「ユーザー増に対応する拡張性」 「ワー クフロー簡素化」といった具合である。 い った確 認 も進 ん t[ こ うしたや ,´ 取 た利用 部 門の ■― 原則 としてブ 次にそれぞれの重要性 を、利用部 門と話 し合 い点数化する。その際、 「フィボナッチ数注1を 使 い、各項目の 点差 をなるべ く大きくするのがコツ」 を三 して挙 が っ ,´ シン 3要 求 ￨ま 、 :― 夕/ブ 3三 反映 =く =,こ する。 そうして ノメ_シ ■含 ってしヽ る ■ 二― か どうか を確 三 の _≡ ==号 =´ ズ に対 す る理 手 を疾 覧 ら 仕様 =■ を確 定 してい くた ,一 モ ￨― が最も重要な要 求であると分かった。 一般に「使 いやすさにこだわりた い」 という強い要求 があっても、開 発チーム としては額面通 りには受け 取りにくいものだ。 しかし、このプロ ジェクトでは検索機能デザインの使い (Ci&丁 パ シフィックの河村博文氏)と やすさという要求 に応えることを優 先 した。開発チームが利用部門の二― い う。点差 が大 きい方 が、 どの 目的 ズに対する理解を深めた好例である。 シン 3疑 得 惑 を得 やすかった こ 三■二 , (の 使いやすさ)」 が重要なのかが分 かりやすいからだ。 [ 利用 部 門 の ■ ― ン 続 いて、利用部門 とともに、システ 注 1)フ ィボナッチ数 隣り合う二つの数の和が次の数となる数例。「 2、 3、 5、 8、 13、 21、 34 」 と続く 。 1 天 きな ム要求 の一覧 を洗い出す。その上で、 1、 Cは Tパ シフィックの開発チームがまとめた、書要求の点数表 Ey*zroHB システム rzr.il* 3目的 と の 薗 塾 撻 =藍 1 ユー ザ ー プロフ /― ル 管理 コンテンツ管理 13 ユーザー登録管理 2 製品管理 クライアン ト機器管理 通知管理 5 国 5 5 3 レイアウ トデザイン ￨を 点数で表 してもらう 5 2 3 13 製品 Q&A管 理 検索機能デザイン 328 3 3 3 動画アップロート管理 塵 5 3 3 3 5 3 5 ・3 3 8 8 8 1 1 257 5 8 5 3 233 プロジェクト マネジャー “ｍ 一 権限管理 報告デ ー タ収集 1 3 慇 羅 誦 F鯉 鯰 雛 謬 :' 要求の価値を定量化 し理解を深める 利用部門の担当者から要求をヒアリングした上で、■―バーソンとともに各要求の価値を定量化する。この過程で要求への理解が深まる NIKKEI SYSTEA/1S 20135 55 やらされ感なく前向きに 現場導入時の五箇条 鱚 １︲１ ﹁ ﹁ ヨ 可■ 翻 １ トヨタ流の技をいきなり導入すると、 メレ ー 感を覚えかねない。 ・ ‐ `4=`■ どうしたらメンバーは前向きに受 !子 ′、 「 実践する現場や有識者から聞いた、 ヽ =F五 ■■重 `て る五箇条を解説する。 ●/ ここまで、開発ス ピー ドを高める ト ヨタ流 の技を五つ紹介 してきた。それ らを現場 に導入す る際に注意 したい点 まずは現場の意見を出しやすくする 一つ 日は、「 メン ‐-1 しないこ とだ。既存 の業務 の進め方に tは 、 メンバーカ t こオ 慣れたチームメンバーは、や らされ感 高 め るアイデアを二:し '・ を持ちやすい。そのためメンバーが前 の準備 だし _二 ー こい っっ ま、プロジェク トマ ネ : そ■ 、朝会などで「本 1ま 二とが あるん じゃない _ _ =:I号 = ITの 現場 向 けの■ めようJと 思えるように浸透させる工 グを手が ける、永 ■ 1 ン トの天野 勝氏 二 r)一 ンター セ ンター長 二 ― __1 ― ― ■ 三十 るとい うもの。こ _「 二 で水を向け、少 し ´て (れ たら「よ く言 っ _ _ 1、 itた ものを吐 き出 しや ― __1 ている現場や有識者にその工夫を聞い こなすの に精 いぅ .ま r たところ、五箇条のポイン トが挙がっ ため込 んでい る 「 た と指摘す る「 そ /t■ 1lr― =:,■ バーか ら前向きな ー '― に次のようなガス抜 f _― 向きに「 トヨタ流で開発 スピー ドを高 (図 1)。 _ tヽ 〔-1_´ い るガス を抜 く場 を そ こで、 トヨタ流の技 を既に実践 し ri tン ―i「 がある。それは、い きなり現場 に導入 夫が欠かせない。急がば回れである。 _ _ ´れす くす る 工夫 として _ 二 」 71桜 木光俊氏 ー Fン _■ (部 ::主 イ (ITソ システムサービ ,ス テム部 第一システ ● :I it らのチームの取 り組み も トヨタ流を浸透させる五箇条 (1)メ ンバーが日頃ためているガスを抜く場を設ける (2)あ りたい姿をチーム全員で考える (3)グ ラフや付箋紙を駆使し、 成果を早めに実感できるようにする デ ニ■ 1 このチームでは、朝会な :一 ニ ングで役職にかかわらず ■ を ン 'ん 」 付けで呼 び合うルー ニ´て ら 形 式張 った雰囲気が 千 _率 直に意見や不満を出し 二 一f 1´ (4)社 内ルールに縛られないプロジェクトにして始める (5)個 々の改善策はいつやめてもいいことにする 田 56 トヨタ流の技を実践する現場や有識者から挙がつた工夫をまとつ■ NIKKE SYSTEMS 2013 5 ■ 1_桜 木氏)と い う。 ]Iま ち りたい姿をチーム全員 で 尋il_t:こ れは、 トヨタ流 の コ ´― ´ニ ンク会社 である豊田マネー : 、し ｀Fモ =子 の高木 徹氏が推奨す トヨタ流を導入する 議 鬱 獲 蠣 Xム ダ取りを前面に掲げてトヨタ流を提案する % 現場はムダだらけなんだ よ ! トヨタ流を導入して 取り除かなければダメだ 一生懸命やつているの ムダなんてないよ に、 プロジェクト マネジャー ○ 開発チーム メンバー ′ 嚇シ誓 難静 あ りた い 姿 を考 えて か ら提 案 す Z ￨ 田 国 NECソ フトERPソ リューション事業部 Elサ ービスグループ では、ありたい姿を週次で考え、 改善活動を行つている ムダ取 りを前面に掲げるより、ありたい姿を考えてか ら提案する タ取りを前面 に掲げることが多いべ ITの 現場では反発を招きやすい。それよりも、チームのありたい姿を考えてからトヨタ 製造業の現場でトヨタ江 Zttj、 =る こ ==ム 流の導入を提案すると浸三 レイず 十 ちこ 二 :]っ ンバーに受け たらll= ヒ '、 ムダ取 りを前 こ■ .=■ 、 =、 二 一全員て のあ りたい姿を メン 、 上で、その姿を日モ十tt、 ニト の導入 を提案すると、す「 ,こ ム た 流 止 り除かなけれ￨ま ,メ モ_ヒ メ い。 しか しITの 現■ て ,ま 、 多 取 ==二 笏 ＬＩＦ一一教考翡 際は、ムダ取 1)を =き めてもらいやすい_■ ￨こ 氏 ERPソ :｀ ニ ク トは特例扱 い し、 コンプライアンス 入 した当初は一生懸命 に取 り組んだ と (法 令順守 )に 違反 しない範囲であれ しても、その成果をなかなか実感でき ば、社内ルールに縛 られないようにす ないと、チーム全体 のやる気が低下 し、 る。既存の社内ルールに反 していても 形骸化 しやすい。 開発 スピー ドが向上する対策が見つか 「利用者 の価値 に直結 しない会議 の 時間 を○時間減 らした」 といった成果 活動 の停滞を防げる。 四つ 目は「社内ルールに縛 られない 五つ 目は「個 々の改善策 はいつやめ て もいいことにす るJ。 トヨタ流 の導 。 ソフ ト プロジェク トに して始める」 入がある程度進 んできた時点で役立つ 工夫である。 るメタボリックスの山田正樹氏 (代 表 実践 しているのは、富士通の森永景 取締役 )は 「既存 の社内ルールがプロ 「改 善策 はまず試 してみて、 介氏 だ。 セス改善活動 の妨 げにな ることがあ 思 うように成果が出なかったときはも る」と指摘す るc う一度工夫を凝 らして試す。それでも 一 一 一一 一 よって利用者にどんな新 しい任 効果がなければやめても構わない 開発の コンサルティングなどを手がけ 一一 チ ームの あ りた い 姿や、 シス ばよい。 る」とい うテーマの会議を百 ( れば、社内ルールの見直 しを検討すれ ヽ´・ 一 しヽ`未 ■ を 一殴﹂陸 た プマネージャー )ら の■―二、 として週 に1回 、 つ 目のポイントだ。 トヨタ流の技 を導 に明示 しよう。成果が見えることで、 ン事業部 EIサ ービスクルーア 楽 そ こで トヨタ流を導入するプロジェ が出た ら、積極的にグラフなどで職場 [ ・ろう1ま 、: これを実践 して ヽ フ トの安田守広氏 めに実感できるようにする。 これが三 供 で きるか とい うプラスア ルファーの 発想 を出す会議 だc前 向 きな発想 を出 例えば、価値直結時間を増やすため うまく行 かない ときはやめる」 (森 永 してい る と、改 善活動 に も自発的 に臨 に社内向けの ドキュメン トを簡素化 し 氏 )。 チームに合わない策に こだわる めるよ うになる。 ようとしたが、社内ルールに反するた より、新 しい策を次 々と試 して検証 し め断念す る、といった事態だ。このよ た方が成果が出やすい。 成果を早く実感すると継続できる グラフや付箋紙 を駆使 し、成果 を早 うに規定に縛 られると、開発 スピー ド を高めるアイデアが出に くくなる。 以上の五箇条を押 さえて、 トヨタ流 をスムーズに浸透 させてほしい。 田 NIKKE SYSTEMS 2013 5 57