前回→"好き"と"関心"を巡る冒険 第三章 Autumn-2 - Sato’s Diary
全話リストはコチラ
前職では、何か問題が起こった時には、
まず誰の責任なのか、責任境界を引くところから始まった。
責任のなすりつけあいで、気持ちがささくれていくだけのような場を何度となく経験した。
プロジェクト開始時に抱く「良いシステムを作りたい！」
という純粋な想いは、
そういった時間の積み重ねで、すり減っていった。
対して、この会社では、
何か問題が起こった時には、
責任を追及するのではなく、
目的を達成するために、どうすればいいのかを考えるスタイルだった。
この会社に来て最初に携わったプロジェクトは、
炎上プロジェクトだったので、
まぁ日々、誰かが何かやらかす。
だけど、やらかし報告が上がってくると、
「えぇ～、マジでー？ 勘弁してよー」
とリーダーのＯ野さんが笑いながら言い、
「じゃあ、どうしようか」
とマネージャーのＯ島さんが言って、対処策を考える方向にすぐ進んだ。
心の中で、
（こんな時に、やらかしやがって…）
とイラついて、やらかした人間を責めていた私は、
自分の小ささを反省した。
人を責めるのではなく、
どうやったら目的を達成できるかにフォーカスする彼らの姿勢が
私は好きで、尊敬もしていた。
だけどそれは時に、
問題の根本解決から目を背け、
自分たち自身を守る保険としても機能していた――。
＊ ＊ ＊
2018年秋。
社内フリーランスになる以前から開発閑散期に着手していた
共通ライブラリの大改修が一区切りつくところが見え、
Ｓ津さんと相談して
いったんここで、社内リリースしようということになった。
以前の話でも少し書いたが、
このライブラリは、全社的に使用されており、
各種プロダクトにも組み込まれているものだったが、
内部的に色々な問題を抱えていた。
私はプロジェクトリーダーとして携わっていた案件の中で、
その問題に気がついて、問題提起を行い、
Ｓ津さんと私で技術部からそのライブラリを引き取って、
問題の根本解決のための作業を行っていた。
問題には、
技術的な問題と、
体制的な問題の２つがあった。
私がライブラリ内部に潜む問題に気づく以前から、
細々した問題には、社員の多くが気づいていたが、
「技術部が面倒をみてくれるはずだから」
「いつまでたっても技術部が直してくれない」
そういう声を出すだけで終わっていた。
しかし、問題の経緯を紐解いていく中でわかったのは、
そのライブラリは、元々は開発部の一社員が作ったものだったということだ。
それが、社員の離職にともなって、設計書も、ろくな引き継ぎもないままに、順々に担当者が変わっていき、
最後の担当者が離職時にたまたま技術部にいたことから、
なし崩し的に技術部が面倒を見る羽目に陥っていたのだ。
そういった経緯で面倒を見ることになった技術部の社員たちは、
このライブラリの仕様も作りも全くわからず、
それでも、このライブラリに関する問い合わせになんとか答えられるようにと、ライブラリのソースコードを読み解いて、仕様を把握しようとした。
しかし蓋を開けてみると、度重なるつぎはぎの改修によって、
誰にも読み解けない状態となったソースコードがそこにあった。
元々は、シンプルな作りの機能だった。
しかし、様々な要件に対応するために、
これまでの担当者たちが、要件の全容を整理しきらないままにつぎはぎの改修を繰り返し、
そして、最後の担当者が、やはり要件を理解しきらないままに、大幅な改修を行い、
それによって、完全に誰にも読み解けないような代物になってしまっていたのだ。
最後の担当者が行った改修は、
速度を改善するためのものだった。
実験的に試してみる分には悪くない取り組みだった。
だが、テスト工程で様々なテストデータを流していく中で、ぽろぽろと不具合が出てきた。
彼はそれに対して、自分の考えた方式に問題がないかを仕様を整理して再検討することはせず、
つぎはぎ的な改修をひたすら充てていった。
そうして、テストに使われたデータに関してはクリアしたということで、正式リリースされた。
そして、それが会社のプロダクトに組み込まれて展開され、
現場から不具合報告が上がってくる都度、
つぎはぎの改修が行われ、
やがてその彼が退職して、
誰にもどうしようもない状態となってしまった。
こういった経緯が、
ソースコードの改修履歴や当時の議事録などを紐解く中で、
見えてきた。
テスト工程の時点で引き返す判断をしなかったことについては、担当者だった彼の落ち度だと私は考えている。
だけど、彼一人が悪いわけではない。
彼一人に任せきりにして、詳細を確認せずに、
テストクリアしたということだけで、
リリースの許可を出したこの会社の体制に
大きな問題があるのだ。
以前も書いたとおり、
営業の強いこの会社では、
素人目にわかりやすいものがウケて、
ぱっと見にわからないところがおざなりにされた。
「処理速度を速くする」というのは、わかりやすくウケやすいところだった。
けれど、要件を整理して全体設計するところを省いて
速度を速くするというのは、
貧弱な土台の上に高層ビルを建てようとするようなものなのだ。
まず、要件と現状の作りを整理して、
要件を満たす土台を作ってから性能改善、
という順番なのだ。
ライブラリを引き取った私は、
上述の問題の経緯を紐解いた上で、
関係者たちに要件をヒアリングしながら整理して、
耐久性の高い土台をつくる作業を行った。
ひとつの問題として、仕方ない話なのだが、
どうしても速度が落ちる。
ある程度落ちるだろう、と思っていたが、
予想していた以上に落ちた。
過去の担当者たちが行ってきた、つぎはぎ改修も含めて仕様を整理しなおした結果、かなり要件が多く、
それに耐えうる作りにしたところ、現行ライブラリの1.8倍の速度になった。
Ｓ津さんと相談した。
「でも速度はこの先の改修で上げていくし、
そもそもの要求仕様が満たされていなくて困っている案件もあるから、ここはいったんリリースしよう」
そういう話で決まり、
マネージャー会議で、共通ライブラリのリリース報告を行うことになった。
＊ ＊ ＊
毎週木曜日に、営業以外のマネージャーたちが集まる定例のマネージャー会議が開催されていた。
私はそこに出席して、報告を行った。
改善内容、現行ライブラリからの変更点などなどを説明し、
そして、速度の測定値についての報告に移ったところで、
「なんで、こんなに遅くしてるんだ！」
ひとりのマネージャーが怒鳴った。
彼は、最後に行われた速度改善の改修にGoサインを出したマネージャーだ。
そしてそこから、場はざわつき始めた。
「いや、俺も今朝、測定値の最終報告を聞いたばかりで…」
Ｓ津さんは、速攻で自己弁護に走った。
最終報告は今朝だが、以前から定期的に報告や相談はしている。
他にも、このライブラリの改修に関して、
速度問題も含めて、随時相談をしてきたマネージャー達が
何人かいるが、全員沈黙だ。
「でも0.1秒が0.2秒になったとして、ユーザーの体感速度にそこまで影響出る？」
唯一、技術部のＳマネージャーだけが助け船を出してくれる。
それ以外のマネージャー達は、問題点の指摘をするか、我関せずか、だ。
速度はこれから上げていくこと、
インタフェースは変えていないので、従来のライブラリを使いたければ使えること、
ただし、従来のライブラリはこれ以降メンテナンスはしないこと、
それを踏まえて、各々のプロジェクトで、どちらを使うかを決めてもらえればいいこと、
etc..
私は辛抱強く説明した。
やがて、場は穏やかとなり、今度は、
どうしたら速度を上げられるか、という話で
マネージャー達は、楽し気にアイデアを交わし始めた。
ひとまずリリースすることに話が落ち着いたことに安堵しつつも、
（この人たちは、いったい何なんだろう…）
私は唖然としていた。
このライブラリの問題を作ったのも、放置してきたのも彼らだ。
私は彼らに礼を言われこそすれ、文句を言われる筋合いなど一欠片とない。
唯一助け船を出してくれたＳマネージャーは、去年入社したばかりで
この問題に責任のない唯一の人だった。
問題に責任のある人達が、他人事のように文句を言ったり、
自己弁護に走ったり、我関せずの態度を取ったり、
楽しくアイデアだけをわいわいと語り合う。
私はこの会社の、色々楽しくアイデアを語り合うところや
問題が起きた時に責任の所在を追及するよりも、
どうすればいいかを考えるところが好きだ。
だけど、それがまた、今回のライブラリのように、
責任のない誰かに問題を押し付けて、裏に問題を積み上げたまま放置することにも繋がっているのだ。
「そもそもなぜ、この問題が起きたか」
それを見ようとしないから、
自分たちが引き起こした問題であるという意識を彼らは持っていないのだ。
この頃関わっていた、他のプロジェクトでも、
根本的な問題の解決よりも、
目の前のことをこなすことに
関係者たちが終始するプロジェクトがいくつかあった。
それに付き合えば仮初めの仲間として
受け入れてもらえるけれども、
根本的な問題の解決を唱えると、
目くじらを立てることを狭量だと言われたり、
「他の人は君みたいに優秀じゃないんだから仕方ないよ」と言われたり、
「君が勝手に解決してくれる分には構わないよ」と、人任せな態度を取られるようなところがあった。
社歴の長い社員たちが主メンバーのプロジェクトで、それは顕著だった。
想いを共有して、活発に議論しながら、
ひとつのモノを作り上げていくこと。
自律的な人達と一緒に作り上げていく時間。
それが私の望むものだった。
そして、それがこの場所にあるように思っていた。
だけど、その奥に、
忙しさや優しさを口実にして、
自分たちが引き起こしている問題から目を逸らす姿勢が
透けて見えるようになってきたこの頃から、
どれだけプロジェクトを共にしても、
どれだけ楽しげなアイデアを語り合っても、
私の心は、どこか満たされなくなっていた。
システムに対して真摯であるといえないのだ。
自分たちの作るシステムに対して真摯であること。
それも私の中で譲れない大切な価値観なのだ。
（つづく）
