入社二年目、NTTアドバンステクノロジでの出来事

2013年、頑張るのは限界

この年わたしは、きちんとした形で体調を壊すことになる。
うつ病という診断を受け、無理をして耐えることを諦めたターニングポイントの年でもある。
会社を信じて無理をしても、どうにもならないということを実感し、諦めるまでの過程ということになる。

4月から7月:新しい仕事、覚えよう、たとえ苦しくても

限界まで頑張ると約束したのだから、たとえ精神がおかしくなろうとも働かなくてはならない。
昨年の上司と約束したことは言ってしまえばそういうことだ。
私は仕事に専念し、体調のことは上司を信頼し、任せることにしたのだから、
どんなに苦しくとも、全力で仕事に取り組む責任がわたしにはあった。

4月からは、新しい仕事先、新しい環境で働くことになる。
そういう場所では、覚えるところから仕事が始まる。
まず聞くところから、慣れるところから、例にもれず私もそうだった。
ただ、なかなか難しいのが別の会社の人間に聞かないといけないということ
もともと私は人に聞くことが得意ではない。
独学で色んなことを覚えてきたので、聞くより先に調べてしまう。
いい事なのではと思うだろうがそうではない。
特にネットワークのことになると、世の中にそんなに情報は出ていない。
断片的な情報をかき集めて、組み立てていってようやく
その環境のネットワークに合致した知識になるのだ。

私は調べるのが苦にならない性格だったので、これが裏目に出てしまった。
必要最低限の質問しかしないので、手はかからないが
一つ一つ丁寧に理解しようとするので、スピードが遅いのだ。
当時の仕事は単純作業、そういう仕事の仕方は求められていなかった。

こうなってしまった理由はもう一つあって、私が質問攻めにしたかった先輩(別会社)には
もう一人、部下がついていた。年下ではあるが私と同じ2年目で女性、
それも先輩と同じ会社の、まぁ先輩にとっては正当な後輩にあたる。
そうなってしまうと、先輩はその後輩にかかりっきりになる。
自然に私は蚊帳の外だった。
ももう少し食らいつくべきだったが、
字が読めなくなるほど無理をしていた時期である。
目の前の仕事で手一杯。そんな余力、どこにも残っていなかった。

もっと言えば、当時の私に客先で人間関係を構築していけるほどの
余力はもう残っていなかったのである。
当時は異動や引っ越し、その他度重なるストレスのため免疫はガタガタで、
定期的に軽めの風邪を繰り返していた。
どうしてタオルを投げ入れないのか、理解できないレベルで
おかしなことになっていた。
個人的には社員の状態を管理できていなかったのではないかと今も思うし、
当時の私もそう感じていた。

それでも、私は上司を信頼すると約束したのだから、
黙々と働くことしか許されないのだった。

8月から10月:貯まるフラストレーション、うまく動かない頭

4ヶ月やってきて仕事はどうにか覚えてきたが、相変わらず精神は限界だった。
特にこの部署、ナレッジがとにかく属人化されている。
資料なんてものがほとんど存在しない。
ほとんど協力会社に委託してるから、派遣された人間は自分の知識を共有せず、
保身に徹するという戦略になるためではないだろうか、
本当のところは分からないがとにかく資料がないし、有っても質が悪い

当時の仕事も無理やり変換されたPDFでなければ、
資料を読み込んでスクリプトで自動化するような形にしたかった。
空いた時間で途中までやったが、部分的にしかてきなかったのが残念だ。
私の力不足もあるが、とにかく環境がひどかった。

統合開発環境どころかvimすらない。
ネットワークを扱う現場ですので、それもそのはず
もともとコーディングを行える環境ではないのです。
細い帯域とセレロン程度のCPU、1Gあるかないかのメモリで開発するのは限界があります。

それでも、大量のファイルを扱う際はけっこう重宝された。
これまでの人の目で行うチェックでは、効率が悪すぎた。

これからの時代、インフラとソフトウェアの境界は
どんどん曖昧なものになって行くに違いないと考えた。
(今でも、この考えは間違っていないと思う。
あと数年で世間でも、そういう考えが当たり前になるだろう。
ネットワーク業界はそれまで非効率なシステムを残しすぎていた。)
私はこの会社の未来のために、ソフトウェアのノウハウを
インフラに展開しようと模索するようになった。
これは、決して珍しい話ではない。
特にネットワーク業界はソフトウェアのように、先進的な技術を取り入れて来なかった。
近年DevOpsというカテゴリが確立し、軽量なインフラが見直され始めてようやく、
インフラを自動化することに価値が生まれた。
象のように重い開発体制が主流のネットワーク業界が、
この価値に気づくことは非常に難しかった。
大企業病に侵されてみんな頭が硬い事なかれ主義だしね…)

当時はアジャイルが浸透してきた頃で、 私個人は反復的な開発スタイルとその自動化はインフラ領域でも有用な技術だと感じていた。
今現在の技術トレンドを見ても、私の想いは間違っていなかったと我ながら感心する。

そんなときに丁度良く、若手メンバーで業務改善をしていこうという 取り組みに参加することになった。
私は大阪では一番若かったので下っ端です。
議論の大局には意見せず、見守るスタンスで参加するつもりでした。
一応、私には改善の一案としてインフラ領域にソフトのノウハウを
展開するというもくろみがありましたので、それに関連する提案をしました。

それは自動化ツールの開発方法に標準を作るというものです。
ライトウェイトなコーディング規約みたいなイメージです。
社内に色んな自動化ツールは転がっていたのですが、
使い方がわからなかったり、動かなかったり、
直そうにもメンテできなかったり、いろんな問題がありました。

そのはずです。彼らはネットワークエンジニア、
体系的にソフトウェアを作るという考えがそもそもなかったのです。
これでは、再利用というソフトウェアの最大の強みを活かすことができません。
再利用できるから反復でき、反復できるから自動化を実現できるのです。
このままでは時代の流れについていけるだけの人材が育たない。
まずはソフトウェアに品質を定義する。
私の案の狙いはそこにあった。

まぁでも、採用されるとは思っていなかった。
私は下っ端です。こういうのは年長者がまとめていくものだし。
そもそも、私以外はこの案のメリットをなかなか理解できていない。
なぜなら彼らもまたネットワークエンジニアだからです。

そういう理解を得られない中で、物事を進めてもうまくは行かない。
チームというものに必要なことは、目的やビジョンを全員が共有することだ。
それがどんなに正しく、優れていたとしてもチームがまとまらないのであれば、
無理に推し進めてはいけない。
当時の私もその心得は忘れず。他の提案に期待をしていました。

しかし、この期待は悪い意味で裏切られます。
他の案は贔屓目に見ても出来が悪かったのです。
いい部分もありました。決め方がいい加減だったのです。
多数決ではありませんが、多数決のようなものを
論理的に補強して多数決に見えないようにする。
そんなやり方で決めていったのでだ。
いいことではありませんが、チームが一つになるには必要な時もある。
(私がチームリーダーならそんなことはさせないし、
そんなことをするくらいなら不名誉な撤退を選択する
名誉の進行はデスマーチにつながるからだ。
上層部は満足かもしれないが、インパール作戦のようになってからでは遅い。
人が死んだり、若手が潰れることに何の価値があるのか?)

私は私で家に帰って自分の案をやればいい、そんなつもりでした。
私は自分の案を独りよがりと理解していましたし、
独りよがりはひとりでやるのが一番いいのです。

採用されようとしてる案は酷いものでした。
たしかネットワーク系の勉強会をする。というようなものだったと思います。
そもそも業務改善ではないんじゃないか、みんなが思っていたはずです。
それでも同調圧力という見えない力のおかげで、ことは順調に運んでいました。
トム・デマルコの言うところの魚の腐った臭いが、
そのプロジェクトから出ていた。

やむを得ず、私は軌道修正に乗り出した。
プロジェクトは非常に危険な状態で、
目的やビジョンが定まっていなかった。
各々が勝手に勉強会という曖昧な取り組みに理想を描いて、投票したのだから当然といえば当然のこと。
業務改善という大前提を満たせていないのも、これが原因だった。

こういうプロジェクトで何が起こるかというと、
目的がないため行き先を見失い、迷子になる。
八甲田のようなデスマーチに突き進み、被害だけが増える。
時間は成果を出すことそのものにではなく、
成果っぽいものを成果に見せる帳尻合わせに使われ、
あとには無くても良かったろくでもないものが残ることになる。

そんなものに付き合わされるのはまっぴらごめんだ。
空いた時間はシステム開発の勉強に使いたいのに、
こんな無駄なことのために時間を持っていかれるのは苦痛でしかない。

こうなれば嫌われ役を引き受けるしかないと腹を括った。
改善される業務が不明確などを指摘し、案を引き戻した。

再度改善テーマを整理し、目的やビジョンを明確にしていくしかなかったのだ。
面倒だが、チームにとって目的はそれだけ重要なものだと理解してほしい。
目的が定まっていないテーマなんかすすめるくらいなら、
メンバーの共感が得られないが、目的は明確になっている私の案を進めたほうがマシなのだ。

モチベーションが上がらないのは気の毒ではあるが、
成果は無駄にならないし、成果報告に頭を抱える時間は少なくて済む。
無駄なことをして、それを成果に見せるために頭を抱えるよりもずっとマシということだ。

そして、結局私の案が改善のテーマになってしまった。
再度、テーマを決める中でどのような業務を改善したいのか
明確にするように話し合いましたが、
まともに整理できたのは私の案だけでした。
正しくふるいにかけたら、正しいものしか残らないのは必然ではある。

私が皆の理解を得やすい案を出すというのも手でしたが、
そんなことをすると私がプロジェクトの中心になってしまいます。
私にそんな余力はありませんし、ソフトウェアの標準を決めることが
最も重要という認識を持ちながら、他の案を出すことはできませんでした。

さて、この時期はこんなことをしていました。
基本的には1日数時間、本来の業務にプラスアルファとしてやっていたのですが、
このグダグダしたやり方は非常に大きなフラストレーションでした。

私以外の人間は、とても本気で仕事をしているようには見えませんでした。
主体性というのが無いように思えたのです。
和を壊さないように進めていたら、誰かが解決してくれる。
そんな雰囲気があったように思います。
どうして、理系の大卒院卒がこれだけ揃っているのに
こんなことになるのか、私には最後まで理解できませんでした。

11月から4月:うつ病、仕事を休もう

若手の活動の方向性がようやく見えてきた頃、私は異動の申し出をします。
他と比較しても私のソフトウェア技術は会社にとって有益です。
(現在でも十分にプロとして通用するレベルの技術がありました)
このまま、ネットワークをやっていても健康の問題は悪化するだけです。
降格だろうとなんだろうと、甘んじて受け入れる。
そういう覚悟を決めて、その年の育成計画に健康状態の話をはっきりと書きました。
内容は非常に刺激的なもので、健康状態の問題が出ていて、このままだと自殺する可能性もありうる。
と、書きました。誇張ではありません。
当時私は本気で自殺も考えていました。
通勤の地下鉄に飛び込むのも時間の問題というような状態でした。
流石に異動させるだろうと思いました。
会社には安全配慮義務というものもあります。
少なくとも、産業医との面談くらいはあるだろうと考えていました。