ボトムアップでプロジェクトをモダンな開発環境に構築しなおしてる話し

以前までメインで担当していたPHPなプロジェクトが最近Jenkins使ってCI回したり、
バージョン管理ツールをsvnからgitに移行していたり(まだ完全移行できてない)、
FluentdやDocker、Ansibleを使ったりとモダンな開発環境へと生まれ変わろうとしている。

全ては主導してくれている同僚H氏の活躍のおかげなのだが
実はこれらは以前からボク自身もやりたいと考えていたのだがなかなかすすめられなかった。
その原因が判明したので自戒の意味も込めてブログに書いておく。

補足情報

なお、誤解されそうなので補足するとボクがプロジェクト在籍中にすでにモダン環境への改善は行われており
ボクが別のプロジェクトにアサインしてしばらくしてからそれらの成果が表に現れてきた、という感じです。
ボクが同僚H氏にとっての癌になっていたわけではないっす。
むしろH氏のアプローチを全面的に支持表明してましたし。

一連の流れ

つまり？

新しいツールを導入したい！とぼくはいうだけだったということですね。
同僚H氏は

「新しいツールではこんなことが出来る、仮にこういう問題が起こってもxxxをみんなで行って習熟度をあげていれば
問題なく解決することが可能だ！だからこのツールの導入をお願いします！！！」

というようにただの希望、願望だけでなく具体的なメリット、問題発生時のトラブルシューティング、またトラブルシューティングのノウハウ共有方法を予め提示していたわけです。
この段階でなにがどう違うのか明々白々ではあるのですが
結局のところぼくはやりたい！という提案こそすれどそのツールを使ってなにをどう行うのか？みたいなところまで学習しておく努力を怠っていたわけです。
そうすると当然管理者たる上司はリスクを出来るだけ避けようとするので「こういう問題起きたらどうするの？」と聞くわけですね。
ぼくも一応「その問題はこのツールのAという機能でなんとかなる」と回答していたんですがどこかのブログや勉強会で聞きかじった知識に重みが生まれるわけもなく

「なるほど、でもそれはそのツールを学習しないといけないのだよね？
今現在Bで問題なく運用出来ているのに敢えて学習コストをかけてそれをみんなに覚えさせるのは厳しいかな」

と答えられることになるわけです。
その判断自体は↑でも述べているように間違ってないし、正しいと思います。

ターニングポイント

管理者はリスクを避けたいだけで導入に反対しているわけではない

という点がこの問題の最大のターニングポイントです。
つまりH氏はそれも含めてチーム全体で学習コストを払うだけの価値があり、またそうすることで業務の効率化や合理化が行えるようになると切々と説いたわけです。
コレはつまるところ経験者と未経験者の発言の重みに起因します。

経験者は過去のトラブルなどから想定し得る問題に対する答えと想定される対処方法を具体的に答えられます。
翻ってぼくの発言は実際にそのトラブルを経験した、もしくは自分で解決したわけではないので言葉に重みがないんですね、ペラッペラだとペラッペラ！

「何を言ったかではなく誰が言ったかが重要だ」みたいな言葉がありますがまさしくその通りで

「当方ボーカル、ギター、ドラム、ベース募集中」問題

率先者こそがもっとも学習コストを払わなければいけないのにも関わらずその努力をせずに声高に提案してもどうやったって採用はされないでしょう。
もしあなたが周りの上司や同僚から新しいツールの導入やその利用で周りの理解が得られない！と感じている場合
少し胸に手を当てて周りの人間に対して不安を払拭することが可能なくらい学習コストを払ってきたか？、また払い続けれるか？を問いかけてください。

つまるところ自業自得だったわけなのですが、少々自分自身の今までの振る舞いに憤懣やる方ない思いを抱いたため
今後そのようなことがないように実践者となれるように継続的な努力をしていこうと思います。

結局ぼくは自身が嫌っていた意識高い系()のことを笑えなかったということですね。
文字通りボク自身が「意識だけが高い人間になってしまっていた」わけです、実に救いがない。
今後はタイトルにあるように同僚H氏のような意識の高い実行者になれるよう努力していきたい所存です。
凹むというよりも素晴らしい知見を得たという充実感と今までの自分を殴りたい怒りでいっぱいなのでそろそろ寝ます。

おやすみなさい。

ここでいう意識高い系()は意識の高いことを発言するがそれに向けて一切なにも行動を起こさない人として定義します。
一般的な意識高い系とはもしかしたらズレがあるかもしれませんのでご留意ください。

www.weblio.jp

ふむ、これを読む限りにおいてはそれほどズレがあるわけではなさそうですね。

追記(2015/12/13)

意識の高い実行者 - おうさまのみみはロバのみみ

考えて(主張して),手を動かす人が一番偉いのは同意;ただこのケースでH氏がツールの学習に個人の時間を使ったのなら馬鹿げてる.会社のメリットになると判断したら,勤務時間を使って著者に学習させる事もできたはず

2015/12/12 13:32

これなんですが実は色々条件がH氏とぼくの場合異なっていたんですね、だからそうなったという部分があります。
なのでその説明をしないと誤解が発生するかなと思いましたので追記します。

主な「異なる条件」

ツールの学習時間

  • H氏、前職で経験済み。
    • 運用も前職で行っていたので多少不足しているところはあるかもしれないが全体的な知識はある、ある程度学習済み。
  • ボク、色んなブログで見聞きしているだけで触ったことがほぼない。
    • 仮に着手していたら全て一から学ばないといけない。また運用も当然行っていないためどういう問題があるか見通せない。

提案タイミング

  • H氏、プロジェクトの拡充に伴い比較的人数増えたタイミングで転職してきてくれた
    • ある程度設定の更新や変更を行うスクリプトや管理画面の機能追加が行われていた。
  • ボク、プロジェクトの割りと早い段階からいる。提案したのはH氏が入るおよそ3ヶ月くらい前。
    • いろんな設定の変更を手動で行っていたためCIなどの大きな自動化の環境に着手するには余裕が足りてない感じ、もしくはようやく余裕が出始めた段階で提案していた。
      • むしろ手作業でやりたくないから提案したんだけどね！！！

プロジェクトの状態

  • H氏、いろいろみんなで頑張った結果チーム全員が設定周りの変更が行えるような状態になっていた
  • ボク、まだ担当者以外が設定を変更するのは時間がかかってしまっていた(経験していない、ドキュメントがないなどなど)

経験値の差

  • H氏、前述している通り前職で経験しているためチーム内で一番モダンな開発環境の経験値が高い。
  • ボク、勉強会や独学でVagrant試したり、git使ったり、技術系ブログに目を通していた。

プログラマとしての能力差

ついで。

  • H氏、有能。割りと行動力もあり、基本的な能力は過不足なく揃っている。
    • 有能な後輩が入ってきて嬉しいです。負けてられないけどな！
  • ボク、新しいものに対してやたら飛びつく割にはいまいち成果に結び付けられていない。また数学苦手だったりアルゴリズムが乏しかったり、基本はできるけど応用が出来ない典型的な駄目プログラマ

追記の結論

そもそも条件が全く同じになってはいスタート！みたいなことにはならないわけですが、
ボクの場合は諸々提案するタイミングなどがダメダメだったなぁという感じです。
なによりも学習コストの差が大きいですね、「前職でやってました！」と「やることが決まってから頑張って学習します！」じゃあ隔たりがひどい。

というわけで会社が悪かった点を敢えてあげるなら

H氏のサポート要員としてぼくをアサインしてくれなかったことですかね！！！

そうすればぼくはH氏から学習できるし、H氏はモダンな環境構築を行ったという成果を得られて双方ともに満足して終われたのにな。
(H氏が教えるコストはこの際ぼくの都合上考えないこととする)