組織の息苦しさから抜ける道（1/3）
前回の記事で「しばらく試しに架空インタビュー形式で書くことにする」などと書いたが、ああいうのは題材を選ばないといけませんね、と反省している。
だって、気が小さいと公言しながら、日本でも有数の大成功企業を斬って捨ててるんじゃないかと読み取られても仕方ない記事（実際にそうかは想像にお任せするが、僕はそう言われても断固否定します）を書いていたら、これは「××××に刃物」と思われてもしようがない。そんな危険な人には近づきたくないと、僕でも思う。
あ。これじゃあ、題材を選ばないといけないという理由にはなっていませんね。寓話というのは、分かりづらいことをなんとなく分かってもらうことに使うものだ。ああいう主張がはっきりしている話では切れ味が良すぎて（上で"刃物"にたとえているのはそういう理由）、逆にそうでない人をも傷つけることがあるかなと思ったのです。
なので、架空インタビュー形式は今後も一つの書き方として採用することもあるかもしれないが、題材を選んで書くことにします。ということで、早くも昨日の誓いを破る言い訳をしておく（本当に言い訳の多い人間だなあ）。
さて、この数週間ひきこもり状態だったのだが、今日は久しぶりに仕事の話で人と会ってきた。やはり人とは会うものである。目の前の人のために一生懸命やらないといけないという当たり前のことを思い出させてくれて、やさしい気持ちになる。
今日お邪魔した会社（Y社とする）は、システムの構築と運用をメインの業務にしている中堅のSIerだ。
Y社のM常務が、2008年に上梓した拙著『SEのための価値ある「仕事の設計」学』（技術評論社）をいたく気に入ってくれて、講演してくれないかという話になったのである。
（以下、宣伝です。嫌な人は、次のパラグラフまで読み飛ばしてください。）
そんな話があったので４年ぶりに拙著を読んだのだが、俺っていいこと書いてるなあと改めて思った次第。自画自賛が鼻につくのは承知の上だが、正直自分が書いたの？と思うぐらいなのである。
その上読みやすいらしい。発売当時、母方の叔母と義理の母とが読んでくれたのだが、当時どちらも70歳前後だったのに、「IT用語はよく分からないが、何を書いているかはすごく分かる」と言ってくれた。その後、わざわざ買ってくれた銀座の某ママからもまったく同じ感想をいただいた。
それなのに何で売れていないのかというと、ほめてくれるのは、ある程度人生の機微を知っている女性たちで、肝心の読者ターゲット＝30代中盤のIT技術者（主に男子）からほめられたことがないからだろう。つまり届かなかったのだ。
あ、嘘でした。30代のSEとIT営業からもほめてもらいました（ともに男子）。たった二人ですが、二人とも「これを読んだときは、鬱病で自宅療養中だったのに、職場復帰できました、ありがとう」とのことだった。
図書館にもあるようです。買わなくてもいいので、一人でも多くの人に読んでほしい。
（以上、宣伝終わり。）
※いつものように画像はAmazonから拝借しました（自著なのに・・・）。リンク先は、アマゾンアソシエイトなのでご注意ください。
講演のお題は、「SEが身につけるべき力」というものだった。
Y社ではM常務とO部長を中心に人材育成改革を進めておられるらしく、ここまでマネジメントやビジネススキル、あと当然だが技術教育を充実してこられた。そして、今年からは心構え的なことも外部講師を呼んで研修しようということになった。それに呼んでいただいたのである。
一通り要望を伺ったあと、僕は自論を展開した。
「こういうお話があったので、拙著を読み返してみました。４年前に書いた本をいま読み直すと、自分が本当に言いたかったことが見えてきました。それは、自分で枠組みを作り直そうということだったようです」
どういうことか、以下で解説したいと思う。なお、Y社でした話をさらに一般化している。
僕は正直IT業界のことしか（もっといえば自分がいた会社のことしか）本当は分からないのだが、たぶんどんな業界でも同じだと思う。
IT業界でいえば、1990年代の後半から現在にかけて、ISO9001、CMMI、SLCP、プライバシーマーク、ITSS（ITスキル標準）などの標準（この多くはグローバルスタンダードだ。個々の言葉の意味は分からなくても以下の理解には差し支えない）が次々と生まれ、これらを基に中堅以上のSIerは自社の枠組みを整備していった。
枠組みの整備が進めば進むほど、組織はどんどん息苦しくなり、鬱病になる人もどんどん増えた。出世したくない人も同じく増えた。
ただ、ISO9001などの標準それ自体が悪いわけではなく、運用のしかたが悪かったのではないかと思う。
というのは、ISO9001でもCMMIでもSLCPでも、テーラリングということを組み込んだ標準になっているからだ。
テーラリングとは「組織・企業が業務の基本として定めた標準プロセスや開発標準などを手直しして、個別のプロジェクトや顧客の要求に合わせて実用的な標準（手順・成果物・指標など）を作成・実行すること」（@IT情報マネジメント用語辞典）である。
業務ごとに適用の自由度があり、マネージャは好きに改変できるのである。言い換えると、業務が成功するのであれば、どんなやり方もありなのだ。
これらの標準が本来求めているのは、会社で決めた枠組みに対して、どこを変えたのかを明確にし、それが妥当なのかを会社側はチェックしろということなのだ。
たとえば、ISO9001で言えばこういうことだ。
ISO9001では、仕事のやり方を標準化することで、品質を保証する。たとえば、ある会社では1つのプロジェクトで30種類の開発ドキュメントを作成し、10ステップのプロセスを踏み、1000個のタスクをこなすと決めたりする。それぞれにレビューする／しない、するなら誰がするなどを決める。決めたことを全部やったら出荷基準を満たしたことになる。
それでも、マネージャ（と顧客）が問題ないと思えば、3種類の開発ドキュメントで5ステップのプロセスで、100個のタスクでもいいのである。
その代わり、会社の標準で言えばどのドキュメントを作成したことになるのか、省いたとしたらどのドキュメントなのか（プロセスやタスクも同様）をマネージャが明示し、それを会社が審査することになる。
ところが、標準化の推進部門というのは多くの会社でお役所と一緒であり、審査のための書類を一生懸命つくり、審査のための会議に時間を取ることを要求する。マネージャは本来の仕事をやりたいのだが、こういうことに忙殺されるか、それが面倒なので会社の言うとおりにやるかいずれかの選択を迫られる。
どちらにしろ本来のシステム開発とは関係のない仕事に忙殺される。マネージャの息苦しさ（図）はお分かりだろう。その息苦しさは気分としてメンバーにも伝わっていく。こうして組織はどんどん息苦しくなるのだ（繰り返すが、ISO9001で会社が息苦しくなっているのではない。その運用の仕方で息苦しくなっているのだ）。
いや、わが社はISO9001なんか採用していないけど息苦しいよという方もいるかもしれない。
確かに、ノルマに追われてとか上司が厳しくてとか、他にも理由はある。
ただ、根本にあるのは、業務をするための業務（ISO9001の例で言えば、審査用資料を作るということだ）、すなわち"メタ業務"に忙殺されて、本来業務に集中できなくなっているということのようなのだ。そこからいろいろなしわ寄せが来ている。
本質は、標準ができたからではない。それに伴いメタ業務に忙殺されるようになったことだ。これが息苦しさを形成している。
営業で言えば、日報作成と伝票処理ばかりに時間がかかり、客先にいけないというような現象が、これに当てはまる。これが管理職になると、日報作成どころか日報のフォーマットを見直すなどという"メタメタ業務"までやらないといけない。それで、まさにメタメタになっているのである（駄洒落ですみません）。
では、どうしたら、この息苦しさから抜けることができるのだろうか？
大きく二つの立場がある。テーラリングができる立場にある人と、テーラリングができない立場にある人だ。
それぞれで処方箋が違う。
長くなるので、次回。
あくまで僕の仮説なので、会社が息苦しい理由はそんなところにはないだろうという方は、ここまでお付き合いありがとうございました。
