この記事は何らかのノウハウを伝えたり、知識を共有するものではありません。単に私の経験を無秩序に羅列しただけのものです。「ふーん」と思ってもらえれば十分です。

経緯

6年間勤めた某ISPを辞め、2016年4月から某人材会社の社内ベンチャーのスクラムマスターとして働いています。役割はチームリーダー（スクラムマスター）で、業務内容は既存システムの保守運用、エンハンス、品質向上です。

気付いたこと

仕事が終わらないので、必然的に取捨選択を迫られる

既存システムというのがまあ酷い品質でして、毎日のように障害が発生します。その原因も様々で、パッと思いつくだけで以下のようなものがあります。

• バグ修正がバグを生む
• 運用チームのオペミス
• 営業と顧客間の伝達ミス
• 脆弱なオンプレ環境のリソース逼迫
• まったく原因不明（結構起きる）

安定稼働のためにはコードの修正や運用改善を進めねばなりませんが、割り込みは絶えず発生します。最終的にどうすれば最も早く安定稼働にたどり着けるかを常に考えねばならないので、優先度付けと取捨選択の能力が非常に鍛えられました。

スクラムは教科書通りで機能する

時間が無いと、弱いスクラムマスターは各種イベントを省略してしまいがちです。が、スクラムのイベントはよく考えられており、どれも削らずに律儀に開催した方が良い結果に繋がることが実感できました。

例えばふりかえり（レトロスペクティブ）は、問題を生んでいるプロセス自体にフォーカスし、対応策を考える時間を与えてくれます。また、バックログリファインメントは、やるべきタスクのゴール（完了の定義）を明確化するので、障害など割り込みが入った場合でも道を見失わずに、確実にタスクを達成することができます。

1週間に渡って障害が発生しているような時でも、緊急度が低い（＝顧客影響が無い）ならこれらのイベントを正しく実施するべきです。

連続稼動は効率を下げる

忙しいからといって休み無しに3,4時間も働くと、午後になるにつれ生産効率はどんどん下がっていきます。これは人間の性質上どうしようもないことです。「顧客が迷惑してるんだ、1分でも早く直せ」という周囲の声に引きづられて、思考能力の落ちた頭で延々と作業しても、ろくな結果になりません。実際、前任者はよく障害対応で別の障害を生んでいました。

当然のことですが、生物は休み休み体力を回復しないと、動けなくなります。ガッツ主義や、近視眼的な「顧客主義」にペースを惑わされてはいけません。

基本に忠実に、カンバンなどのツールで進捗を可視化し、途中途中で進捗をセーブしながら、最高のパフォーマンスを発揮できるペースで働くべきです。幸い今の職場はそうした働き方に理解があるので楽です。

改善は技術力を鍛える

「こんなクソプロダクトに関わっても成長できない！」と言って、仕事や組織を呪っているエンジニアをよく見かけますが、それは浅はかです。クソプロダクトはスキル次第で改善できます。また、改善をすることでスキルが鍛えられます。

例えばデグレが頻発するシステムなら、自動テストを作ってリファクタリングすることで対処できますし、それによって設計能力や疎結合の考え方が向上します。私自身、某オープンソースECパッケージのクソコードを上述のように対処することで、オブジェクト指向とテスト駆動開発をマスターしました。ついでにアンガーコントロール（怒りの感情制御）もできるようになりました。（最初は意味不明なロジックを読んでは毎日のようにキレていました）

もちろん、エンジニアへの支援が一切無く、改善のリソースも与えられないような組織に属しているなら、脱出した方がいいと思いますが…。

新技術に貪欲なのが良いエンジニアではない

「新しい技術を使いこなせる＝イケてるエンジニア」という価値観が世間では一般的ですが、それだけがエンジニアではありません。私はビジネスに貢献できるエンジニアこそ価値があると考えています。

品質を作り込んで安定稼働を実現すれば、プロダクトの品質をセールスの武器にできます。業務効率化を成し遂げれば、空いた時間で新たな価値創造ができます。地道なパフォーマンスチューニングによって、顧客満足度を高められます。

新技術を広く浅く触ってばかりで、全然プロダクトに生かせないエンジニアを少なからず見かけますが、それは単なる「新しもの好き」で、「良いエンジニア」とは言えません。