bon now

今回は僕が社会人になって10年ちょっとの間に行ってきたいわゆる技術的施策みたいなのについて思ってることを取り上げる。
技術的施策っていうのは、ある問題や課題が組織ないしは既存システムや業務フローに存在するとき、それをITテクノロジーを使って解決するという施策のことである。 例を上げるとExcel方眼紙にマトリクス表作って単体テストの組み合わせを列挙し手作業で単体テストするみたいな、 SIあるあるな面倒なうえに人的ミスの起きやすい部分をExcelマクロやSeleniumを使って自動化するみたいなものである。

本題を述べるのと同時に僕の職務経歴を軽く紹介しないとお前みたいなわけわからんやつが何言ってんの？と多分なると思うので、今回はそこもちょっと触れてみることにする。

1社目 大手SI孫でやった技術的施策

パフォーマンス改善

入社してなんやかんやありリーマン・ショック後の予算削減の煽りを受け、比較的潤ってるちょっとした改修が途切れることなく発生する保守系のプロジェクトに突っ込まれた。 当時の僕は尖ってたトコもありSIなんてクソだ5年で辞めてやる！みたいなことを比較的広く公言してたので、地味な保守作業なんてやる気がなかった。 そのため、過去の設計書や要件定義などのいろいろな財産とノウハウを知る絶好の機会があったにもかかわらず、あろうことかほとんどの時間を自学に費やした。 このときに一番学んでたのがRuby On Rails(以下Rails)だった。当時はRails3が出始めで、Scaffoldすごいよーみたいな盛り上がりをみせてた時分だった気がする。
もちろん今となっては真面目に業務に取り組んでない自分をぶっ叩いてやりたくもなるが、良くも悪くもここは僕のターニングポイントだったなというところもある。

その後僕のやる気の無さがだいぶ問題視されたというかキャリア的にマネジャーはやめたいと課長になかば強制的にお願いしたところ、 自社製品を開発するプロジェクトに移ることになった。 そこではJavaEE(JBoss / JBoss Seam)を使ってたんで、必然的にJavaEEに明るくなっていった。

ここで僕がやったのは、なんか遅いリクエストのレスポンスを速くするというものだった。

例えばデータの一覧表示。まずSQLを見直して30秒くらいかかってたのを10秒くらいにした。更に非同期処理を取り入れて5秒にした。
他にはCSVエクスポート処理もSQLにFetch(1万件で分割取得する)処理とStream処理つかうようにし、さらにSQLに頼ってたところをHashMap使ってメモリでなんとかするようにすることで数分の処理を10秒程度まで縮めた。 この施策は今考えても合理的だなと思ってて、HashMapはメモリを都度確保しちゃうので大量データの場合そのデータがすべてメモリ確保されることになるが、 FetchやStream処理をいっしょに組むことで、たかだか1万件のデータ分しか確保しなくて良くなったわけだ。 もちろんこれに対する検証としてもJMeterで負荷試験しつつ、JVMのヒープとGCを jstat + GCViewerでみながら問題無いことを確認した。自分でもよくやったなと思う。 JMeterはシナリオのテンプレートを作って別プロジェクトに活用してもらったり、Javaだと当時のRichFacesがIE10対応できてないためにjarをいじったりそれを別プロジェクトでも使ってもらったり、他部署からSpringがわからんと聞かれたので採用する際の準備物をマニュアル化したり、まぁ自分のためだけでなく色んなとこに恩を売った。 ビジネススキルとしてはマイナス面も大きかったけど、それを奉仕の心で補っていたと思う。

シニアエンジニアでも使える自動テスト基盤

リーダークラスのおっさんたちのほとんどは現代風のOOPなんて触ることができず、代わりに神Excelの魔力に取り憑かれてしまった人たちが大半だったため、 単体テストや結合テストもすべてExcelにて記載されるのが当たり前だった。 僕は集中力があまり持続しない人間なので、さっきやったテストケースをもっかいやったり、 さっきやったテストケースに「OK」つけたと思ったら前のテストケースを上書きしてたり、もはや正しいテストをやってるという自覚すら持てなかった。 そんな感じなのでたまに「検証してるのにエラーになる」っていう不具合が起票される。まぁ僕が悪いんだけど、Excelの小さな方眼紙を眺め続ける苦痛もある。 それにテストケースをExcelに書き起こすという作業自体もまあまあの無駄を含む作業ではないだろうか。 だったらこのExcelに書いたテスト項目を、そのままコンピュータが読み取ってくれて自動的にテストしてくれたら誰も損しないじゃないかという発想で、 当時技術統括チームみたいなところの人と組んでクラウド基盤のSeleniumテストシステムを作った。

このシステムの裏側はRailsにCucmberとCapybaraとSeleniumを使っていて、Excelに以下のような入力をしたらそれ通りにテストしてくれるというものだ。

1
2
3
4
5
id, login  
入力, admin  
id, password  
入力, password  
操作, クリック, submit  

この例ではHTML要素でidがloginのものにadminと入力し、id=passwordのところにpasswordと入力したあとsubmitボタンを押すという流れになる。 まあまあ汎用的にも作れたし、当時のIT情勢としてIE8,9,10,11のクロスチェックとかもやらざるを得ない場面も多々あったので、 こいつがまともに使われたらかなりの生産性向上がみこまれたはずだった。

僕はこれを作り上げてすぐくらいに会社を退職してしまったのでその後はわからないが、伝え聞くところによると存在すら抹消されているらしい。 これこそがこの会社でのオーパーツだっただろうなと今は思う。これについては後で説明する。

2社目 自社製品独立系でやった技術的施策

CI環境の構築

現職に転職を決めたのは1社目でRailsやって面白かったのと、自社製品触ってるほうが性に合ってると思ったからだ。 他のありきたりな理由だと典型的なSIなためにExcel神を信望するマネジメント職にならざるを得なくなってきて、それをやるくらいなら流行りだしたアジャイルなりなんなりで、 もっと自由にプロジェクトに関われて裁量持てる会社で仕事してみようと思ったのもある。

そうやって現職では幸先よくバックエンドエンジニアとしてキャリアをスタートしたものの、 怠け癖のついてた僕はよくサボっては怒られつつ、今までのスピード感との違いと品質保証に対するエンジニアの意識とのギャップに心底驚いたことは今も覚えている。

この会社ではテストコードを書いていなかった。カバレッジ率とか網羅率を定量的に評価しないと次のフェーズに進めなかった前職とは全く違った。 いい意味でも悪い意味でも品質はエンジニアとQAの腕にかかっているため、属人的かつ客観的な品質評価を誰もできないという状況だった。
そんなわけで現職でリーダーになってからというもの「テスト書けよテスト書けよ」と言い続けて2年くらいでテストコードを書かないとプルリクエストが通らない状況をつくることができた。その流れでCIを取り入れた。

CIといっても企業や組織によってその規模の程度がバラバラだと思うので補足すると、僕が作ったCIは2つ。 1つはBitbucket Pipelineを使ってRailsのテストツールであるRspecを自動的に回すというもの。
もう1つはTeamCityというJetBrains社製のオンプレCIツールを使い、自社の仮想サーバーに用意したKubernetesにデプロイするというものだ。

前者は組織の中では健康食品になり、プロダクトもエンジニアもどちらも健康になった。 僕がコピペで書いてたYAMLをメンテナンスしてライブラリインストール時のキャッシュが効くように変えてもらったり、 RubocopというRubyの静的解析ツールも組み込んでもらったりとどんどん進化している。とても良いことである。
問題は後者だ。メルカリの@deeeet氏が開発者向けの基盤をつくるというものを公開してるが、 僕がやったこともほぼこれで、この小難しいKubernetesとかTeamCityとかのCI/CD基盤はそれなりのインフラ知識とコンテナ開発知識が必要になるため学習コストが異常に高い。 そのせいもあってかあまり使われてない。笑えない冗談だけど、僕以外からみればこの環境はほぼオーパーツなのだ。 また別の理由として、この開発環境と並行稼動している既存の開発環境のほうが長く使われたこともあり、 エンジニアにも馴染み深く楽だからというのも使われてない要因の1つだとは思う。

社内改革は難しい

長く書いたとおり、僕個人的には顧客に打つ施策のほうが社内のそれよりも成功する確率が高いということだ。 僕なりの反省点を述べるとすると、顧客に対してはSEあるいはエンジニアとして正しく彼らの問題に向き合った結果いい感じに解決策を提供することができたのに対し、 社内に対しては多分理想と現実とのギャップを意識せずに今わかっている限りの最新の技術と知識を以て解決策を推し進めてしまった点だ。
結局僕は「こうあったらいいな」をそのまま実現してしまったに過ぎない。そこには他のメンバーの気持ちと理解が追いついていないのである。

唯一社内改革で成功したテストコードを書く文化とそのためのCIは、実際は1年間という期間で少しずつ浸透していった結果である。 タイトルに出てる「健康食品」というのも、要は即効性のあるものではない。地球の自然を作るのも1年や2年じゃなく数十年の時間を考慮しなければならないように、 社内で発生した病気や雰囲気--多くの場合これを文化という-- は、いきなり変わるなんてことはほぼない。 特に社内の技術レベルはより顕著に文化に影響されると思ってて、最初から開発環境は依存の少ない仮想化が当たり前の文化のエンジニア組織なら、 チョット昔ならVMやVagrant、今ならDockerやMinikubeあたりをローカル環境で動かしているだろう。 テストを書く文化が当たり前のようにあるのであれば、TDDにも取り組むだろうしリグレッションテストもやるだろう。 そんな文化的な側面を無視して突然の飛躍を遂げるなんてのはダーウィンもびっくりな進化を促してるわけである。

つまるところ行き過ぎた社内改革、技術の取り込み、仕組みの作成はオーパーツを作ってることと同義であり、興味のある人や触れる人がいなくなれば誰も手を付けなくなる。 これを避けるには2人目のフォロワーが必要になる。(参考先はTED)

2人目(後継者)を作って組織の健康状態を管理する

リーダーならば技術の進化とともに組織ないしは人の進化を促さなければならない。 つまりリーダーの行動をあとからフォローする2人目のメンバーを育成するということだ。
僕らの開発はすぐ目の前の問題を解決しながらも、数年先の未来で価値のあるものが提供できることを意識しないといけない。 そういう意味では、今のリーダーが培った考え方や仕組みなど、それらが反映されたプロダクトとともに未来に受け継がれなければならない。 エンジニアは一種のアーティストではあるが、根本的に彼らと違うのは、今の世の中のエンジニアリングは1世代で終わるものではないという点である。 だいたいはチーム開発しているし、だいたいは関わるエンジニアが代わる代わる現れては消えている現場がほとんどだと思う。 チームや組織で必要なのはそれらを健康に保つことである。そうすることで「なんかこれやると元気になれる」とみんなが思えば、 やってみようというモチベーションも湧く……はずである。 少なくともわけのわからん遊び道具を与えられて「これが最新技術や！」と言われるよりマシなのは確かだ。

健康は大事である。個人の健康、組織の健康、企業の健康。それぞれ体、生産性、経営という感じでそれを見るための指標は存在する。 ウェルビーイングとかSDGsとかそんな言葉じゃなく実感として捉え実践することが現場の人間には必要なことになる。

ということでみんなオーパーツよりも健康食品を作ろう。 オーパーツを作ってしまったら、それが健康につながるための努力をしよう。 文化的にそれが困難なのであればなくしてしまえばいい。無理をしたって健康は手に入らないのだから。