実験的アプローチを可能とするチーム作り
三菱電機株式会社
細谷 泰夫

改善 ＝ 変化
改善するときにやること。
• 「やることを増やす」• 「今やっていることを変える」• 「今やっていることをやめる」

これらは、現状に対する「変化」であると言える。

変化への恐れ• ほとんどの場合、「現状」には問題はあるが、“なんとかなっている”• 「変化」は、現状なんとかなっているバランスを崩す可能性がある。

それ故に、「変化への恐れ」が生まれる。
特に、組織にとって、新しい手法を適用する場合にこの「恐れ」が大きくなる。
改善のためには、この「恐れ」を乗り越えなければならない。

「恐れ」への典型的な対処• 組織的な合意のプロセスを踏むことで「恐れ」を克服する。
• 事前に入念な調査を行い、費用対効果を組織で合意し、パイロットプロジェクトを選定して手法を評価する。

典型的なプロセスの問題点• 適用までの投資が大きい。
情報収集の開始から実プロジェクトへの適用までにかかる時間とコストが大きい。

• 撤退しにくい。
適用までの投資が大きいので、（特に提案者は）撤退の選択をしずらくなる。

新手法適用のジレンマ• 自分たちのコンテキストに合わせた形で手法を適用しなければ効果はできにくい• 自分たちのコンテキストでの実践をしなければ、手法を自分たちのコンテキストに合わせてどのように適用すればいいかはわからない。

最初のパイロットで、未経験の手法を実践しながら自分たちのコンテキストに合うように適用して、良い結果を出さなければならない。

実験的アプローチは、新手法適用時のジレンマを解決する手段

実験的アプローチの三原則
実験的アプローチによる現場改善において重視する３原則

原則1： 「改善のスコープをきわめて小さくする」
原則2： 「実践の結果を素早く得る」
原則3： 「結果を評価して、軌道修正する」

原則１ 改善のスコープをきわめて小さくする• 改善のスコープが大きいと、改善にともなう変化量、手段の複雑度が大きくなる。
• 変化量、複雑度が大きいと、結果を得るまでのコスト、時間が大きくなる。

改善のスコープを極力小さくすることで、改善による変化量、手段の複雑度を小さくする。

原則2 実践の結果を素早く得る• 原則1 「改善のスコープをきわめて小さくする」を適用することにより実践の結果を素早く得ることができる。

結果を素早く得ることにより、素早く軌道修正することができる。

原則3 結果を評価して軌道修正する• 原則2「実践の結果を素早く得る」より早期に得られた結果を評価する。
• うまくいっていれば継続、改善点があれば変更、効果がわりにあわないと判断すれば取りやめを判断する。
素早くやめることもできるため、新手法適用のリスクを低減できる。
取りやめた場合でも、置かれているコンテキストとその課題と手法の関係性を実践結果から学習することができる。

実験的アプローチの6つの活動• 情報収集・調査• 課題の発見• 課題と手段のマッチング• 手段の試行• 手段の実践• 結果の評価情報収集・調査• “良さそうな手法”を発見する活動• ターゲットを絞らない「収集」とターゲットを絞った「調査」がある。
• 「収集」では、自分に役に立つかどうかは気にしない• 「収集」の情報源は、カンファレンス、書籍、Twitter。
Facebookなど。
誰からどんなキーワードが出ているかをチェック。
（AさんとBさんが“XXXX”がすごい！と言っているなど。）• 「収集」は定常的に行う。
• 「調査」は、課題と手段のマッチングによって特定の対象が絞られている場合に実施する。

課題の発見
• 反復的な活動を利用する。
• アジャイル開発のイテレーションとの親和性は高い。アジャイル開発でなくても作業に繰り返しの要素を入れると効果的。
• 繰り返しの中で未来の反復でも繰り返し現れるような課題を発見する。具体的かつスコープが小さい課題。

課題と手段のマッチング• 発見した課題と手段をマッチングさせる。
• 情報収集により発見した手法が手段になる場合と発見した課題のスコープに合った手段をここで抽出する場合がある。
• 課題に合う手段は一つではないし、手段が有効な課題も一つではない。

課題
NN

手段

課題に合う手段は一つではないし、手段が有効な課題も一つではない。

情報収集、調査

手段

手段

手段

より良い手段

当面の手段

課題

開発
計画

実行

ふり 計
かえり 画

実行

ふりかえり

手段の試行• 課題とマッチングした手段が対象。
• マッチングにより、適用のスコープがより絞られていることが重要。
• 課題を解決する手段を一つではないので、手段を試行するのと並行して別の手段を実践する場合もある。
• 試行のゴールは実践を開始できる状態になること。
試行しなくても実践を開始できるものはこの活動を省略する。

手段の実践
• 実際の業務の中で課題にスコープを絞った手段を実践する。
• 実践による結果が極力素早く得られるようにすることが重要。

結果の評価• 実践により得られた結果を評価する。
• 反復のふりかえりの際にその効果や改善点について話し合うのが効果的。
• 当初は考えていなかった問題や、意識していなかった副次的な効果を発見。（実践してこそ得られる）• 結果を評価して、手段を継続するのか、軌道修正するのか、やめるのかを判断する。
• ここでの気づきからより手段を発展させるアイデアが出る場合もある。

コミュニティ、
シンポジウムSNS

書籍など

情報収集・調査

課題と手段のマッチング結果の評価

手段の試行
課題の発見

手段の実践

手段の実践

手段の実践

手段の実践

課題と手段の関係
実験的アプローチ

課題設定を先にする方法

手段の収集

課題の設定
課題を設定

課題に合ったスコープにしぼる

課題に合った
手段を調査
手段の調査

手段の実行
手段の実行

事例1 原因結果グラフを単体テストに活用
活動

実施内容

情報収集

JaSSTでCEGTestを知る。ブログ等で内容の確認。

課題の発見

方式設計～単体テストを繰り返すプロセスの中で、単体テストケースを入出力値のパラメータ表で設計していたがテストケースの意図が判りにくいという課題が出た。

課題と手段のマッチング テストケースの意図を表現する手段として原因結果グラフがマッチング。
手段の試行

CEGTestを利用する上での準備はほとんど必要なかったので試行は省略

手段の実践

CEGTestを使って単体テスト設計を実施。原因結果グラフをレビュー。CEGTestのデータはエクスポートしてソースとは別管理。

結果の評価

テストコードとCEGTestのデータが別管理なので煩雑。
元のパラメータ表よりCEGTestの方が意図が読み取りやすい。

事例1の変遷
単体テストツールテストコードのパラメータをCEGTestのデシジョンテーブルデータから自動生成できないか？

自動生成ツールを作成して実施した。自動生成はできたが、原因結果グラフの可読性が悪化した。

テストコードのヘッダにDoxygenやSandCastleのようなドキュメント生成ツールの形式のコメントとしてCEGTestのデータを貼り付ける。

原因結果グラフはテスト設計、テストコードはテスト実装なので同じレベルまで詳細化しない方が良いのでは？

反復の中で試行を繰り返す。

事例1の変遷後の利点• デシジョンテーブルとCEGTestのデータがテストコードと同じ箇所に一体となっているため、テストコードで実装しているテストの意図が読み取りやすい。
• ドキュメント生成ツールで単体テスト仕様を出力することができる。
• テスト駆動開発と原因結果グラフによるテスト設計を併用することで、コードの内部品質が向上した。
• ペアプログラミング時にペアで原因結果グラフを作成することによって、ナビゲートの地図を得ることができ、ペアプログラミングがスムーズに実施できるようになった。

事例2 DSLを用いたコード生成
活動

実施内容

情報収集

テキスト型DSLのXtextについてはSNS、ブログ等で認知。

課題の発見

アジャイル開発で2週間の反復をしている状況で通信プロトコルの解析処理の実装が電文解析を見ながらの単純作業になっている。

課題と手段のマッチング 電文仕様を形式化してコード生成する手段とマッチング。
XtextのようなDSLの適用対象であると認識。
手段の試行

Xtextをインストール。チュートリアルの試行。

手段の実践

まずは独自のコードジェネレータを作成してコード生成を実施。

結果の評価

電文仕様の量が多かったので、コード生成によるミスの低減、作業効率化を実現できた。
独自のコードジェネレータ、電文仕様の形式は対象のプロトコル仕様専用。

事例2の変遷
電文仕様からの単純作業

独自の電文仕様形式
独自のコードジェネ
レータ

コード生成によるミスの低減、作業効率向上を確認

1つのプロジェクトで効果を確認

電文仕様のDSLとコードジェネレータをXtext
で開発

より良い手段としての
Xtextの試行

複数のプロジェクトで効果を確認

事例2の変遷2012.11

2012.122012.12電文仕様からの単純作業

独自の電文仕様形式
独自のコードジェネ
レータ

コード生成によるミスの低減、作業効率向上を確認

2013.1

2013.1

1つのプロジェクトで効果を確認

電文仕様のDSLとコードジェネレータをXtext
で開発

2013.2～5
複数のプロジェクトで効果を確認

2012.12
より良い手段としての
Xtextの試行

事例2の変遷後の利点• 対象のプロジェクトメンバー全員がDSLの定義、コード生成の基本的なスキルを習得。
• 仕様から単純に設計、実装が可能なのをDSL化できないかと考えるようになった。
• 想定できる不具合の原因（DSLの定義間違いなど）を特定しやすくなったので、レビューやテストの観点が明確になった。
• 複数の概念や責務を一つのクラスに押し込めるような設計が減少した。（DSL→コード生成の観点からはむしろ面倒になったから）事例3 実験的にやめてみる• チームがユニットテストに時間が掛かりすぎるという課題を持っていた。
• ユニットテストでのカバレッジの目標、「単体」へのこだわりなど。
一週間、ユニットテストを実験的にやめてみた。

現在のやり方が充実していて複雑だとどこまで降りるのが良いかがわかりにくい場合がある

一旦、やめてみて、そこから考えた方が簡単な場合がある

やめて何が起こるか観察する• やめたことで、品質がどうなったか？
• やめたことで、どれだけ負債が溜まったか？
• 負債を返すために最低限何をすればいいか？
• ユニットテストを「やめ続けたら」何が起こりそうか？
• どこまでやると自分達にとって適切なのか？

2010年～2012年でチームで取り組んだ新手法(1)プロセス
スクラム、XDDP(2)手法
アジャイルの技術的なプラクティス（TDD、ペアプロ、CI）
原因結果グラフテスト設計の段階的詳細化
アジャイルインスペクション
外部DSL(3)ツール
TFS、Test Manager
SphinxXtext

チームへのアプローチ• 新しいことをへのチャレンジにネガティブなチームで実験的アプローチを実践することは困難。
• 実験的アプローチの実践を意識したチームビ
ルディングが必要。

コミットメントフリーなチーム• チームにコミットメントを求めると、新しいことにチャレンジすることにネガティブになる。
• 「約束」のためには、確実な手段を必要とするから。
• コミットメントフリーにすることにより、チームにチャレンジを促す。
• 自分達が考えられる最大限改善をし続けることにコミットしてもらう。

チームへの提案• チームに対して新しいチャレンジを提案する。
• 強制しない、ただし、議論をする。
• 最後はチームに決断を任せる。
• 同じような機会にまた繰り返し提案する。

組織へのアプローチ• 実験的アプローチによる勝算の伴ったスケール。
• 機を逃さないための継続的なアプローチ。

勝算を上げながらスケールする
個人、チームレベルで実験的に実践を繰り返す。

①小さく試行

実践により得られた知見によりより大きな課題への勝算を上げていく。
範囲を広げるときに進化がある④新たな試行②範囲を広げる ③勝算が大ければスケール

ボトムアップ、トップダウン• ボトムアップ、トップダウンは「方向」であり、どこを起点にしても良い。
• ボトムアップ、トップダウンは、一方向のみを単独で実行するのではなく、まずは、小さくボトムアップしたものを小さくトップダウンする。
• 勝算が高いものは、より大きく展開する。

実践した手段の組み合わせ• より複雑な課題に対して、実践経験のある手段を組み合わせることによって解決することができる。

機を逃さないための継続的アプローチ
一気に前進するポイントはどこかにあるがどこにあるかは判らない。

押し続けても手応えがない手応えがなくても、継続して押し続けない限り、前進するポイントには決して到達できない。

実践への第一歩• 作業に反復とふりかえりを取り入れる。
計画

実行

ふりかえり

計画

実行

改善を提案する機会として「ふりかえり」を行う。
反復的に作業することにより、チャレンジの実施と評価、改善の機会を作る事ができる。

ふりかえりもう一歩踏み込んだプロセスの実装• アジャイル開発のような反復的な開発手法でなくても作業を反復的に行う価値は高い。
• 自分達の今やろうとしている作業の、前後をもう一歩踏み込んで考える。
• 「機能一覧」の機能はどうやって導出されるの？
• テスト設計するときは、どの情報を元にどんな分析をするの？

実践を通じてコンテキストに適合させる• 誰かのうまくいった事例の感想として、「たまたまうまくいった」と言われることがあるが、そのコンテキストに適合した方法になっているからうまくいっている。しかし、その必然性を認知しているとは限らない。必然性を認知して言語化するには、コンテキストと実施内容との関係を認識する必要がある。
• 実験的アプローチは、実践を通じて、その効果を経験し、コンテキストとのすり合せを繰り返しながら、そのコンテキストに対して必然性のある改善を進めていく手法と言える。