~ソフトウェア品質の向上とそこに関わるすべての方へ~ Software Quality Profession

「混乱からの脱出~ XDDPで現場は甦った~」

(株)デンソー技研センター
古畑 慶次

現場の何が問題か? ~ 個人の習慣と組織文化に挑む ~

 改善戦略は立案できましたが、問題はこれをどう実践するかです。技術者に対して何をどう考え、具体的にどう行動していくのか、推進側が取り組む姿勢を変えなければ、現場の技術者は本気で取り組んでくれません。
 これまでXDDPの現場展開を進めてきて感じるのは、技術的なハードルよりも、むしろ人の意識に問題があるということです。これまでのプロセス改善活動やCMMIやISOの取り組みで、技術者に改善への拒否反応やトラウマを植え付けてしまっている可能性があります。今回、XDDPの導入前に、現場の技術者にプロセス改善について聞いてみると、以下のような話が聞けました。

  • CMMIのレベル2をクリアしたが現場はよくならない
  • 決められたドキュメントは作るが何に使うかわからない
  • どうせまた、しばらくしたら違う方法を進めるのだろう
  • 推進側は現場のことを理解していない 

 これらは、今回のXDDPの展開についてのものではないですが、現場の技術者の推進側に対する不信感をよく表しています。CMMIやISO自身は決して悪くないのですが、推進側が現場への導入を誤り、正しく誘導できていない可能性がありました。こうなると、むしろ今回の取り組みは推進側への信頼を取り戻すことを前提に、我々推進側と技術者の考え方や習慣を変えることが成功への近道だと感じました。そして、“技術者の習慣を変え組織文化を変革する”をスローガンに、“個人の習慣”と“組織文化”に挑む活動を始めました。

展開の方針 ~ PCA と コミュニケーション ~

 XDDPの展開を進めるのに当たり、2つの方針を掲げました。
1.PCA  ( Person Centered Approach ) による個別性、独自性の尊重
2.コミュニケーションを主体にした信頼関係の確立
 プロセス改善の対象である個人の習慣や考え方を変えるためには、個別に対応していくしかありません。ソフトウェアの開発では、プロジェクト毎に要求や制約条件が異なります。また、技術者についても、性格、技術、キャリア等、当然違っています。こうした状況下で、現場に対して十把一絡げに施策を打っても、問題は決して解決しません。
 PCA は、カール・ロジャーズが提唱した、一人ひとりの人間の個別性、独自性を尊重し、あらゆるコミュニティとの積極的な対人関係を深めようとする考え方です。XDDPの展開では、PCAに基づいて、開発状況や技術者の個性を尊重したコンサルティングと技術支援 を活動の中心にしました。
 そして、そのアプローチの中で重視したのが、コミュニケーションによる現場技術者との信頼関係の確立です。“共感”はするが“同情”はしない。“理解しようとする”のではなく“受け入れる”。技術者が直面している状況を察し、伴走者の気持ちで支援を諦めずに続ける。これらは、我々が目指す目標と現場を分析した結果から、自ずと導かれる方針でした。

人を振り向かせる技術 ~ 営業活動から学ぶ ~

 取り組みの中で、一番苦労したのは、Step1からStep2への移行です。Step1では、組織の中でXDDPに個別に取り組んでいる人や、興味のある人が対象でしたので大きな問題はありませんでした。しかし、Step2では、リーダー候補を選定し、XDDPを指導できる人材に育てる必要があります。
 そのためには、XDDPを十分理解していないリーダー候補者に、XDDPに実際に取り組んでもらわなければいけません。XDDPに振り向いてもらわないといけないわけです。このような点から、このフェーズの活動は、“営業”と考えることができます。つまり、この活動は、XDDPという商品を顧客である技術者に買って頂く営業活動であるということです。
 営業の技術は、営業活動で成果を上げている中堅企業や書籍から学び、そこで得たエッセンス(以下)を実際のXDDPの展開活動に活用してきました。

  1. (1)「訪問時間」よりも「訪問回数」

 これまで、何度となく技術者の席まで行き、話をしてきました。その時に注意したのが、“話す時間”より“行く回数”を重視する「訪問時間より訪問回数」という発想です。1時間まとめて話をするよりも、15分を4回に分けて話をする方が効果的だということです。
 技術者は、日々“忙しい”と感じていますので、長く時間を取られることを嫌います。そこで、何度も技術者の元に足を運びながら、彼らの話に耳を傾け、状況にあわせてXDDPの話を少しずつしていきます。席にいないときは、来たことを名刺に書いてキーボードの上に置いておきました。これも1回の訪問でした。
 何度も席まで行って話をするうちに、少しずつ耳を傾けてくれるようになります。そうして、取りかかれる内容を一緒に考えながら、自ら一歩踏み出す瞬間を待ちます。かたくなな態度をとり続ける技術者もいましたが、そういう技術者は、“縁がなかった”と諦めました。

  1. (2)「言い訳」はチャンス

 いざ、取り組みの話題になると必ず出てくるのは、出来ない理由(言い訳)です。「取り組む時間がありません」「全部は無理です」「プロジェクトはまだ途中なので・・・」「取り組むテーマがありません」等、いろいろ聞いてきました。こうした人は、言い訳して、結局何も変えません。そして、皮肉なことに彼の言い訳は当たります。そこに気づかなければ、変わることはできないのです。ですから、出来ない理由に全く意味はありません。それに、この先、できる条件が完全に整うことなど決してないのです。
 しかし、こうした言い訳の対応策が工夫できれば、彼らは取り組まない理由を失います。技術者によって異なりますが、一通り話を聞いて状況を共有できたら、“出来ない理由”を“出来る理由”にかえるアイデアを一緒に考えます。こうして外堀を辛抱強く埋めていきます。
 ただ、言い訳も2種類あります。“前向きな”言い訳と“後ろ向きの”言い訳です。“前向きな”言い訳には、本当に何とかしたくても何ともできない技術者の気持ちが表れています。ここを感じ取り、共感し、受容する姿勢が推進側には必要であると感じています。

  1. (3)技術的な説明は妥協しない

 XDDPを十分理解していない状態では、XDDPの技術そのものに対する誤解が生じています。そこで、技術的な質問が出た時には、的確かつ丁寧に答える必要があります。「なぜ、うまくいくのか?」、「今までと、どこが違うのか?」「どんな技術が新たに必要か?」「習得にどのくらいかかるのか?」等、質問はさまざまですが、すべての質問に納得できるよう答えて、技術者の不安や疑問を解消してきたつもりです。この回答には、推進側とXDDPへの信頼がかかっていますので、誠意ある姿勢が求められました。
 技術者は、「やりたくないから取り組まない」のではなく、「知らないから取り組まない」という場合がほとんどです。技術を理解してもらうまで粘り強く説明すると、能力の高い素直な技術者は興味を持ってくれました。まだ、頭の中のどこかに“なんとかしたい”“やってみたい”“うまくやりたい”という気持ちが残っていた証拠だと思います。

 こうして、現場の技術者を徐々に“せざるを得ない状況”に追い込み、彼らの気持ちの変化を待ちました。そして、取り組むきっかけをつかんだ技術者は一歩踏み出してきますので、そのタイミングで技術支援を開始しました。気持ちが傾いたその瞬間、そのタイミングで彼らが必要としているものを必要なだけ提供したのです。
 世間では、“Time is money(時は金なり)”といいますが、開発現場の改善では、“Timing is money(タイミングこそ金なり)”の発想が重要でした。このタイミングを把握でき、こうした機会を意図的に作り出せる人が、組織には専任者として必要だと思います。

“変化の兆し” ~ 変わり始めた技術者たち ~

 「普及率16%の論理」では、16%を超えると組織全体に影響すると言われていますが、実は確信があったわけではありません。むしろ16%を目標に、あらゆる手段を考え実施してきたというのが本音のところです。おそらく、周りの誰も信じてはいなかったと思います。
 しかし、確実に技術者たちは変わり始めました。「はじめに」では、“変化の兆し”として、論文や社外発表への取り組みを紹介しましたが、今では、次のような技術者も目にするようになりました。

  • 身近な話題でテーマを作り、要求仕様書の書き方の“けいこ”を始めた中堅技術者
  • 「私も課題を持って発表できるような仕事がしたい」と相談に来るリーダー
  • “アーキテクチャ再構築”に自主的に取り組み、コンサルティングを希望する若手技術者
  • “なんとかしたい”とオフショアでのXDDPの活用を相談に来る上司と部下
  • XDDPの勉強会を自ら企画し、課内で部下と一緒に勉強を始めた管理職

 まだ、このような技術者は全体の16%には至ってはいませんが、こうした光景を見ていると個人の習慣から組織文化が徐々に変化している手応えを感じます。組織の中でも、技術者の変化を話題に上げ、嬉しそうに話をする管理者もいます。「もしかすると16%を超えたら展開が加速して組織が変わるかもしれない・・・」展開前に想定したロジャーズの仮説が、今、現場への大きな期待へと変わり始めました。

Vol.11 2010年 8月号 目次へ2. 人材育成へ

ソフトウェア品質のホンネ
SQuBOKソフトウェア品質体系ガイド
セミナー
SQiPセミナー
SQiPセミナー開催レポート
研究会
ソフトウェア品質管理研究会
シンポジウム
ソフトウェア品質シンポジウム
資格試験
ソフトウェア品質技術者資格試験
JSTQB 認定テスト技術者資格
国際会議
世界ソフトウェア品質会議
ASQN
ニュース
SQiPニュース
webマガジン「QualityOne
コミュニティ
ソフトウェア品質確証部長の会(東京)
ソフトウェア品質保証責任者の会(大阪)
SQiPコミュニティ
SQuBOKユーザーの会
SQiP SIG
SQiPアーカイブ(研究成果や実践事例集
SQiPライブラリ
ソフトウェア品質管理の宝箱
調査・研究
ソフトウェア品質実態調査
調査・研究
ソフトウェア品質実態調査