【巻頭言】
正々堂々 恥じず媚びず誇らしく
楽顔・美顔・誇顔 溢れるカイシャ
1.
世界中で「本気」が飛び交うカイシャ
異文化の壁をよじ登る人たち
2.
矛盾のマネジメント
生きる力を引き出す
3.
笑えるカイシャ
笑う門に福来る
4.
「女性を活かせるカイシャ」考
女性の多様性と向き合う
5.
良いヤクショ
職員の条件と人材マネジメント
6.
IT企業で働く人たちの喜びのツボ
どこにあり、どう押すか
7.
心に火が点くR&Dマネジメント
技術者と会社の協働キャリアづくり
8.
〈良い組織〉を作れ
個の力を組織に展開するマネジメントプロセスの革新
9.
「握り」が引き上げるM&Aの期待成果
仏に魂を入れる組織能力の開発
10.
アジア人材を育成する「良いカイシャ」に
11.
中国・アジアにおける「日本企業ブランド」を考える
アジアの人材をひきつける日本発の人材マネジメントのあり方
12.
社員にとってホントに良い報酬
愛のあるお金の流れを作り出せ
13.
報酬における経営者満足は「良いカイシャ」につながるのか
14.
飽きないカイシャの見えない仕組み
これからの日本型「良いカイシャ」の条件
15.
年金設計に込める「良いカイシャ」と言われるための思い
【心理学ゼミナール】
人材論が根本から変わる
【巻末言】
「良いカイシャ」原論
日本企業は特異点を目指すのか
IT企業で働く人たちの喜びのツボ
どこにあり、どう押すか
 |
増倉 洋 |
IT企業に働く人たちの仕事は「動作するシステムや製品を作り上げること」である。モノを作り上げる仕事は、本質的には大変面白い。特に、IT開発プロジェクトは、大規模案件から簡単なものまで、モノを作り上げる体験に関与する機会が大変多いと感じる。
IT企業に働く人たちの「喜びのツボ」は、「受け手に喜んでもらえるシステムや製品を、遠回りや無駄な作業を行わずに、効率よく作り出す」という点にある。
「受け手に喜んでもらえる」「遠回りや無駄な作業を行わない」は、顧客の事情や取り組んでいる対象の複雑さなど、制御できない部分で決まることが多い。本稿では、これら制御できない部分の存在を受け入れた上で、その前提の下で、マネジメントがどのように「喜びのツボ」に近づけるのかについて考察したい。
プロジェクトマネジャー vs. 開発技術者
とあるIT開発プロジェクトのミーティングから。このプロジェクトは、自社のWebサイトで会員制サービスを提供するためのシステムの開発を行っている。プロジェクトマネジャーと複数の開発技術者が集まり、週に一度の割合でミーティングを持っている。
以下、プロジェクトマネジャー（以下PM）と開発者（以下D）の会話―
PM「それじゃ報告を。昨日、マーケティングと話しました。このサイトへの
登録だけど、やはり、今まで当社のメールマガジンに登録している人
との連携をとりたい、と言っています」
D 「連携をとるって？」
PM「まずメールマガジンでこのサイトの案内を送りたいそうです。リンク
を埋め込んでおいて、そこをクリックすると、自動的にこちらのWebに
も登録されるようにしたい、とのことで」
D 「それ、どうやるの？ メルマガユーザーのデータベースって違うじゃ
ない。一体どうやってユーザーの情報を持ってくるわけ？」
PM「メルマガ登録ユーザーの情報を渡す方法はマーケティングで考え
る、と言っていますが……」
D 「ふーん……じゃ、メルマガユーザーとこのサービスのユーザーと、
登録が二重になるけど、それはいいんだ？」
PM「それは、仕方ないってことじゃないでしょうか？」
D 「でもさ、だとしたら、そもそもどうしてメルマガのユーザーを持ってき
たいわけ？ ユーザー属性がわかっているからでしょう？ それを、
一方だけ更新してもらって、他方は更新しないってことで良いのかな」
PM「……良くないかもしれませんね」
D 「良くないんじゃないの？ いや、わからないけど」
PM「……難しいでしょうか？」
D 「さぁ……大変じゃないかもしれないけど、大変かもしれない。データ
ベースだってもうスキーマー（※）も固めたし正規化（※）もやってしまっ
た。これからいじる？ どうする？」
PM「……えーと、スケジュールは、どれくらい……？」
D 「いや、だからさ、わかんないって。本当に」
PM「マーケティングに聞いてみましょうか？」
D 「聞いたってわかんないよ、そんなこと」
PM「……あの、どうすればわかりますか？」
D 「わかんない」
PM「……」
D 「……」
上記のようなやり取りは、規模の違いこそあれ、日本全国のIT関連プロジェクトにおいて無数に発生している。この例では社内の開発プロジェクトだが、顧客からシステム開発を請け負ったプロジェクトでも、全く同じように発生する。
これは「顧客や、そのシステムに関連する部署と折衝する役目の人と、プロジェクト内にこもって作り上げる役割を負う人との、外界の変化が引き金となっての衝突」である。
プロジェクトマネジャーの仕事は、外に向かって開かれている。ユーザーや顧客、さらには、現時点では明確に意識されていないような潜在個客まで、様々な人々と話し、その中からアイデアやあるべき姿を得る。この作業を通して、最終成果であるシステムは洗練されたものになっていく。
一方で、プロジェクトの中で作業を行う人は、外部世界にはあまり目が向かず、自分たちが作り上げようとしている製品世界の整合性や完全性が主な関心事となる。プロジェクトマネジャーからいろいろなインプットを得ても、それはせっかく出来上がりつつある製品世界に、完成前から増改築を強いられているという感覚で受け取られることが多い。
システムは、開発技術者が一行ずつプログラムを書くことによって生み出される。だから、開発技術者はその製品世界をすべて支配し、閉じた世界での全権を持っているというマインドセットに陥りやすい。一度、そのような考えに取り付かれると、そこから出てくることは、とても難しい……
冒頭のやり取りでも、開発中のシステムの「創造主」である開発者は、プロジェクトマネジャーからの提案を、これまでの進捗や提案内容の不完全さを盾にして、拒否している。このような形での拒否は、プロジェクトの進行を弱め、また、この場に居合わせた人やその他の人のモラルを、下げてしまう。
創造主たる開発技術者が、製品世界を十分に実現するだけの技術力、開発力を欠き、その欠落を長時間労働で補おうという行動に入った場合、そのプロジェクトはIT業界で“デスマーチ（死の行進）”と呼ばれる状態になる。
繰り返しになるが、このようなやり取りは、今この瞬間、あなたの会社の現在進行中のシステム案件でも発生しているかもしれない。この「衝突」が常に最悪の結果を生み出すとは思わないが、プロジェクトマネジャーにとっても、開発技術者にとっても、ユーザーなどそのシステムの最終受益者にとっても、そしてもちろん会社にとっても、不幸なことに違いない。実のところ、このような衝突は、開発に関わる人々が不幸になる原因としては最もよくあるものの一つである。そして、不幸なプロジェクトマネジャーと“デスマーチ”を突き進むプロジェクトの組み合わせは、その組織の優れた製品やサービスを生み出す力を、徐々に奪っていく。
外部環境や達成すべきゴールの変化への対応を前提としたプロセスを確立し、磨き込み、貫徹する
→ツボの押し方：「優れたプロセスを共有する特別な集団」としての共同体意識を作り出す
たとえ1カ月の作業の結果出来上がる成果物でさえ、我々は本当にそれが自分たちの意に沿うものなのか、欲しかった通りのものとして出来上がってくるのか、正確に言うことは難しい。未来に向かっての想像力はごく限られており、しかも危険なシグナルでさえ、“自分の見たかった未来”の一部と解釈しがちである。特に「一見すると人間に似た振る舞いをするが、実のところ大変に、大変に、異質な存在」であるIT上にナニモノかを構築しようとすると、自分の愚かさや想像力の欠如、思い込みなどに、常時直面させられることになる。
建築中のITシステムに、完成する前から、増築や改築を繰り返さなくてはいけないことは日常茶飯事として起こる。それならば、あらかじめ設計を完全に行ってから建て始める、というやり方は、うまくいかないものと認め、別のやり方を探さなくてはいけない。
建築中のある時点で、その時点での出来具合を判断して、間取りや壁の素材、色などを変更できるような方法とする。そして、その方法をチームの全員が共有し、さらに、方法をより洗練されたものとするための努力を続けていく。
そして、一度決めた建築の進め方に関する合意事項（＝プロセス）は、何があっても、一つの例外もなく、全員が遵守する。それが一見するとどんなに奇妙なものであっても、人間の自然な感覚と異なっていようとも。
冒頭の会話の例で言えば、プロジェクトマネジャーは気軽にマーケティングの話など聞かず「マーケティングからフィードバックをもらう日程」と「その対応を検討する期間」を、あらかじめ開発の工程に入れておくべきであった。さらに、実現の難しさと機能の必要性をどのように秤にかけ、対応する／しないを決定する基準も、持っておくべきである。さらに、何か変更や機能の追加への要請が来た場合、対応する／しない、という稚拙な判断ではなく、その追加や変更の優先順位を決定する、という方式をとるべきである。
冒頭の会話では、何の構造も基準もないままで事情によく通じていない他の部門の話を聞いてしまったために、中途半端に受け取った要求はプロジェクトとの間で板ばさみなってしまった。短いやり取りの間でも、プロジェクトマネジメントという観点から、非常に多くの間違いや不全を見出すことができる。
プロセス（上で述べた「建築の進め方に関する合意事項」）は、どこからか与えられるものであってはならない。開発に関わる人がすべて関与し、討議した上で、顧客や外部環境に合わせて、一番よいものを、プロジェクトのたびに決定し、改善していく。プロセスを改善する作業を、開発作業の一部と位置づけて、絶えず実施していく。強い決意をもって常時プロセスを維持し、改善しようと試みても、開発が佳境に入れば、プロセスを変化させる余裕などなくなってしまう。開発期間を通して、余裕のあるうちに、最良と思えるやり方にたどり着き、実績を積んでおくことは、非常に重要である。
開発プロジェクトの都度「最良のプロセスを求める」という磨き込みの努力を繰り返していくうちに、その組織におけるプロセスは一定の幅の中に落ち着いてくるはずである。
組織がこの段階にまで達し、その場で働く人々が「洗練されたプロセスを共有する、特別な集団」という感覚を共有するようになれば、しめたもの。本稿の冒頭で「喜びのツボ」は、成果を「遠回りや無駄な作業を行わずに、効率よく作り出す」と述べた。これを可能にするための、強固な組織土壌を得たことになる。
「遠回りや無駄な作業」は、時には避けられない。それでも、自分たちが決めたプロセスをもって検討し、仕方がなければ受け入れる、という対処は、単に不平不満を抱きながら避け難い現実に隷属することとは、本質的に違う。
うまくいって当たり前、失敗すれば文句を言われるが、
感謝の言葉はもらえない
→ツボの押し方：「ご褒美」を可視化する
「事前に約束した内容の最終成果を、決められた期限と費用で作り出した」という事実は「契約の履行」という概念から見れば、それ以上でもそれ以下でもない。それでも、作り出す作業に関わった人々にとって（そして顧客や発注者にとっても）、これをやりおおせたという事実は、単に契約を履行したという以上の意義がある。
筆者は以前、とあるソフトウェア製品の開発プロジェクトに、プログラムマネジャーとして関わっていた。製品が出荷され、店頭に並び、最初の数日間、サポート部門に異常な不具合の存在を示す問い合わせがないことを確認できると、人生の一つの章が終わった、と感じたものである。誇張ではなしに、人生のあるステージを通過した、と感じた。
発注側やその製品を購入する人にとっては、期待通りに動くことは当たり前。でも、作り上げる側にとっては、そこまで行けることは奇跡とさえ感じる。建築のように、目で見ることができ、身体で感じることができるものなら、成果の良否ははっきりする。ところが、ソフトウェアのように目に見えない論理の積み重ねでは、自分たちの作り上げた成果が本当に正しかったのか、一見すると正しそうに見えるけれど、ちょっとした外界条件の変化で、それこそすべてが瓦解するんじゃないか、という恐怖心をぬぐえない。
システムや製品が動き出し、一定期間が経過すれば、内部の論理はほぼ試され、動作していると確認できる時が来る。顧客やユーザーは、もちろんそんなことは意識していないが、利用開始後、しばらく過ぎた時点で、関係した人々は、ようやく胸をなでおろすことができる。
この段階で、何か目に見える「ご褒美」を共有することを考えてみよう。「打ち上げの宴会」のように、消えてしまわないものが良い。トロフィーでも盾でも記念品でも何でも良いが、ともかく、机の上や壁の上に置いて目に止まるもの、自分が過去にいくつのプロジェクトを超えてきたのか、自分自身と周囲にも示せるものが良い。
関与した人全員が、同じシンボル化された「ご褒美」をもらえるようにする。関与した人全体に確実にこれを実施していくことは実のところなかなか難しい。プロジェクトマネジャーが対象者を会社に申告、という形での実施が良いだろう。
目標管理やコンピテンシーなど人事評価は、IT企業で働く人々にとって大きな区切り―それこそ、人生における一つの「章」と言っても良いような―とスケジュールがiみ合わないことが多い。また、これらは「人」の評価であって、元来プロジェクト自体の評価ではない。会社のマネジメント側から見れば、長期的な視点では人事評価制度は役割を果たすものの、人事評価によって「喜びのツボ」を押させようとするのは、あまりうまくいかないと考えるべきである。
最後に
本稿では、IT企業で働く人たちの「喜びのツボ」を、「受け手に喜んでもらえるシステムや製品を、遠回りや無駄な作業を行わずに、効率よく作り出す」と定義して、これを押さえる方法として、二つの工夫を示した。
「他の人に喜んでもらえるようなナニモノかを作り上げることはとても面白い」という価値観を中心に据えれば、これ以外にも、その企業の事情に合った、いろいろなアイデアが出てくるだろう。ITに関与する人々の処遇を考える際には、このような価値観と矛盾をきたしていないか、一考することを、強くお勧めする。
会社が、不幸なプロジェクトマネジャーと常態化した“デスマーチ”の工場となるのか、喜んでもらえる製品やシステムを継続的に作り出す“強い組織”となるのかは、この価値観をどこまで尊重し、貫くことができるのかで決まってしまうのだから。
| トップへ戻る ▲ |