Archive for 2010年4月月20日

大事な話だから2度、聞いた。標準化のお話@AgileJapan&QconTokyo

4月 20, 2010

標準化、と聞くと「うげっ」と嫌な顔をする方も多いでしょう。
もしくは、あまり「意味がない」と感じている方も多いかもしれません。

一般的に、標準化というのは意味のない(わからない)業務の手順が増えたり、決まりを守るばかりで融通の利かない硬直した組織を想像したりするからでしょう。
ようするに、失礼かもしれませんが「お役所仕事」を想像させるものなのだと思います。

私自身は、中小企業に勤めているためか、むしろ手順や運用が定められていない苦労を感じすることが多いです。
そのため、標準化、がすすめられている組織をちょっとうらやましく思うわけです。
というのも、一定のプロセスが定められていない組織においては、「普通」がないわけです。
「普通」がない不便さは、たとえば「単体テスト」という言葉を一つとっても、
・1つのクラスの動きを検証することを指すのか
・1つの画面の動きを検証することを指すのか
・1つのメソッドの動きをTDDによって検証することを指すのか
がわかりません。
「単体テスト」のみならいざ知らず、標準化、が進んでいない組織というのは、一事が万事その状態なので、なにやるにしても言葉の意味や行動のルールを再定義する必要があります。
そのコストはバカになりません。

2010/4/10(土)のAgileJapan2010、2010/4/19(月)QcomTokyo2010で、この標準化をテーマに、鈴木雄介さんがお話をきいてきました。
鈴木雄介さんのブログには、すでに発表されたスライドと、お話の要点がアップロードされているので、ご参照いただきたいと思います。
http://www.arclamp.jp/blog/archives/qcontokyo_2010.html

お話を聞いて、あらためて企業における「システム」の影響力の大きさを認識させられました。

従来の標準化の場合は、同一の行為が同一のモノを作り出すことを前提に、画一的なプロセスやドキュメントのフォーマットや内部構造として同一のフレームワークを定義してきました。
この標準化は、ソフトウェア開発にたいして効果的ではありません。
というのは、ソフトウェア開発では同じものを作ることはないからです。
というのも、同じものを作るのであればコピーして配布できるからです。

では、ソフトウェアにたいして効果的な標準化はいったいなにか?
鈴木さんはご自身の経験に基づき、
・開発環境の整備
・アーキテクチャ標準を定める
という標準化を提示していました。

これは、従来の標準化が「行動そのものを縛ろう」としているのにたいして、「行動する環境を規定しよう」というものです。
開発環境の整備、またアーキテクチャ標準の詳しい内容は、発表のスライドを見ていただくとして、重要なことは、「環境を規定する」という視点から標準化しようという企ての強力さです。

行動そのものを規定してしまうと、それを強要される人々はよっぽど従順な人でない限り窮屈さを感じます。
また、普段は意識しないもの規定でも、自分の行動が制限されたとたんそのルールに苛立ちを覚えることもあります。

しかし、環境を構築し、その環境に順応するように促し、その順応に成功すると、おのずと行動が整理されることになります。
たとえば、新入社員はすでに会社という完成された(整備されているかどうかは別として)環境のなかに放り込まれます。
そして、その組織の常識にもとづいて、自分の常識を構成し行動することになります。
しらずしらずのうちに、環境により行動を規定されるのです。

企業システムも、これと同じ性格を持っています。
私たちが依頼を受けて作成するシステムも、何がしかの意図、目的を持ってつくられます。
ある期間、ユーザー企業の人々は、このシステムを使用して目的どおりの成果をあげることになります。
しかし、時がたつにつれて意図や目的が時代遅れになり、システムそのものが意味を失うことになります。
恐ろしいのは、システムの意図や目的を理解している人がいなくなる場合、システムそのものを扱うことが、そのシステムの意図や目的を知らない人たちの仕事になる、ということです。
というのは、ながらく使用してきたシステムに仕事の環境を規定され、環境を規定されたことにより、行動そのものが無意識に規定されてしまっているからです。

開発環境やアーキテクチャの標準を定めることで、組織の人々に心理的な負荷をかけずに、標準化の恩恵を得ることができます。
ちなみに、鈴木さんは、標準化の恩恵として、
・アセスメント性の向上
・品質の適正化
・要因流動性の向上
・全体最適
を挙げています。

こうした恩恵を得ることのできる標準化ですが、一つ間違うと人々の行動が意識せずに固定化してしまう、という恐ろしい面もあるのではないか、と感じました。
ですから、鈴木さんのスライドの最後にあるように、「常に改善」してゆくことが必要なのでしょう。
このように考えると、開発以前のユーザー企業の仕事と業務の設計そのものの重要性がわかります。
と同時に、システムを作るということは、ユーザー企業の仕事をつくることでもあり、それは創造性も必要とされるおもしろい仕事なのだと思います。

ランキング参加中。気に入ったら一押しお願いします!
人気ブログランキングへ