苦しみの国
ところで僕はトイレが近い。1時間に1,2回はトイレに行く。
仕事中のコーヒーが好きだからかもしれない。
自分の席から立ち上がってトイレに行こうとすると、必ずと言っていいほどチームメンバーの誰かから声をかけられる。
「内藤さん、この仕様について質問していいですか？」
その質問に答えると、今度は別のメンバーから声がかかる。
「実装内容についてこれで正しいか、見てもらっていいですか？」
こんな調子で、僕はトイレに行く度にメンバーから声がかかるのが日常だった。せめてトイレから帰ってきてからにして、と伝えた。トイレから出ると、順番待ちの列ができていた。なんだか、みんなイライラしている。
電話がかかってくると、それはたいてい僕あての電話だ。どれもが僕の担当クライアントからの電話。
あまりにしょっちゅうかかってくるものだから、電話当番の社員を気遣って、会社の電話ではなく携帯に電話をもらうようにした。それからは、早朝から夜遅くまで、僕の携帯電話は鳴り続けた。
夕方になると、メンバーにベランダに呼び出される。ベランダは、他の人に聞かれたくない話をする時の場所。内容はチーム内の人間関係の相談。どうもチーム内で揉めているらしい。
そこから戻ると、さっきのメンバーと揉めている人に、屋上に誘われる。以下、同文。
この息苦しさはなんだろう。
なんだかとっても忙しいし、心が疲れるぞ。
「あれ・・・喜んでいるのはクライアントだけ？社員も、僕も幸せじゃないような・・・？」
王国の崩壊
2010年代の後半、その小さな王国は終わりの時を迎えた。
印象的な大きな事件があって・・・、という感じじゃなかった。最初からどこかに無理があって、10年くらいの時間をかけて徐々に壊れていった感じだった。
クライアントに見放されたわけじゃなかった。そのときだって、仕事は十分にあった。
・・・だけど。
一生懸命育成した社員がやめていく。あの天才プログラマーは、かなり早い段階でいなくなった。優秀なマネージャーも次々に転職する。
やめていない社員も、モチベーションがとても低い。
社内の雰囲気はギスギスして最悪。
仕事を取ってきても、もはやそれを実行するチームがいない。
かろうじて稼働中のチームは、やる気もスキルも不足していた。
何がいけなかったのか、僕は信頼のおける仲間数人と、原因を追求した。原因と考えられる事実を付箋に書いて、ホワイトボードに並べていく。あっという間に、ホワイトボードは埋まってしまった。
数週間かけて原因分析を終えたとき、僕は冷たい汗が止まらなかった。
うまくいっていると思っていた、”小さくて実践的かつ理論的なチーム開発”、”技術者と技術を大切にする仕組みづくり”には、たくさんの明確な間違いがあったんだ。
絹の目かくしと、無関心の荒れ地
間違いの1つ目が、”絹の目かくし”。
僕は、チームメンバーのモチベーションや集中できる環境を大切にしていた。技術と技術者を大切にしていたから。なので、みんなのモチベーションが下がらないように、集中を妨げないように、チームメンバーたちにはちょっとした目かくしをさせていた。
何を見せないようにしていたか。それは例えば、クライアントの不遜な態度、無理な要求、意味不明の説明。メンバーがそれらに直接関わることは、マイナスだと考えていた。途中経過のやり取りなんて、作業を邪魔するノイズになると思っていた。
日々そんなものに触れていたら、チームの誰もがクライアントを嫌いになり、”敵対の谷”を形成してしまうと考えていた。それは避けないといけない。
だから、クライアントの乱暴で意味不明な表現は、僕という翻訳機を通して丁寧でわかりやすい表現に書き換えてチームメンバーに伝えていた。
重要な情報だけに削ぎ落として要点だけ論理的にまとめた。途中経過の話とか、結論の出ていない話はメンバーには伝えなかった。
無理な要求があれば、メンバーのいないところで僕が応対し、取り下げてもらうよう説得した。
もちろん、クライアントから感謝の言葉をもらえることだってある。それらは積極的にチームメンバーに伝えた。
僕はこうした日々の自分の働きを、すばらしいプロジェクトマネジメントだと思い込んでいた。
これこそ、技術と技術者を大切にするマネジメントの鑑だ、と言わんばかりに。
でも、まちがいだった。
こんなことを繰り返しているうちに、チームメンバーにとってクライアントは神々しい・・・というよりも、なんだか空々しいリアルじゃない存在になっていった。
自分たちの開発したシステムを使用する人間の存在を、正しく実感できなくなってしまったんだ。クライアントから不具合の指摘を受けても、翻訳された優しい表現には切迫感がなく、チームメンバーは不遜な態度をとることが増えてきた。
「先方の勘違いじゃないですか？」
「え、それ、今日対応する必要あるんですか？」
内容を考えたら、クライアントの業務が止まってしまうことは一目瞭然。そんな不具合に対しても、チームメンバーはなかなか重い腰を上げようとしなくなっていた。
そこには、”敵対の谷”よりたちのわるい、”無関心の荒れ地”が広がっていた。
答えつきの課題、混濁の川
2つ目の間違い。それは”答えつきの課題”。
クライアントには困っている課題がいくつもあって、それを解決するためにシステムを構築する。言うなれば、システム構築というのは課題に対してのアンサーの集合体だ。
その課題とアンサーの組み合わせは、多岐にわたる。たとえば、こんな感じ。
【課題】社員のログインパスワード管理がずさん。外部に漏出しそうで怖い。
【アンサー】推測されそうな安易なパスワードは設定できないようにする。また、90日に一度、パスワードを変更しないといけない仕様にする。
こうした課題とアンサーの組み合わせは、すべて僕が聞き取り、僕だけで解決策を練って提案し、クライアントの検討の末、決定したあとになってはじめてチームメンバーに知らせることになっていた。
何を作るのか明確になってからメンバーに作業を依頼するのだから、なんて完璧な仕事の流れなんだろう。煩わしいことを考えさせずに済むのだから、メンバーを大切にしている証だよね。僕はそんなふうに考えていた。
でも、チームメンバーが実際に感じていたことはもっと違うことだった。
（なんでその仕様にするのがベストなんだろう、もっと他の案もあるよね。）
（そもそもその課題って、本当に解決する必要あるの？なんのために？）
（やることが決まっているから、手を動かすだけ。つまらないな。）
そのうち、チームメンバーは課題にあらかじめつけられた解答に従って手を動かすだけになり、クライアントを悩ませる課題自体には関心を持たなくなっていった。
ドドドドドド・・・・。
かつて僕が嫌っていた、混濁した川の流れる音が鼓膜を震わせる。
僕という上流工程と、チームメンバーという下流工程。なんということだ。
閉ざされた箱庭と虚実の霧
3つ目の誤り、”閉ざされた箱庭”。
僕は、クライアントの要求を耳障りの良いように翻訳してチームに伝える。
僕は、クライアントの課題を聞き取り、その解決策を考え決定事項としてチームに伝える。
チームメンバーからすると、クライアントの姿は僕という扉の向こうにいて、よく見えないしつかみどころがない。なんだか都合よく翻訳されている気さえする。
僕という扉がクライアントをどこかに隠しているような形だ。
その逆、つまりクライアントから見たチームの姿はどうだったろう。
チームメンバーが言う。
「その不具合対応、本当に今日やる必要ありますか？」
僕は、そんな態度のチームメンバーの言動をそのままクライアントに伝えることはできない。だから、クライアントにはこう伝える。
「チームメンバー、一丸となって対応中です。」
僕という扉の向こうにチームがいるから、クライアントにも実像が見えない。
僕は2つの箱庭で起きている事実を捻じ曲げてつなぐ、暗くて重い扉になり下がっていた。
加えて、僕の根底にはサラリーマンとしての”お客様は神様”、という根強い思想が腰を下ろしている。チームを閉じ込めた扉の先は上り階段になっていて、クライアントが住まう箱庭はあきらかに上層にあった。
不具合があればすべて僕らの責任。
僕が約束したことは、たとえどんなに困難でも期日までに果たす義務がある。
僕は表現こそ柔らかくしていたけれど、その責任と義務をチームに強要していた。
下層の箱庭に閉じ込められたチームメンバーの不信感は募るばかり。
「それ、本当にクライアントが思っていることですか？内藤さんの見解じゃないですか？」
あれ・・・まわりの見通しがきかないぞ。何が正しくて、何がいけないことだっけ？
事実を捻じ曲げて上下につなげた箱庭のそこかしこに、虚実の霧が立ち込めてきていた。
それは、チームではなかった
”絹の目かくし”をされたまま、”無関心の荒れ地”をさまようメンバーたち。”混濁の川”で流れ落ちてくる”答えつきの課題”を拾い上げて、機械的にシステムを作り上げていく。重い扉に”閉ざされた箱庭”の中は、虚実の濃霧が立ち込めていた。
メンバーたちにとってはもはや、クライアントが実在するかどうかなどどうでも良くなっていた。
メンバーに、やる気がわいてくるはずがなかった。
みんなイライラしていた。
そうして、ひとり、またひとりと、小さな王国から離れていった。
今となっては原因は明らかだった。
僕の、僕の力への絶対的な自信と、メンバーの力の無視。
技術者を大切にするという志は立派だったけど、その方法は不適切だった。
僕は、すべてのクライアントの、すべての課題に答えを示すことができる・・・本気でそう考えていたんだ。そうして、メンバーと一緒に考えるということを全くしてこなかった。
僕はそう呼んでいたけど、実際にはそれはチームとは言えなかった。
僕はチームメンバーを大切にしていた・・・はずなのに。
結局僕は、チームメンバーを手足として使ってしまっていたのだ。
小さな王国の崩壊。
その原因分析に力を注いでくれた、信頼のできる仲間たちはこう言った。
「内藤さん・・・、あなたモノリスなんですよ。」
モノリスを壊せ
モノリスというのは、あらゆる機能を全て搭載した巨大なシステムのこと。僕は、営業、ヒアリング、設計、開発管理、検証・・・といった具合に、実装以外のすべてを行っていた。全部自分で行える、いや、行うべきだという強迫観念にかられていたんだ。
それは、他のメンバーには任せられないと思い込んでいたから。
「僕以外にできないでしょ？」
そんなふうに、メンバーの（技術以外の）力や気持ちを軽んじていたんだ。
それが、小さな王国を崩壊に導いた。
僕は、僕というモノリスを壊すことを決意した。
僕の苦しみを伝えるためのジャーニーではないのであんまり触れないけど、僕自身にとってそれからの数カ月はあまりに過酷な日々になった。自分の考え方、やり方、ときには自分という人格を全否定して力や役割、責任を剥奪していく毎日。なかなか熾烈な体験だった。
ともかく、組織は根底から生まれ変わった。
これまでの失敗体験を徹底的に分析し、論理的かつ実践的なカウンターアクションをたくさん盛り込んで、全く新しいカルチャーのシステム開発組織として再構築した。
僕はその新しいカタチの組織に、名前をつけた。
それが、『PRIME ORDER』なんだ。