Tbpgr Blog

Employee Experience Engineer tbpgr(てぃーびー) のブログ

新訳『エクストリームプログラミング』を機に eXtreme Programmingが私に与えた影響を振り返ってみる

f:id:tbpg:20150803034502j:plain

新訳『エクストリームプログラミング』を機に eXtreme Programmingが私に与えた影響を
エンジニア人生全体で振り返ってみます。

2001年新卒入社

新卒で受託開発の会社に就職。

この会社での仕事はほとんどが2次請けでしたが、基本的に自社のオフィスで同じ会社の同僚と開発できたので
後に勤めることになるSI'erの下請けとして派遣(多重請負)されるタイプの会社に比べるとかなり恵まれた環境だったと思います。
「残業時間」を除けばね。

XPとの出会い

新卒で勤めた会社では、各新入社員に一人ずつ先輩がついてくれます。いわゆるメンターですね。
この時、私の担当をしてくださった先輩が社内で最も技術に対する熱意のある方で、
社内勉強会を主催していました。
残業地獄で勉強会は即活動停止になりましたけどね。

さておき、この経緯で

旧訳「XPエクストリーム・プログラミング入門―ソフトウェア開発の究極の手法

と出会うことになりました。

この時勤めていた会社はウォーターフォール型の開発手法で納期までに死に物狂いで納品水準をぎりぎりで実現。
保守性?何それ?的な感じですし、そもそも標準的な開発構成がIIS+ASP+VBScriptのWebシステムだったので、
保守しやすく作ろうにもかなり厳しいものがあります。
(JavaJSPRubyのerbに全てのロジックが書かれたシステムを想像してみてください)

XPと現実との差。
XPに書かれているような現場を作りたい、働きたいという思いが広がりはじめていました。 そして色々学習したい、という思いはあったものの残業が多すぎて時間的な余力がないまま2年で体を壊し、
このままここにいたら死ぬ、と思い退社することに。

※以降も含め全般的にダメな文脈でウォーターフォールがでてきますが、手法自体の批判ではなく
たまたま私が経験したダメなケースがウォーターフォールの現場だった、という話です。

苦し紛れのつけ

体を壊したことで、中途半端な経歴・経験値で計画性がないまま転職することになり、まともな転職ができず。
(もちろんこの時点の実力不足もある)
結局多重請負のかなり底辺のJava案件をこなす会社へ。
自己ベストは7次請

とはいえIIS+ASP+VBScriptに比べれば、Javaの開発自体はとても楽しかった。

この時は案件によって忙しさに波があり、多少学習出来る時期もあった。
そこで、XPのプラクティスの一部である自動テストなどを自発的に学習し、
参画したプロジェクトで提案・導入をしたりしていた。
このことは、XPがきっかけであり、こういった提案などの実績は
後のキャリアにおいて大きく役にたっている。

この時もウォーターフォール型の受託開発でJavaのコードとExcel方眼紙の
メンテナンスが主な職務。現場を大きく変える裁量もなく、
XPのプラクティスの多くはまだまだ自分にとって非現実的な世界でした。

そして、結局転職後も激務が続きシステム開発の仕事を離れることを決意。

のんびり

事務仕事やちょっとしたホームページ管理の仕事などで、しばらくはのんびり過ごす。
しかし、少しずつ募っていく仕事への物足りなさ。
結局、システム開発の仕事に戻ることに。

システム開発の現場に再び

派遣スタイルで痛い目を見ていた私は、自社開発ができる会社を探しました。
ブランクがあるということで、転職は難航しましたがようやく自社でサービス開発をしている会社に入社。

しかし、出社初日の前日に「ちょっと、緊急で手伝ってもらいたい案件があるからこの会社で面接を受けてきて」と言われる。
で、次の日からその面接を受けた会社で勤務することに。そういえば面接するのってry いや、そもそもまだ入社していない日に面接にry 久々にシステム開発に復帰してみて、開発を楽しさを改めて確認できました。
そのため、この時も新卒の時と同様かそれ以上の激務だったのですが、限られた時間での学習は欠かさないようになりました。

変わらない世界

システム開発への復帰は30歳を過ぎていたため、
「久しぶりのシステム開発の現場はXPの中のような世界になっているのだろう。」
「楽しそう。」
「ついていけるかな?」
など期待と不安を募らせていました。

しかし、蓋を開けてみると若い頃に勤めたJavaの多重派遣と変わらない世界がそこにありました。
ただ、当時と違うのは私自身のモチベーションです。
自動テスト、リファクタリングテスト駆動開発など個人でできるプラクティスは導入し、
少しずつ裁量を得るにつれ、その影響範囲を広げていきました。

転機

とはいえ、まだまだ制約の方が多く開発内容はXP、アジャイルの世界とは程遠いものです。
同僚も「Martin Fowler? 何それおいしいの?」という反応の人ばかりです。
そして再び残業地獄でボロボロになり、開発チームのリーダーとして1日中大量のメールとBTSの課題を
ぽちぽちするだけの日々に嫌気がさしていました。
開発を離れたくないものの、ある程度実力を認められてくると開発から引き剥がされてしまうジレンマもありました。

ぼそっと「Railsの開発ができる現場に転職したいな」とTwitterで呟いた所、
1ヶ月半後に転職することになりました。
ちなみに在職中2つの現場に派遣されていましたが、入社の前提であったはずの自社開発は1回もしませんでした

現在

現在、個人に裁量があり新技術や改善の導入に積極的な会社に所属しています。
開発スタイルもアジャイル風(正式なプラクティスなどを実践しているわけではないので「風」)です。
長年夢見ていた「書籍エクストリームプログラミングに書いてあったような開発組織」で仕事をする機会を得ました。
実際に経験してみると、とにかく開発が楽しいですし、過去の職場で経験してきた

何かしら解決すべき問題があって、解決方法も分かっているのに制約・政治・不理解などにより解決させてもらえない

というような悩みがほとんどなくなりました。
もちろん全てが順風満帆ではないですが、非合理なことに時間を割く機会は以前の職場に比べて相当減りました。
しかも定時勤務。スコープを調整できる環境なのです。

週に1回クリエイターズネクスト社に勤務することで、複数の現場のノウハウを習得できる、という貴重な経験もしています。
クリエイターズネクスト社は社長が技術者ではありませんが、
エンジニアの提案を積極的に採用する「アジャイル」な組織です。
以下の記事などで、その社風が伝わりやすいかと思います。

cnxt.jp

XPの世界を実現できる環境を一度に2つも手に入れてしまいました。

まとめ

過去を振り返り、この記事にまとめることでXPへの憧れや個別のプラクティスの学習・実践は、
私が最終的に今の環境を得るまでの長い道のりの起点として大きく役立って来たことを再確認できました。

また、最近技術者がアジャイルな開発を行っているWeb系の開発現場に流れていく傾向が強いようですが、
そういったアジャイルな開発現場に対してエクストリームプログラミンがこの15年で与えた影響は
大きいのでは、と思います。今快適な環境にいる若者も、実はXPの恩恵を得ているのでしょう。

関連書籍

XPエクストリーム・プログラミング入門―変化を受け入れる

XPエクストリーム・プログラミング入門―変化を受け入れる

  • 作者: ケントベック,Kent Beck,長瀬嘉秀,テクノロジックアート
  • 出版社/メーカー: ピアソンエデュケーション
  • 発売日: 2005/12
  • メディア: 単行本
  • 購入: 3人 クリック: 55回
  • この商品を含むブログ (70件) を見る

エクストリームプログラミング

エクストリームプログラミング