Crazy for life（セイカツ イチバン、IT ニバン）

　「船頭多くして船山に登る」という。もちろんそれでは困る。だからここでは4人の船頭をプロジェクトに投入せよと言っているわけではない。しかしセンドウとは、船頭だけではないのだ。以下、プロジェクトに必要な4種類のセンドウを紹介しよう。

■船頭

　当然のことだが、船頭なしにうまく行くプロジェクトなどない。船頭＝プロマネと考えれば間違いないが、明確にプロマネという役割と認識されていなくても、成功するプロジェクトには必ず船頭役のメンバーがいて、プロジェクトのゴールに向かって調整し続けてくれているものだ。

　まぁ、今更ここで船頭について私が解説するまでもなく、ITエンジニアならその重要性については十分認識されているだろうから、さらりと流して次に行こう。

■先導

　次は先導者だ。技術的な先導者がプロジェクトの中にいると、非常に安心感がある。有能な先導者は、常に先回りして技術的な不明点を調査検討し、プロジェクトが抱える技術的なリスクを低減するように努力する。

　ただし、注意点がひとつある。この役割は船頭が兼任してはいけない。この役割を兼任するような技術好き船頭は、放っておくと技術方面に没入してしまうものだ。そして船頭としての役割がおろそかになり、プロジェクトがうまく回らなくなる。

■煽動

　私の好きなジャズバンド、SOIL&"PIMP"SESSIONSの「社長」のパートは"アジテーター"と呼ばれている。観客を煽ってライブを盛り上げる役割だ。

　プロジェクトも、ある意味ライブだ。アジテーターの有無はプロジェクト内の雰囲気に大きく影響を及ぼす。キックオフ時には、メンバーの緊張を解きほぐし、全員が同じ方向を向いてテンションを上げるのを助長してくれるし、プロジェクトの後半、特にラストスパートにもその存在は進捗に大きく貢献する。アジテーターの一言が、メンバーから爆発的なパワーを引き出すこともある。

　先導者と違って、アジテーターは船頭が兼任するのもいいだろう。大きなプロジェクトでは、チームごとにアジテーターがいるのが理想的だ。

　メンバーのモチベーションは、プロジェクトにとって重要なファクターだ。アジテーターの役割を過小評価すべきではない。

■仙道

　「仙道？なんだそりゃ？」と思った人は、勉強不足だ。以前のコラムで、私は「ジョジョはエンジニアの必須科目だ」と言ったはずだ。よもや忘れたわけではあるまい？

　ジョジョの歴史は仙道パワーを源とした波紋エネルギーからスタートした。だから決しておろそかにしてはいけないのだ。ここで注目したいのは、波紋戦士の心意気だ。

　ジョジョPart2。ローマでジョジョとカーズが最初に遭ったときのシーザーを思い出せば十分だろう？波紋戦士は仲間思いやる心を大切にする。これは4人目というよりも、プロジェクトメンバー全員が持つべき力だといえる。

　メンバー全員が他のメンバーを思いやる心を持ち、常に周囲に気を配ることができれば、きっとプロジェクトを楽しむことができるだろう。

　以上、「センドウ」というキーワードで（最後はかなりゴリゴリな感があるが）プロジェクトを円滑に進める上で必要な役割を示してみた。プロジェクトの進行中は、どうしてもタスクやコストや納期ばかりに目が向き勝ちだが、ヒトに目を向けることの重要性も忘れないで頂きたい。

■ヒーローってなんだ？

　ヒーローにもいろいろなタイプがある。自分のことをヒーローだとは思っていないけれど、周囲からはヒーローと思われて頼りにされているタイプ。うまく回っている職場では、みんなが他のメンバーをヒーローと感じ、お互いを尊敬しあっているものだ。

　このように、ヒーローとは自分以外の優秀なヒトに贈る称号であり、自称するものではない。相手の能力を認め、尊重するところからヒーローは生まれる。逆にいうと、自分の持つ能力や情報を積極的に開示し、周囲のヒトの役に立つこと。その積み重ねがヒーローへの第一歩となるわけだ。

■職場を蝕む困ったヒーロー

　しかし、多くの職場には、別のタイプのヒーローがあふれている。自意識過剰な自己陶酔型のヒーローだ。彼らは実際にはヒーローではない。周囲のヒトが彼らをヒーローとは思わないのだから。自分で勝手に自分のことをヒーローと思い込んでいるだけなのだ。彼らは、典型的な例として次のような思考に凝り固まっている。

　『自分は見えないところでみんなのために必死で努力をしている。それなのにみんなはなぜ 自分を嫌うんだろう。まぁいい。自分が悪者と思われても、自分が嫌われ者になっても、それで会社が、組織がうまくまわればそれでいい。あぁ、自分はなんて献身的なんだろう。自分はなんてかわいそうなんだろう。自分は特別だ。自分はカッコイイ。そんな自分が大好きだ！』

■ステルス性ヒーロー症候群とは

　そんな甘美な自己陶酔の世界に引きこもっている、自称ヒーローたち。いや「自称」というと語弊がある。彼らは自分をヒーローと思ってはいるが、ヒトに対してそれを公言することは少ないからだ。

　なぜなら、理解されないことが彼らの妄想の栄養源なのだ。だから、基本的に彼らはヒトに対して自分を開示しない。まぁ、日ごろの態度を見ていれば、ヒーロー気取りなのは一目瞭然なのだが。

　このタイプのヒトは、とにかく仕事を抱え込みたがる。ヒトから理解されない悲劇のヒーローを演じたいので、チームプレーよりも個人プレーを重視しているのだ。彼のやっていることは周囲にはまったく見えない。そう、これを、わたしは「ステルス性ヒーロー症候群」と名付けた。

■情報のブラックホール

　彼らはヒーローだから、組織内のことは何でも知っていないと気が済まない。そして首を突っ込まずにはいられない。彼らの主観でいえば、「救いの手を差し伸べる」ということになるわけだ。

　いずれにせよ、そうやって周囲には見える化を要求しながら、自分だけはステルス並の見えない化を貫き通すのだ。情報は外部から吸い取るもので、吸い取った情報はどこにも出さない。自分ですべて抱えこんで、妄想のネタにするだけだ。

■ステルス性ヒーロー症候群の治療法

　このタイプは、組織内である程度のポジションにあるヒトによく見られるが、それはただ単に影響を受けるヒトが多いから目立つだけなのであって、実際には組織内のどの階層にも存在する。

　新人社員の中にも、仕事を抱え込みがちなヒトを見かける。彼らは、ステルス性ヒーロー症候群の初期症状を見せているのかもしれない。

　治療法はたった1つ。単純だが簡単ではない方法だ。つまり、自分で気づいて変わるしかない。周囲からの意見や非難や攻撃は、この病に対しては栄養源にしかならない。治るためには、自分が真のヒーローの意味を理解するしかない。

　周囲としては、迂遠なことではあるが、辛抱強く患者に気づきを与えるように仕向けるしかないだろう。

　笑いながらこれを読んでいるアナタ。アナタも気をつけた方がいい。仕事を抱え込みがちなアナタは、特に要注意だ。ステルス性ヒーロー症候群は、知らないうちにヒトの心を蝕み、症状が進行してしまう。なんせ、ステルス性なのだから。

■ヒトの基本戦略は、恐怖を避けること

　強靭な意志を持つヒトであれば、恐怖に直面しても微動だにせず立ち向かうことができるのかも知れない。しかし我々のような一般小市民は、恐怖に出合えばしっぽを巻いて一目散に逃げるのが常だ。ほかのすべてに優先して、恐怖を取り除くために全力で逃亡する。崇高な理念を実現するための願望があったとしても、そんなものは恐怖の前では雲散霧消してしまう。それが我々というものだ。

■変化は恐怖を呼ぶ

　ヒトが変化を嫌うのは、慣れ親しんだ状態を失うことへの恐怖だ。「今までと違うやり方を覚えなければならない」「これまでの経験が無駄になる。」「当然いままでより時間がかかるだろう」「また仕事を増やそうとしやがって」「ていうか、ひょっとして自分の仕事がなくなるんじゃないか」

■しかし、恐怖は変化の引き金にもなる

　それほどまでにヒトの行動に影響を及ぼす恐怖は、実は変化を引き起こすトリガーにもなる。つまり諸刃の剣というヤツだ。個人であれば「このままでは他のヒトに取り残されてしまう。」「時代に取り残されたこんな職場で、このまま一生、働いていていいのか？」と奮起して、勉強したり転職したりするし、組織であれば「今のやり方では限界だ、時間と人手がかかりすぎる。何か手を打たなければ」「この業界には先がない。一刻も早く新規事業を立ち上げなければ」と改革に乗り出す。これらもすべて、恐怖のなせる業なのだ。

■恐怖が我々の行動を左右する

　結局のところ我々はいつも、さまざまな恐怖の重さをはかりにかけて生きている。たとえば、「こんな会社にいたら自分はダメになる」という恐怖と「会社を辞めたら一家が路頭に迷うかも」という恐怖の重さを比べて、転職を思いとどまったりする。最終的には、自分が一番重いと感じた恐怖を解消するための行動を選択することになるのだ。

■変化できない組織とは

　このように考えると、組織が変化できない理由が見えてくる。「変化しないとヤバいぞ！」という恐怖をメンバーに与えられないこと。これが、組織を変化から遠ざける元凶だ。ある意味ヌルいのだ。「こうあるべき」という理想は示せてもそこへ至る道筋は示せず、現状維持派のメンバーが抵抗すると簡単に諦めてしまう。「こうあるべき」といっている方にしてみても、切迫した恐怖からではなく単なる願望を述べているにすぎないので説得力もなければ、覚悟も見えない。

■変化のパワーは自分の中にある

　「メンバーに恐怖を与える」というと、パワハラめいた状況を思い浮かべてしまうかも知れないが、そういうことではない。ヒトは、外圧では変わらないものだ。変化のきっかけは、常に自分の中から湧いてくる。エンジニアならみんな分かっているはずだ。なぜ勉強し続けるのか。なぜ最新情報をウォッチし続けるのか。なぜ現状に満足しないで、その先へ行こうとするのか。もちろん「楽しいから」という面があることは否めない。そこにエンジニアの度しがたさを垣間見ることもできる。しかし、自分の心の奥底を静かに観察してみれば、そこに恐怖の影が潜んでいることにも気づくはずだ。

■その先へ進むために、心に恐怖の種を植え続けるのだ

　変化できるヒトは、恐怖の種を自分の心に植え続けているのだ。だから、そういうヒトが自分の属する組織を変化させたいと思うなら、自分自身にしているように、メンバーにも恐怖の種を植えてみてはどうだろう。植物に水や肥料を与えるように、メンバーに適切なタイミングで適切な情報を与えよう。植物を日当たりや風通しのいい場所に置くように、メンバーを社外のセミナーや勉強会に連れ出そう。

　さぁ、みんなで一緒に恐怖を抱擁しようではないか！ そうすれば、きっと変化は訪れる。

■ネットワークの8番目の層

　どんなにサクサクとデータの送受信ができても、伝えたい情報が正確に伝わるとは限らない。OSIの7階層をどんなに完ぺきに設計して実装したとしても、社内ネットワークの最大のボトルネックを取り除くことはできないのだ。なぜなら、そのボトルネックは8番目の層に存在するものだから。その層の名は「ヒューマン層」。

　この層で行われる不適切なフィルタリングにより、多くの情報はその先のノードに伝わらなくなる。また、意図的な改ざんや知識・認識の不足による誤解によって、情報は驚くほど変質してしまう。

■ボトルネックを探せ

　従って、このヒューマン層の品質を高めることが社内ネットワーク品質向上のための最大のキーポイントとなる。それでは、この層のボトルネックにはどのようなものがあるだろうか。今回はその代表的なものをいくつか挙げてみよう。

■プロトコルの不統一

　どんなに小さな企業でも、組織間での話がかみ合わないことが往々にしてある。IPの上でTCPやUDPといったプロトコルが流れるように、例えば同じ日本語（IP）は使っていても、営業部（TCP）と開発部（UDP）では、そもそも通信の確立手順からして違うので話が通じないのだ。

　対策の一例としては、部署間で共通言語を持つことなどが挙げられるだろう。

■セグメント分割

　プロトコルの違いは、組織間でのコミュニケーションで発生しやすいが、セグメント分割はそれ以前の問題だ。組織間の壁が厚すぎてコミュニケーション自体が発生しない。いわゆるセクショナリズムというヤツだ。

　対策としては、インフォーマルな交流の場をつくることが挙げられる。例えば喫煙者であれば、昔の喫煙室が果たしていた役割を思い出してみると、そこにヒントを見つけられるかもしれない。

■不適切なパケットフィルタリング

　人間というノードが持つファイアウォール機能のデフォルトポリシーは、「都合の悪い情報は通さない」だ。外から入ってくる情報に対しては目と耳をふさぎ、自分自身のことであれば口をふさいで外に出さない。このポリシーは、失敗に対する組織の不寛容さの度合いに比例して強化される。

　従って、失敗を悪とする組織文化からの脱却なしに、このポリシーを変更させることは不可能だろう。太陽と北風の逸話を引き合いに出すまでもなく、自発的な行動を促す文化の醸成が求められるわけだ。

■踏み台

　通常のラインマネジメントでいうと、各組織の長は自分の上長と部下の間に立つプロキシサーバといえる。しかしこのプロキシサーバは高圧的な上長のアタックに耐えきれずに魂を乗っ取られ、踏み台にされることがある。イエスマンの中間管理職に多いパターンだ。上からの無理難題を、部下にそのまま無差別にまき散らし、部下からの報告は、自分のフィルタを通して削ったり加工したりするようになる。

　この踏み台の対策は非常に難しい。ここではとりあえず、皆さんの上司の善政を祈っておこう。

■ヒューマン層を最適化しよう

　さて、この短いコラムで「ヒューマン層」のすべてを語りつくすことはできない。上記ボトルネックも、その対応策もほんの一例にすぎない。しかし、インフラをどんなに整えても、社内の情報の流れが良くならない理由の一端は垣間見ることができたのではないだろうか。あとは皆さん自身の手で、自社ネットワークのヒューマン層を分析し、適切な解を導いて欲しい。

■リストラ？　いえいえ、リストアー

　先日、リストラティブ・ヨガのワークショップに行ってきた。多くの日本のビジネスパーソンにとって、「リストラ」という響きは少々マイナスなイメージを喚起させられるものだが、ここでいうリストラティブは「元気を回復させる」という意味のrestorativeだ。

　最近はメンタルヘルスがクローズアップされているとはいえ、未だに多くの職場では「元気を失わせる」、「委縮させる」、「やる気を削ぐ」、「魂を抜く」ようなマネジメントが横行している。今回は、リストラティブ・ヨガのワークショップの体験から、「元気を回復させる」マネジメントのヒントを探ってみる。

■カスタム・メイドで極楽へ

　このヨガは、まさに日頃のストレスから解放してくれる優しいヨガだ。 例えば、円筒形の固い抱き枕のようなボスルターと呼ばれるモノを、四つん這いになって抱え込み、そのまま10分間じっとしているとか。逆に、ボルスターの上に仰向けに寝転がって10分間じっとしているとか。ひとつのポーズに10分間とどまって、そうやって自分の重さでじんわりと筋肉をほぐしていく。それがこのヨガの特徴となっている。

　ところで、筋肉や関節の固さは人それぞれだ。だからインストラクターは、参加者1人1人の状態を確認しながら、たくさんのブランケットを使って身体の各部位のポジショニングを調節して、一番ラクな状態に保ってくれる。参加者は、自分の身体の中で違和感のある部位に意識をフォーカスし、心地よさを感じるポジションを探る。

　室内にはアロマと音楽が満ちている。さらにインストラクターのマッサージまで入ったりする。これはかなりヤバい。気をつけないと、よだれをたらしてぐっすり眠ってしまいそうになる。そうやって、普段は緊張しっぱなしの筋肉をゆるめたり、のばしたりして、疲れきった心身を回復させてくれるのだ。

■足してもダメなら引いてみな

　われわれは何かうまくいかない時には、ついつい、「努力が足りない」とか「気合が足りない」とか、何かが不足しているからダメなのだと思いがちだ。だから、自分にも鞭打ち、部下も叱咤激励して、これまで以上に頑張って現状を打破することばかり考えてしまう。もちろんそれが最善の方法となる場合もある。しかし、別の方法もあるということを、リストラティブ・ヨガは思い出させてくれる。そう、足してもダメなら引いてみればいいのだ。

　たまりにたまった疲労やストレスから解放し、重くのしかかるプレッシャーを取り除くことによって、心身共に回復すれば、自分が本来持っている最大限の能力を発揮できるようになる。スポーツ選手が「ゾーンに入る」ことができるのは、そうやって自分のコンディションをベストな状態に回復できるからだ。

■ゆるい管理ではなくて、ゆるめる管理が必要

　われわれの現場では、人手不足などの理由によって、管理者自身もプロジェクトにどっぷりと浸かってしまい、ついつい管理がゆるくなってしまうことも多い。

　「ゆるい」というのは「何もしない」ということだ。そうではなく、個々のメンバーをしっかりと見て、問題点とじっくり向き合って、積極的に「ゆるめる」。そんな、きめ細かいカスタムメイドな対応が必要なのではないだろうか。

　そんなリストラティブなマネジメントを、みなさんの職場でも取り入れてみてはいかがだろうか。

■面接は当てにならない

　多くのIT企業において、最も悩ましいもののひとつとしてエンジニア採用の問題が挙げられる。

　この時代、頭数をそろえるだけならそれほど難しくはないだろう。しかし本当に欲しいスキルを持ったエンジニアを採用するのは至難の業だ。履歴書や職務経歴書などは当てにならないし、通常の面接で1時間話をしても、エンジニアとしての実力や適性を判断することは非常に難しい。

　そこで今回提案したいのが「ライトニング面接」だ。イマドキのエンジニアにはおなじみのライトニング・トークス（以下、LT）を、面接のときにやってもらおうという話だ。

　でもその前に、準備段階で使いたい「ペルソナ・シナリオ法」についても合わせて話をさせていただこう。どんなに素晴らしいライトニング面接を聴いたとしても、評価基準があいまいでは、結局のところ適切なエンジニアを採用することはできないだろうから。

■ペルソナ・シナリオ法

　採用後に「こんなはずでは……」と思ってしまうのは、多くの場合、組織に必要なエンジニア像が明確に定義されていないからだ。そこでまずはこれ。ペルソナ・シナリオ法で自分の組織に必要なエンジニア像を明確に定義してみよう。

　これはご存知の通り、インタラクションデザインの分野で要件定義に使われる手法なわけだが、自分の組織で欲しい人物像を定義するためにだって使えるはずだ。

　年齢、性別、経歴から性格・趣味までしっかりと落とし込む。また、プロジェクトで何か問題が発生した際にどんな行動をとるかとか、アサインされたタスクに不明確な点があった場合にどう動くか、さらにはプライベートな時間の使い方まで定義する。とにかくなるべく具体的な人格を定義しよう。

　また、ペルソナはひとりではなく、最低でも男女数名分は用意しておくべきだ。そしてそれらを組織内で共有していなければならない。（この共有は、実は重要なポイントだ。既存メンバーが自分のスキルと組織に必要なスキルの差を把握し、軌道修正する役割も期待できるからだ。しかし今日の本題からは外れるので、これ以上の言及は避けよう。）

　ここまで事前準備しておけば、面接時にもかなり踏み込んだチェックができるにちがいない。

■ライトニング面接

　さぁ、必要な人物像が明確になったら、ここからが本番。ライトニング面接だ。カウントダウンタイマーをセットして、5分で自分の伝えたいことを存分に語ってもらおうではないか！

といっても、学歴や職歴の紹介や自己アピールに終始されては困るので、テーマは事前に伝えておいて、募集者に準備してもらわなければならない。

　例えば、求めているスキル（や特定の技術）に対して、それをどういうところで使うべきか、メリット・デメリットはどうか、といったことについて本人のスタンスを語ってもらうのはどうだろう。採用された場合、自分のスキルを活かしてどんなことがやりたいか、などというのも面白い。

　とにかく、直接仕事に関係するテーマでなければならない。このテーマも、必要なエンジニア像が明確になっていればそれほど苦労せずに設定できるはずだ。

　LTの利点は、自分の考えをまとめるスキル、自分の考えを伝えるスキル、資料作成スキルなどがはっきりとわかることだ。それはまさしく日々の業務に必要なスキルだ。

　そして、テーマにもよるが、当人の技術的な志向や技術に向き合う態度もよく見える。発表中やその後の質疑応答からは、そのテーマに対する本人の理解度も見えるし、なによりも本人のナマの姿を垣間見ることもできる。

　ざっとこんな感じだ。どうだろう。

　事前準備は当然必要ではあるにしても、LTを使えばこのように、面接なんてファイブミニッツでイナフなのだ！

　もし、あなたの組織が「モチベーション3.0」というOSをインストールしようとして失敗したとしたならば、それはあなたの組織が、ハードウェア的に「モチベーション3.0」の動作スペックを満たしていなかったからということになるでしょう。

　心理学者マズローは、自己実現理論（欲求段階説）の中で人間の欲求を5段階のピラミッドで表し、ヒトは低次の欲求が満たされた後に、次の段階の欲求を満たそうとすると定義した。

　これを、モチベーション3.0の動作環境として、組織が従業員に提供すべき機能に当てはめてみよう。

●生理的欲求

　生命維持のための根源的な欲求。ほとんど本能レベル。これは組織以前のものなので、ここでは割愛する。

●安全の欲求

　一家が路頭に迷わない程度の収入。健康を害さない程度の労働時間、労働環境。

●所属と愛の欲求

　信頼できる上司、同僚、部下。組織への帰属意識、連帯感。良好な人間関係。

●承認の欲求

上司、同僚、部下からの正当な評価。自分自身に対する満足感。

●自己実現の欲求

「自分の能力や可能性を最大限に発揮したい！」という欲求。

　この中でいうと、生理的欲求から承認の欲求の「上司、同僚、部下からの正当な評価」までは、整った組織であれば、モチベーション3.0をインストールして実行可能となるはずだ。

　しかし、所属と愛の欲求が整っていない組織が多いと思われる。ましてや「上司からの正当な評価」など、望むべくもない…というのが現実といったところだろう。中には安全の欲求まで脅かされているヒトだって実際にいるのだ。

　多くのエンジニアが転職の理由に「専門知識・経験・市場価値の向上」を挙げている。このようなエンジニアはモチベーション3.0そのものだ。

　ところが、それを理由に転職しているということ自体、裏を返せば「今の会社じゃそんなことは望めない」という不満のあらわれといえる。

　そんなわけで、組織内でモチベーションを高めたいのなら、欲求の5段階のピラミッドを順に積み上げていくことだ。順番を間違えてはいけない。

　モチベーションは一番最後にやってくる。

　15～29歳の若者人口がその社会の全人口の3割を超えると、その社会の中で彼らが能力を発揮できる場がどんどん足りなくなるという。

　そしてこのような状況になると、若者は自分が活躍できる場を求めて、海外移住、対外侵略、テロ、革命、内戦といった過激な行動に走る。

　これは、ドイツの社会学者グナル・ハインゾーンが『自爆する若者たち』の中で紹介している「ユースバルジ現象」だ。

　例えば現在ユースバルジである国として、エジプトやメキシコなどが挙げられる。エジプトは実際、今年の初めに革命が起こったし、メキシコは、米国への不法移民が多いことで有名だ。

　過去にさかのぼれば、古くは欧州諸国の大航海時代や、日本でいえば明治維新もユースバルジによって引き起こされた。血なまぐささは拭えないが、その圧倒的なパワーが歴史を動かしてきたことは間違いない。

　しかしまぁ、割合が多かろうが少なかろうが、若者が活躍できる場を求めるのは、古今東西普遍的な現象だ。人口が安定していれば、場が十分にあるので競争の必要もなく、過激な行動は起こりにくい。人口の増加に、場の拡張が間に合わないときに、若者は爆発するというわけだ。

　IT業界、特にドットコム企業（もう死語？）では従業員の比率として、29歳以下の従業員が会社全体の3割を超えている企業なんて普通にあるだろう。そういう企業では、若くて上昇志向の強いエンジニアたちが、満足のいく仕事に就けないということも多いはずだ。

　その時、彼らはどんな行動を取るだろう。まぁ、さすがにテロや革命は起こさないだろうが、能力のあるエンジニアは、迷わず転職する。

　中には社内の仲間をごっそり引き連れて転職する場合だってある。そこまで行くと、ある意味テロに近いかもしれない。読者の周囲にも、あるいは読者自身もそのような行動を起こしたことがあるのではないだろうか。

　ユースバルジの特徴は、貧困による暴発ではない点にある。彼らは活躍の場を求めているのだ。同様にエンジニアの転職理由も、貧困というわけではない。

　もちろん、給料に不満を持つ場合も多いが、生きていくのに必要な最低レベルの金額さえ保証されていない、ということは少ないだろう。評価（の結果としての給料）が、自分の能力や仕事量とマッチしていないという不満が根底にあるのだ。つまるところ、正当に評価される活躍の場を欲しているのだ。

　エンジニアの流出はIT企業にとっては大きな問題だ。従って企業は、それを避けるために、彼らが能力を発揮できる場を創出しなければならない。

　「仕事を割り当てる」のではなく「場を与える」。
　これがエンジニアの心をつかむ秘けつだ。

　便利になることと、ラクチンになることとは違うし、ラクチンになることと、ストレスがなくなることもまた別物だ。

　コンピュータを導入して、システムを構築する。

　これまで我々は何度もそれを繰り返してきている。提供者として、あるいは利用者として、何度も何度も繰り返してきている。

　それで我々は仕事が少なくなって、ラクチンになって、ストレスも減って、健康で文化的な暮らしを手に入れられただろうか。

　残念ながら、この問いにYESと答えられる人はあまりいないだろう。むしろ、我々の仕事量やストレスは増えている。

　なぜ、そうなるのか。今回は、コンピュータ（システム）が仕事を増やしている状況を、パターンとしていくつか列挙した上で、どこに問題があるのかを考えてみよう。

【導入に関するパターン】

■Builderパターン

　経営層が、その時その時に抱えている経営課題を解決するために、個々の部門にバラバラに必要なシステムを導入・構築させる。いわゆる『個別最適化』だ。
全体が見えないまま、部下は横の連携なしに製品を選定したり内製したりして導入・構築する。

　最後に、上司はそれらのバラバラなシステムを使って、全社の円滑な情報共有をするように部下たちに指示するが、もちろんうまくいくはずもなく、部下たちの仕事とストレスは増えるばかり。

■Factory Methodパターン

　新し物好きな上司が、具体的な導入イメージも描かずに新しい製品の導入を決めてしまう。あるいは、取引先との限りなくグレーな関係から導入を決めてしまう。
その後部下を呼んで「今度こういうものを入れるから、どう運用するかはお前に任せる。」と言われる。

　「そ、そんな中途半端に枠を固めた後で投げられても……」と文句を言っても、『神の見えざる手』に抗うことはできない。反抗しようものなら自分の評価は右肩下がりになるのがオチだ。

【人員に関するパターン】

■Mediatorパターン

　オブジェクト（社員）間の相互作用に（メール等の文字ベースの）システムが仲介しすぎると、オブジェクト（社員）間の結合度が低くなる。

　特に大きな企業、あるいは地理的に離れた拠点を多く持つ企業に、『社員同士が疎結合』な組織が多い。

　コミュニケーションの絶対量が少ないだけでなく、ビジネス文書に関するリテラシーが低い者同士がメールでの情報伝達を多用すると、お互いに対して悪い印象を持ちやすい。
上司からのリテラシーの低いメールは特に有害だ。いずれ部下も同じようなメールを送るようになって、殺伐とした企業文化が育まれることになるだろう。

■Prototypeパターン

　システム導入によって、操作の簡易化、マニュアルの整備が進み、インスタンスの複製（新しい担当者の教育）がラクになり、自分の仕事が脅かされる。つまり『存在価値の減少』パターンと言える。

　まぁ、これは悪いことではない。むしろその程度の単純な仕事から解放されることを喜べないとしたら、そこにこそ大きな問題が潜んでいるというべきだろう。

■Singletonパターン

　効率化による『人員削減』が極限まで進み、インスタンス（担当者）がただ一人になってしまうパターン。休めないし残業も増えるし、一体これからどうすればいいんだ？と頭を抱えてしまう。

　このパターンの最悪な点は、複数のインスタンスが同時に存在し得ないというこのパターンの特性自身にある。

　言いかえると、疲れ果てた担当者が辞めた後にならないと、後任者は入らない。つまり、まともな引き継ぎが行われず、知識の蓄積・継承は期待できない。

【運用に関するパターン】

■Facadeパターン

　上述したSingletonパターンとも関連するが、担当者がただ一人どころか、一人で複数の複雑な業務を『掛け持ち』でやらなければならない状態。

　もちろん、これまで以上にたくさんの窓口業務を、これまでと同じレベルで親切、丁寧に行わなければ、周囲からはブーイングの嵐だ。

■Observerパターン

　作業効率と情報共有の名のもとに、次から次へと導入されるさまざまなシステムにより、自分の行動や実績は常に細かく監視されていて、すぐにチェックが入る。

　モバイル機器も持たされて、毎日、どこにいても何かに追われるような息苦しさを感じる。まるで『囚人』のようだ。そうやって社員の心は病んでいく。

　以上、勢いにまかせて羅列してみた。

　勢いだけで書いたので、「GoFのデザインパターンのパロディで行こう！」という当初の目論みからすると中途半端になってしまったが、そのあたりはご容赦いただきたい。

　それはともかくとして、このようにコンピュータ（システム）は我々の仕事とストレスを増やしているのだ。

　しかし、もう一度じっくりと上記のパターンを読み返してみよう。すると、突き詰めて考えるとこれはコンピュータ自体が問題を作り出しているわけではないということに気づく。

　システムを導入するのはヒトだし、運用するのもヒト。失礼なメールを出すのも、人員を減らすのも、たくさんの仕事を与えるのも、結局のところ行きつく先は「ヒト」だ。

　要するに、問題は道具ではなく、それを使う側に存在するということだ。

　そりゃそうだ。コンピュータは与えられた仕事をするだけだし。

　仕事を作り出すのは常にヒトだもんな。

　あぁ、なんともつまらない結論になってしまったものだ。

　しかしまぁ「ヒトが仕事を増やす」なんてつまらないタイトルにしたら、誰もここまで読んでくれないだろうから、タイトルは変えずに置こう。

　え？ タイトルに興味をそそられて読んでみたけど、期待外れの結論だ。騙されたって？

　そうとも。この記事自体が「コンピュータが仕事やストレスを増やす」ひとつのサンプルなのだから。