書評:レガシーソフトウェア改善ガイド

Kindle版、Amazonポイント50%還元キャンペーン中に、技術書を大量買いしたときの1冊。
ずいぶん前に読み終えたけど、久しぶりにパラパラ眺めながら何が書いてあったか纏めておきます。

誰向け?

* 日々レガシーシステムと格闘していて何とかしたい人
* 新しい技術に興味がある人
* 何か新しいことを学びたいけど、何が良いか判らない人
* 新しい技術を仕事で使いたい人(レガシーシステム関係なく)
* 保守中のシステムに対して改善提案したい人

レガシーシステムを改善するためのガイド本なんじゃないの?
と思われるかもしれませんが、
私が読んだ感想としては、私の中では新しい技術を使うプラクティス本的な位置づけです。

向かない人は?

本書に興味がない人
※勉強熱心な全てのエンジニアに読んでもらいたいです

どんなことが書いてあった?

中途の人が新しい職場に転職して、出社初日に開発環境の構築に四苦八苦したり、
良かれと思って直したコードが、他のところに影響してしまったとか、
システムのリライトしたら、過去のバグを再発させたとか、
そんな、保守案件・保守開発のあるある話に対する改善方法を提示してくれています。

ツール類は?

DevOps界隈で言われているツールが殆どです。

これ見てる人にとっては、当たり前に使っているもの・特に使ってないけど、どんなものかは知っている、というものが殆どです。

新しいモノの使い方について

「とにかく一気にやり過ぎない。何かを始めるのは1つまで。」

これは新しく何かを作るときも同様で、新しいことをやったら大抵の場合地雷を踏んでプチ炎上状態の中、問題をクリアしていくことになります。
これは成長するために必要な失敗と成長を体験するために必要な儀式なので、問題ないです。
ただ、新しいことを複数行うとプチ炎上が重なり、大炎上する可能性が、まぁ指数関数的に上がります。
なので、保守・新規に関係なく、新しいことを始める場合は、1案件1つまでにしましょう。

という、納得のことが書いてありました。

私も、新しいことは1案件1つまでと決めてやってます。
もちろん、すんなりことが運んで、もう1個くらいイケたな!と思うことはありましたが、
嵌れば1週間くらいは簡単に溶けるので、2個以上は手に余るので、上手くいった次も1個しか新しいことはしません。

ただ例外もあります。
自分にとっては新しいことでも、熟練者がいるときです。
多くの組織では、熟練者にその部分を担当してもらうと思いますが、これは自分でぶんどれます。
で、自分の判る領域を別の人に回す。
誰かがプチ炎上状態になっても、その領域の熟練者がいるので即鎮火できるので、ほぼノーリスクで新しいモノのノウハウが溜まりますし、
プロジェクトメンバー間で共有すれば、自分がやってない部分のノウハウも身に付きます。(実際には自分で手を動かさないと厳しいと思いますが、あの人ここでハマってこう解決した、というのを聞いていれば解法を導くのが時短できます)

リファクタリングの仕方について

テストを書きましょう!といういつものヤツが書かれています。
新規開発では、まぁ書きましょう!となりますが、テストコードがないレガシーシステムはどういうアプローチでやるの?
ということが丁寧に書かれています。
レガシーシステムについては、有りものを正義とみなして、仕様化テストを書くと良いよ!ということが書かれています。
この辺はちょっと前にテストコードを書いてこなかった人向けに資料作って発表しているので、参照頂ければ。

www.slideshare.net

 

あまり触れられないコストについて(追記分)

絶対に書こうと思って書き忘れたので追記します。
日々の生産性やリリースまでのリードタイムなどはよく取り上げられますが、
人の受け入れコストについて触れているのが本書の特徴です。
特に開発環境の構築は、無駄コストとして扱っています。
確かに、新しいプロジェクトに入ると1〜2日、酷いと3日は開発環境を構築している人、居ますもんね。
一人なら良いですが、人の出入りが激しいと、この工数はバカになりません。

その解決手法はVagrantやDockerを使って開発環境を自動で構築して手間を省こうというものです。

また、新しい人を受け入れて、どの程度で周りと同じ程度の生産性になるかについても言及しています。

最後に

なんやかんやと色々理想が書かれていますが、作者も言っている通りで、
やれること、やれそうなことを無理のない範囲で行っていけば気付いたら脱レガシーになっているだろうし、エンジニアとして色々知見も溜まって良いですね。
私も立ち止まらないように色々チャレンジしていかねば!

レガシーソフトウェア改善ガイド (Object Oriented Selection) | クリス・バーチャル, 吉川 邦夫 |本 | 通販 | Amazon

書評:エラスティックリーダーシップ ―自己組織化チームの育て方

タイトル的に気になっていた本書。

住んでる近くの図書館に本を返しに行ったら、新書の棚に置いてあったので借りて読んでみました。

最近の図書館って発売したての本も置いてあるんですね〜。

新書過ぎてびっくりしました!

読んでみた感想としては、

「手元に置いてたまに読み返したいかな〜」

という良書です!

 

# 誰向け?

以下の人々に読んで欲しいかな

* 人の成長に興味があると、口だけは言っているマネジメント

*人の成長に興味があると、口だけは言っているプロジェクトリーダー

* チームリーダー or その予備軍

 

割と過激な書き方をしましたが、本気で人の成長を望んでいる人は行動で出来てる(自分自身やってもらった)ので、

口だけ、と書いてしまいましたが、どうやったら良いのか分からない人たちに読んで欲しいですね。

チームリーダーとその予備軍は、是非読んで実践してみて欲しいです。

 

 

# 向かない人は?

* リーダー層ではない人たち

今読むと、理想とのギャップで現職が嫌になるかもしれないので。

ただ、プライムでやってる人たちは、社内政治的な世界で殴って勝ち取れるかもしれない理想なので、読んだ方が良いかも。

 

# どんなことが書いてあった?

チームの状態を

* サバイバルモード : 自分の仕事でいっぱいいっぱい状態

* 学習モード : 学習しながら仕事に取り組める余裕ありな状態

* 自己組織化モード : 端的に言うと、YWT(やったこと・わかったこと・次やること)を自主的にやるような状態

 

各モードの関係と、何が起きると他のモードに遷移してしまうのか、
各モードでどんなリーダーシップを取ると良いのかと言ったことが書いてありました。

リーダーも自分のマネジメントスタイルをメンバーに押し付けるのではなく、
自分のチームの状態がどのモードに居るのかによって、変わっていくことが重要とのことで、これは確かにそうだし、自分自身全く出来てなかったかな〜と自省してます。

リーダーとしては、当然サバイバルモードは避け、
学習モードから自己組織化モードを目指すべき時代のようです。確かにそう思います。
たまに、あのリーダー何もしてくれないけど、プロジェクトは順調なんだよ、あのリーダー要らなくね?
と言う場面があると思いますが、それはリーダーが上手いことバランスを取ってくれていて、チームが自己組織化モードに居るという可能性が高いので、
間違っても「あのリーダーが不要」と言うのは辞めましょうw

平和なのには訳がちゃんとあるのです。

脱線しましたが、上記のモードを懇切丁寧に解説してあります。

だいたいここまでで、本書の半分程度。

残りの半分は、じゃあ何すれば良い?というのが延々と書いてあります。
これはこれで面白いですし、実際にやるときには、どういうこと気にしなきゃいけないんだっけ?というのを読み返してからやろうと思えます。

 

# 最後に

自分自身うまく出来てなかった部分も多いので、しっかり自戒して取り組みたいと思います。

あと、この本は買おうと思います。手元に欲しいw

 

ちなみに今のチームの状態は「学習フェーズ」です。

自己組織化フェーズは、多分会社としてそういう文化がまだないかな〜と言う状態ですね。

サービスを提供する会社なので、会社が潰れそうにならない限りは、サバイバルフェーズに移行することはないだろうけど、そうならないように意識だけはしとこ。

 

www.amazon.co.jp

 

バイザーに入社して2ヶ月経った

2017/4末で大手SIerを退職し、5/1からバイザー株式会社という俗に云うWeb系にクラスチェンジしました。

 

で、2ヶ月経ったので、どんな感じか書いてみます。

ちなみに試用期間3ヶ月なので、もう1月は試用人ですw

 

# バイザーってどんな会社?

自治体に向けて情報を発信するためのサービスを開発している会社です。

すぐメールというのが主力サービスで、自分の生まれ故郷の某所にも導入されていたりと、多分知らず知らずのうちに使っている人、めっちゃ多いと思います。

 

# なんで入ったの?

これから色々やっていきたいということで、話していて貢献できそうなことが多いと感じたためです。

Web系の企業だとスタートアップ時やよほど大きい会社でもない限りは、基本的にリリース済みのサービスの保守とエンハンスがメインになるようですが、

運良く転換期に出会え、バリバリコード書ける&フットワーク軽そう&面白そうなサービス持ってる&名古屋でサービス開発できるの超貴重!っていうので、選びました。

 

# 入ってどう?

入社前と後で特にギャップもなく楽しく働けています。

時間の使い方は前職とあまり変わらない感じで、

プロダクト開発8:情報収集2程度の比率を確保できています。

前職の時は情報収集しても開示する先がなかったですが、

現職では Slackを使っているので、面白かったもの・今後役に立ちそうなモノなど、

コメント入れてSlackに投下してます。

それを見て反応を貰える&どんどんやって欲しいと言われているので、どんどんやっている状態ですw

 

スキル的には、はじめの2〜3週間くらいはPHP + Laravelという初物部分で多少戸惑いましたが、最近は癖もだいぶ掴んできたので、スラスラ書けるようになってきたかなと思います。

 

あと、開発するPC環境はめっちゃ快適です。

多分Web系だと普通のレベルなのかもしれませんが、前職と比較すると天と地ほどの差があります。

 

# クラスチェンジするに当たって不安はなかった?

プログラミング言語は方言だ!と言える程度のスキルは持ち合わせているので、あまり不安はなかったです。

初日全社員の前で挨拶しろと言われていたので、スベらない自己紹介についての不安はありましたが・・・w

 

# 今後は?

お互いにミスマッチな部分も特になく、長く働いて事業・人員育成に貢献できれば!と思っています。

エンジニア10年振り返り

はじめに

社会人歴が10年となったので、

今まで何を大切に生きてきたかを書いてみます。

今の会社は4末で辞めるので、若い人たちの参考になれば。

軽く自己紹介

プライムベンダーのアプリケーションアーキテクトってことになっているそうです。
 

自称はプログラマーですが、

経歴を振り返ると、

プログラマー兼アーキ兼DBA、つまりなんでも屋です。

最近インフラ周りを見ることも増えました。

目標は全領域制覇なので、未経験分野は特にウェルカムです。

(でも、未経験分野をやる時は、内心不安でいっぱいで吐きそうにはなってます)

1〜5年目

客先常駐してた時で、

むちゃくちゃ働いて、むちゃくちゃ飲んでた時代。

仕事自体は、とある生活インフラの遠隔監視制御システムのリライトしながら、

たまに保全活動の支援したり、みたいな感じでした。

この時は、経験・未経験に依らず、振られた仕事は何でも受けてました。

仕事を受けすぎて怒られたこともあるくらいに・・・。

知らないからこそ、やってみよう!というポジティブさで生きてました。

あれこれ何でもやってたので、この時の経験は財産になっているのではないかと思います。

何でもやってみないと課題も見えてこないぞ、と。

あと、俗に云うデスマーチも経験したので、

プロジェクト運営のバッドノウハウとか、

炎上した時に出てきた責任者の動き方など、色々学ばさせてもらいました。

デスマーチは若い時に経験すると、得られるものが大きいので当たったらラッキーです。(給料も笑うくらいもらえる)

※心が病みそうな場合は、我慢しないで逃げましょう

6〜8年目

自社持ち帰り一括案件やら、他PJの火消し的な感じで、

開発プロジェクトの数をこなしまくってた時代。

基本的に社内常駐でノウハウも社内に全部残せるってことで、

客先常駐ってエンジニアとして良いこと何もないってことで嫌いに。

方式から内部仕様など、決定権があるのでやりたいようにできたのは、

プライムベンダーの旨味。

これを活かして、1案件で1つ新しい事をやるってのをずっとやってました。

1つなら無理なく(?)できるのでオススメです。

というか将来困りたくないなら、やりましょう!とオススメしたい。

流行りに乗る、勿論OKですが、それをやる事で何が嬉しいのかを考えてやるのが良いですね。

僕の場合は、自分のところに何でも来るので、

自分が楽できて工数が浮く、っていうのが判断材料でした。

言い方が悪いですが、バカでもできる方法を取り入れるわけです。

次の案件では、前にやった新しいことの恩恵で、工数が浮くので、

また新しいことができるっていう良いスパイラルが生まれるわけです。

役職周りには言わないでこういうことをやるので、

後でばれて怒られたこともありますが。

まぁちゃんと動かせているからっていうので、強くは言われないし、

こいつはこういうやつって感じで最終的には収まりましたね。

ただ、動かせるところまで行けなさそうだったら引く勇気も必要で、

こういうのは目標利益の下限を下回らないようにやることが重要なので、

そこだけはお気をつけを。

ちなみに、僕主導の案件は利益率30%くらい常にあったので、

周りからはボッてると思われることが多かったですが、こういう努力の賜物です。

9〜10年目

東京にさようならをして、名古屋に来た時代。(現在進行形)

そしてまた客先常駐に。。

純粋にプログラマーやってたと思います。

勿論、提案時とか相談は受けましたが、日々のプロジェクトに対して裁量が・・・ない。
 

そんなこんなで、いろいろな要因が相まって10年働いた会社を去ることに。

11年目(5月)からは名古屋で自社サービスやってる会社にお世話になるので、

そっちで頑張ります。

今いる会社の若者に伝えたいこと

スペシャリストになる必要はないけど、

技術系のものにアンテナ1本くらいは立てといた方が良いよ。

トップダウンとか、客先都合でいきなり新しいもの使うことになると、困るわけだから。

(実際、フリーズしているのが何人か・・・)

僕は去りますが応援はしているので、頑張ってください。