"好き"と"関心"を巡る冒険第三章 Autumn-5

前回→"好き"と"関心"を巡る冒険第三章 Autumn-4 - Sato’s Diary
全話リストはコチラ

「Ｏ部さんも入れて、デザインから徹底的にやろうぜ」
Ｒシステムを大刷新することを決めて、Ｓ高さんが言った。

デザイナーのＯ部さんは、以前から、
「この会社のプロダクトはユーザビリティが悪い。開発の初期からデザイナーが関わって、根本的なところからデザイン設計していきたい」
と言っていた。
しかし、この会社の、目先の短納期案件に追われる開発スタイルと、
柔軟な変更に耐えうる設計ができる開発者がいなかったことから、
その望みは叶わずに来ていた。

このＲシステム大刷新のプロジェクトは、
Ｓ高さん、Ｏ部さん、私の３人それぞれの念願が叶うプロジェクトだった。

Ｓ高さんは、社内では主流から外れているＲシステムに自分のアイデアを盛り込ませて大刷新して、
お客さんや会社を、アッと言わせたいという野望のような願いを持っていた。
しかし、自身はプログラミングスキルを持っておらず、
またＲシステムが開発者たちから嫌われていたため、叶わずに来ていた。

私は、若手の頃に経験したプロジェクトで、
自分やお客さん、プロジェクトメンバーを含む関係者全員が、色々辛い思いをした経験から、
「柔軟に要求に応えられる開発」というものに、
ずっと関心を抱き続けて、
勉強や試行錯誤を繰り返してきていた。

そうして、試行錯誤の繰り返しにより得た知見と、
技術系に振り切ることで高めた技術力により、
この頃、ようやくそれを叶えるだけの力を身に着けており、それを実務で証明したかった。

そして、ダイヤの原石として見出した、このＲシステムは、
その他に必要なスキルや難易度も含めて、
私のスキルが如何なく発揮できる代物でもあった。

こうして、私たち３人を基軸としたＲシステム大刷新プロジェクトが開始した。

　＊　＊　＊

このＲシステム大刷新プロジェクトは、
私がこれまで携わってきたプロジェクトの中で、
最も理想的な形で進めることができたプロジェクトだった。

このプロジェクトを通して、
チームを組むにおいて、何よりも重要なのは、
「利害の一致」
だということに、私は気がついた。

私たち３人を結びつけていたのは、
信頼関係ではなく、
強固なまでの利害の一致だった。

私はＳ高さんのことが嫌いではなかったが、
というか、それなりに好きだったが、
信頼しているとは言い難かった。

Ｓ高さんは、自分の手柄にこだわるタイプで、
自分の手柄にならない仕事は適当なことを言って、かわしていくし、
１のインプットから３のアウトプットを出す能力を持っているところは純粋にすごいと思うのだが、それをさらに８に盛って言うようなところのある人だった。
信頼しているとは言い難かった。

Ｓ高さんの方も、私の技術力をすごいと思ってくれてはいたが、
それを利用して、どう自分の手柄にすっかなー、
みたいなことを考えていそうな雰囲気であった。

そして、何をしているのかよくわからないのだけど、
いつも「いやー、忙しくてさー」と言って、
いつまでもデザインを出して来ないことで有名なＯ部さんのことも、
私とＳ高さんは信頼しているとは言い難かった。

だから、私たち３人を結んでいたのは、信頼関係ではなく、
利害の一致だった。

私は、自分が可能性を見出したＲシステムを、
自分が培ってきたスキルを発揮して、大刷新したかった。
自分の考えた設計が、柔軟な変更に耐えうるものであることを証明したかった。

Ｓ高さんは、自身のリソースマネジメント能力やアイデア能力をもって、
Ｒシステムを、お客さんや会社をアッと言わせるものに大刷新したかった。

Ｏ部さんは、システムのコンセプト設計から関わることで、
デザイナーとして一段上の成果を挙げたいと考えていた。

３人の利害が一致するポイントが、
Ｒシステムの最適解でもあった。

利害が一致すると、何がいいのかというと、
誰もサボらないのだ。

生来の小器用さから、適当にサボりがちなところのあるＳ高さんだったが、
「ここ、Ｓ高さんがやらないと進まないですよ。いいんですか？」
と言えば、やるのだ。

忙しさやら何やらを言い訳に、なかなかデザインを出してこないＯ部さんも、
「デザイン出してこないと勝手にイケてないデザインで進めちゃいますけど、いいんですか？」
と言うと、出してくるのだ。

「やってください」ではなく、
「あなたの望みが叶わないけど、いいんですか？」
で動くのだ。

そして、変に気を遣い合う必要もなかった。

「難しいデザインの要望出したら、Satoさん怒るでしょ？デザインの案を出すと、いつも開発者に嫌な顔されるんだよね」
そう言って、Ｏ部さんがごにょごにょとデザインを出し渋る。
「怒らないですよ。それを実現する方法を考えるのが私の仕事です。だから、思ってるアイデアはとっとと全部出してください」
私の望みは、柔軟な変更や拡張に耐えうる設計を実現することだった。
だから、Ｓ高さんやＯ部さんがどんな要望やアイデアを出そうが、
それに応えることが、私の利だった。

Ｏ部さんの望みは、ユーザーのユースケースを根本から考えたシステム全体のデザイン設計をすることだった。
だから、Ｓ高さんや私が、
「違う！　ユーザーはそういう使い方をしたいんじゃない。そんなデザインじゃ駄目！」
と全NGで突っ返しても、それを踏まえてデザインを設計しなおすことがＯ部さんの利だった。

そうして、私やＯ部さんが全力で出してきたアウトプットである、実際に動くシステムを触りながら、
プロダクトオーナーとして、システムをどうしていくのがいいのかを真剣に考え抜いて、方針やアイデアを出していくこと。
それがＳ高さんの利だった。

完全な利害の一致だった。

新規プロダクト開発の時、
リーダーの私とマネージャーのＯ島さんは、信頼関係で結ばれていた。

Ｏ島さんの品質マネジメント能力や、プロジェクト遂行にあたって決して逃げ出さない姿勢、嘘をつかない人柄を、私は信頼していた。

Ｏ島さんも、私の能力、責任感を信頼していた。

だけどうまくいかなかった。
なぜか？
利害が一致しなかったからだ。

良い新規プロダクトを作りたい。
そこまでは一緒だ。

だけど、私は、メンバーの自主性を活かして、
メンバーや社内の意見を積極的に取り入れて、
コンパクトでいいから柔軟に人の意見を取り入れたシステムを作りたかった。

対して、Ｏ島さんは、がっつり自分で管理して、
機能盛りだくさんで品質をしっかり担保したものを作りたかった。

完全に食い違っていた。

なまじ、相手を信頼しているものだから、
「伝えあえば、わかりあえるはず」
なんて思って、ひたすら破滅に向けてヒートアップしていったのだ。