株式会社メルペイを退職します

2018年6月1日から働き始めた株式会社メルペイを9月30日付けで退職します。4年4か月勤務したことになります。1984年4月1日に社会人として富士ゼロックスで働き始めてから、7社目の会社でした。10月1日からは、新たな会社でソフトウェアエンジニアとして働き始めます。

週4日勤務

「ソラミツ株式会社を退職します」でも書きましたが、リコーを退職してからは、基本的に週4日勤務をしてきました。メルペイでも、金曜日は欠勤するか有給休暇を使うなどして、週4日勤務をしてきました（週4日勤務で働くことに関して、入社前に合意してもらっていました）。10月からの会社では、週4日勤務の雇用契約で働きます。

初めてのウェブサービス開発

富士ゼロックス、富士ゼロックス情報システム、リコーの3社で合計31年7か月を過ごし、富士ゼロックスでのワークショテーション開発を除くと、その多くは、デジタル複合機のソフトウェア開発に従事してました。ウェブサービス開発に従事するのは、（gRPCの経験は、前のソラミツで多少は経験していましたが）メルペイがほぼ最初と言ってもよい状態でした。

メルペイでは私が入社した時点で、すでにマイクロサービスをGo言語で開発していました。私自身は、Go 1がリリースされるより前の2010年夏からGo言語を学んでおり、メルペイへ入社した時点で、次の2冊のGo言語に関する翻訳本を出していました。

プログラミング言語Goフレーズブック

• 出版社/メーカー: ピアソン桐原
• 発売日: 2012/10/04
• メディア: 単行本（ソフトカバー）

プログラミング言語Go

• 出版社/メーカー: 丸善出版
• 発売日: 2021/07/13
• メディア: Kindle版

Go言語に関しては特に問題はなかったのですが、それ以外の使っている技術やサービスは初めて触れる物がほとんどでした。

最初に担当したマイクロサービス

最初に担当したマイクロサービスは、「加盟店様向けの管理画面」用のAPIマイクロサービスでした。管理画面の仕様に対して、バックエンドのAPIマイクロサービスがどのような機能を提供すれば仕様を実現できるかと検討しながら、マイクロサービスのAPI仕様を.protoファイルにコメントとして記述して、API仕様を策定する作業を2か月ほど行いました（「gRPCを用いたマイクロサービスのAPI仕様の記述」）。

最初の仕様が確定してから、マイクロサービスをどうやってテストするのかを検討しました。正直、ウェブサービスが初めてで、マイクロサービスも初めてでしたので、どのようにテストするのが標準的なのか全く知らない状態で、テスト方法を検討しました。

その結果、gRPCのエンドポイントを呼び出して、マイクロサービスの本番コードをほぼそのまま起動して、手元のMacBook Proでテストできるテストフレームワークを考案しました。正直、その時点で、メルペイ内の他のマイクロサービスがどのようにして、gRPCのエンドポイントを呼び出してテストしているのかはほとんど知りませんでした。

フレームワークの実装が終わったら、gRPCのエンドポイントを順にテストファーストで開発していきました。この時の経験をGDG Dev Fest Tokyo 2019で話をしました。その後、同じ話をいくつかのカンファレンスで話したのですが、最後は、Mercari Gearsとして動画（およびテキスト）にしてもらいました（merpay マイクロサービスの開発とテストファースト/テスト駆動開発）。

私が考案したマイクロサービスのテストフレームワークは、後に独立したリポジトリとして共通ライブラリとして私自身で整備し、現在では、採用しているマイクロサービスが増えています。

他のマイクロサービスチームへの異動

その後、いくつかのチームを異動して、2020年7月からは「メルペイスマート払い」に関連するマイクロサービスチームへ異動しました。このチームでは、私自身で何らかのビジネスロジックを実装することはほとんど行っていません。しかし、行った作業の中でも印象的なのは、「テストの安定化」です。

異動してきた時点で、そのマイクロサービスの自動テストは安定しておらず、かなりflakyなテスト群となっていました。テストを安定させるために、何が問題なのかを一つずつ調べて修正していきました。その際に、問題点を洗い出すための用いた手法が、「長時間ランニングテスト」です（「長時間ランニングテストの勧め 〜開発用ノートPCの活用〜」「（続）長時間ランニングテストの勧め 〜開発用ノートPCの活用〜」）。

長時間ランニングテストは、私自身にとっては、目新しい手法ではなく、2003年からずっと行ってきた手法です（「マルチスレッドプログラミングにおける重要な４要件」）。基本的に、この長時間ランニングテストは、ずっと続けてきました。

テストが安定化した後に、問題になったのは、テスト時間でした。そのため、t.Parallel()を呼び出したら並列に動作しないテストコードを一つずつ修正して、できる限り並列に実行するようにしました。そのときの知見をまとめたのが、「Go言語でのテストの並列化 〜t.Parallel()メソッドを理解する〜」です。

複業の継続

「複業を20年」に書いていますが、週4日勤務というのもあって、メルペイ在籍中も継続して行ってきました。

技術書の翻訳

翻訳本としては、以下の4冊を出版しました。

Effective Java 第3版

• 出版社/メーカー: 丸善出版
• 発売日: 2021/07/13
• メディア: Kindle版

新世代Javaプログラミングガイド[Java SE 10/11/12/13と言語拡張プロジェクト] (impress top gear)

• 出版社/メーカー: インプレス
• 発売日: 2020/03/13
• メディア: 単行本（ソフトカバー）

スーパーユーザーなら知っておくべきLinuxシステムの仕組み

• 出版社/メーカー: インプレス
• 発売日: 2022/03/08
• メディア: 単行本（ソフトカバー）

Go言語による分散サービス ―信頼性、拡張性、保守性の高いシステムの構築

• 出版社/メーカー: オライリージャパン
• 発売日: 2022/08/03
• メディア: 単行本（ソフトカバー）

技術教育

企業向けの技術教育としては、「Go言語研修」と「Java言語研修」を行ってきました。2020年2月まではオフラインの教育でしたが、それ以降は、オンラインの教育でした。オフラインの教育では、研修後に受講生の人達と懇親会をするのも楽しみでした。また、Go言語研修では、古川陽介さんや和田卓人さんも受講してくれました（「第6期、第7期のGo言語研修が終了しました」）

これから

これからもソフトウェアエンジニアとして働きながら、技術教育や技術書の翻訳、それにオンライン読書会（ブログのPC版で左上に一覧があります）も続けていきたいと思っています。

株式会社メルペイで働きます

一か月前に「ソラミツ株式会社を退職します」を書きました。その時点では6月からの勤務先は未定でしたが、6月1日から株式会社メルペイで「ソフトウェアエンジニア（Backend）」として働くことになりました。

通勤

勤務場所は六本木ヒルズです。今までよりも乗り換えが1回増えるために、通勤時間はおそらく片道で15分ぐらい長くなるのではないかと思います（往復で3時間を超える？）。朝は今まで通り、自宅の最寄り駅の始発（初電）に乗車して、各駅停車で行く予定です（「通勤電車の書斎化」）。フレックス勤務でコアタイムは12:00〜16:00なので、今までのように出社前にスターバックスに寄って翻訳などの作業をせずに、そのまま出社して早めに帰宅するつもりです。

7社目

1984年4月に富士ゼロックスに就職した頃には全く想像もしていませんでしたが、これで7社目となります。

• 富士ゼロックス
• 日本オラクル
• ジャストシステム
• 富士ゼロックス情報システム
• リコー
• ソラミツ
• メルペイ

定年まで 18か月 6年半

日本企業なので就業規則には定年があり60歳です。私は1959年11月生まれなので、18か月勤務すれば定年となります。
定年は65歳に改訂されていたので、6年半で定年です。

個人としての活動

リコーを退職したのを機に、ソラミツ社勤務時代に始めた個人として活動（金曜日に行う、企業への技術教育、講演、コンサルティング等）は、今後も引き続き行っていきます。

ソラミツ株式会社を退職します

2017年8月末に株式会社リコーを退職し、9月よりソラミツ株式会社に勤務してきましたが、2018年5月31日をもって退職します。ちょうど９か月勤務したことになります。退職理由については述べませんが、ちょっと変則的な働き方をしてきたので紹介します。

週4日勤務

ソラミツでは週4日勤務の契約で正社員として働いてきました。2000年の頃から執筆や翻訳などの副業は行ってきましたが、あくまでも週5日勤務しながら私的な時間に行ってきました。リコーを退職したのを機に、個人で技術教育・コンサルティング・講演などの副業を行うことを想定して、週4日勤務で週休3日（金、土、日）で雇用契約を結んで働いてきました。個人の活動とはいえ相手先は一般企業であり、週末とはいきませんので、金曜日を当てています。

金曜日はすべて予定が埋まっているわけではありませんが、ある程度は個人で活動できています（「Go言語研修実績」「講演予定・実績」）

部分的な在宅勤務

基本的な勤務時間は9:00〜18:00だったのですが、ソラミツの会津支社で一緒に開発している会津大学の学生と夕方の時間を合わせるという理由と、通勤で楽をしたい（座って帰る）という理由で、16:00に退社して18:00〜20:00まで自宅で作業するようにしてきました。朝は、電車を「書斎化」するために自宅の最寄り駅で始発（初電）（5時54分）に乗車して会社の最寄り駅まで行って、出社前にスターバックスで翻訳作業をして出社するパターンでした。

体調不良とか午前中の通院のために午後は自宅で開発業務を行うということも（公式ではないですが）できました。

会津出張

会津支社へは4回出張し、合計4週間弱でしたが、ソラミツで働いている（アルバイト）している会津大学の学生達と一緒に、会津若松市サテライトオフィスや会津支社で開発も行いました。

今後の予定

6月から働く次の会社は未定ですが、引き続き週4日勤務を続けられる会社を探す予定です。

株式会社リコーを退職します（2）

今日（2017年8月31日）がリコーへの最終出社日です。2009年9月1日にリコーへ入社してから、主に行ってきたことを簡単にまとめます。

【業務関連】所属した開発組織の業務として行ったものです。

• 技術教育：2010年に延べ500名以上のソフトウェアエンジニアに対して、「ソフトウェアエンジニアの心得」「テスト駆動開発」「C++」「API設計の基礎」などの教育を実施しました。しかし、「教育と場」でも書いたように、今から振り返ってみると、単に「教育をした」と「教育を受けた」ということだけが残り、私が教えた内容を実際の開発の現場で指導する人がいないため、開発組織としてのレベルアップにはならなかったと思います。
  
  
• Jenkins導入：2010年10月から行ったものです。当時デジタル複合機内で動作するJavaの開発環境やインテグレーション環境は、私の視点からはあまりにもお粗末でした。それで、FXIS時代に一緒に仕事をした派遣会社のエンジニアに来てもらい、二人で二ヶ月で一新しました。ソースコントロールシステムをCVSからSubversionへ移行し、それまですべて手作業で行われていたビルドをすべて自動で行えるようにしました。さらに、FindBugsを含む静的解析ツールの導入も行いました。この2年後に「継続的インテグレーションは強みではなくなった」という記事を書いていますが、これは継続的インテグレーションに対する社内のあまりの無理解に対して書いたものです。
  
  
• 1701G：1701Gというのは、2013年7月に発足した開発グループの正式な名称です。私がグループリーダでした。Star Trekのファン（つまり、トレッキー：Trekkie）であれば、1701が何を意味するのか分かると思います。
  
  このグループでは、デジタル複合機のコントローラソフトウェアをリコー社内では前例のない方法で開発しようとしたものです。Go言語を用いて、完全テスト駆動開発というものです。当時、Go言語での開発経験者の中途採用活動も行っていましたが、今日とは違って経験者は皆無でした。
  
  グループとしての活動は2年間で終了させられました。途中で、このグループの開発よりもはるかに先を行っているHPの開発を知りました。それについては、こちらで書いています。実は、このHPよりも先行できる可能性があったのが富士ゼロックスでした。1701Gで行った開発は、私が2003年から2009年まで従事したC++によるプロジェクトを、Go言語で若手のエンジニアを中心として焼き直したものでした。
  
  
• 技術レビュー：1701G以降は、開発現場の成果物のレビューを中心として活動を行ってきました。

【技術教育】2000年から行ってきている教育です。

• 「ソフトウェアエンジニアの心得」教育：リコーへ入社する前から行っていた2時間30分の研修です。リコーでは、2009年から今年まで、情報系として入ってきた新卒新人向けに毎年行ってきました。
  
  
• Java言語研修：詳しくは、こちらです。8年間にリコーグループで109名が修了しています。途中から数えるのが面倒になったので正確な数字は分かりませんが、約1/4の修了生がすでに転職しています。今年は、2年ぶりにJava研修のOB・OG懇親会を開催しました（その様子はこちらです）。
  
  
• Go言語研修：書籍『プログラミング言語Go』の出版を機に始めたGo言語の研修です。詳しくは、こちらです。

上記の3つの研修は、希望される企業があれば有償で開催可能です。開催日は原則金曜日となります。ただし、今回私が適用を受ける「セカンドキャリア制度」（いわゆる早期退職制度）の制約により、リコーグループの会社に対しては開催できません。

株式会社リコーを退職します

2009年9月から働き始めた株式会社リコーを8月31日付けで退職します。丸8年働いたことになります。現在57歳であり、定年退職までにはまだ2年と少しありますが、「セカンドキャリア制度」（早期退職制度のようなもの）の適用を受けて退職します。

8年間の会社での業務や退職理由については述べませんが、業務以外の私的活動の成果をまとめてみると次のようになります。

• 翻訳本（8冊）：『アプレンティスシップ・パターン』『プログラミング原論』『Android SDK 開発クックブック』『プログラミング言語Goフレーズブック』『Objective‐C明解プログラミング』『APIデザインの極意』『Java SE 8 実践プログラミング』『プログラミング言語Go』
• 自著（2冊+α）：『ソフトウェア開発の名著を読む 【第二版】』『プログラマー”まだまだ”現役続行』『API設計の基礎』
• Jolt Award読書会
• 横浜Go読書会
• 講演活動：実績と予定はこちら

現在翻訳している技術書は最終校正段階ですが、8月までには出版にならないので、出版は次の会社へ働き始めてからとなります。

最終出社日は、8月31日（木）です。そして、9月からは長年勤めた複写機業界（富士ゼロックスが12年、富士ゼロックス情報システムが11年、リコーが8年の合計31年！）を離れて、私にとって6社目となる会社で働き始めます。

専門性に忠実になる

転職に際して、「会社での工数の4割弱程度は、設計・実装・デバッグを行うことが希望である」と採用面接時に述べています。当然、そのような希望が常にかなうわけではありません。実際に、設計・実装・デバッグができなくても、若い人達の育成という意味で、レビューを行うことでも、ある意味、開発活動と見なすことができます。

大学を出て就職してから、私自身が開発を行っていない時期と行った時期が数年単位で交互に繰り返されています。そして、残念ながら最後の転職からは、行っていない時期となっています。

確かに、Java教育を行ってもきましたし、継続的インテグレーションの導入や様々なAPIのレビューなども行った時期もあります。しかし、実際に、自分自身がリーダである開発グループを持ってからは、開発ができるというよりも、管理職としての雑務（間接業務）に忙殺されており、チームの実際の開発の成果物をきちんとレビューもできない状況です。つまり、今の状況は、拙著『プログラマー”まだまだ”現役続行』の第12章「30代、40代の人たちへ」で述べている「レビューを行う」さえもできていない状況です。

前職では、リーダではなく、部長でしたが、むしろ、かなり開発をしていましたし、部長としての雑務は、今と比べて非常に少なかったです。それは、私の他にグループリーダがいて、さらに、事業部には選任の営業がいたため、私自身が開発における間接業務を行う必要がなかったからだと思います。

会社の仕事に忠実になるのか、自分の専門性に忠実になるのかを選択するとしたら、自分の専門性を選択します。そうでなければ、過去、4回転職することはなかったと思います。

どうやったら、もっと開発寄りの作業に時間を費やせるか考え直す必要がある時期なのかもしれません。

キャリア・アンカー

ウィキペディアでは、「キャリア・アンカー」は、次のように説明されています。

キャリア・アンカーとは、アメリカ合衆国の組織心理学者エドガー・シャインによって提唱された概念。

ある人物が自らのキャリアを選択する際に、最も大切な（どうしても犠牲にしたくない）価値観や欲求のこと、また、周囲が変化しても自己の内面で不動なもののことをいう。

ウィキペディアより

さらに、アンカーの分類として、以下の8分類が説明されています。

シャインは主なキャリア・アンカーを「管理能力」「技術的・機能的能力」「安全性」「創造性」「自律と独立」「奉仕・社会献身」「純粋な挑戦」「ワーク・ライフバランス」の8つに分類した。

• 管理能力 - 組織の中で責任ある役割を担うこと（を望むこと）。
• 技術的・機能的能力 - 自分の専門性や技術が高まること（を望むこと）。
• 安全性 - 安定的に1つの組織に属すること（を望むこと）。
• 創造性 - クリエイティブに新しいことを生み出すこと（を望むこと）。
• 自律と独立 - 自分で独立すること（を望むこと）。
• 奉仕・社会献身 - 社会を良くしたり他人に奉仕したりすること（を望むこと）。
• 純粋な挑戦 - 解決困難な問題に挑戦すること（を望むこと）。
• ワーク・ライフバランス - 個人的な欲求と、家族と、仕事とのバランス調整をすること（を望むこと）。

ウィキペディアより

数年前、52歳を対象とした研修で、自分のキャリア・アンカーを調べるというのがあったのですが、確か「技術的・機能的能力」が非常に高かったです。一方で、いわゆる管理職的な仕事は、過去も行ってきてはいます。日本オラクル社時代は、当時のOracle ApplicationsのHRシステムの開発マネージャでしたし、前職のFXISでも開発部の部長でした。しかし、今でもそうですが、「管理能力」はキャリア・アンカーとしては、かなり低いです。つまり、管理職を指向していないということです。

今、振り返ってみると、日本オラクルを退職したのも、FXISを退職したのも、私自身のキャリア・アンカーとは一致していなかったためかもしれません。最近は、私の回りの知り合いの若手のソフトウェアエンジニアで、転職する人達が多い※のですが、彼らも「技術的・機能的能力」を指向しているためなのかもしれません。
※　今年だけで、6名です。私の直接の部下ではありませんが、4名はJava研修の修了生です。

書籍『40代からのスターティングノート』

40代からのスターティングノート―あなたはもう、自分の人生シナリオを描きましたか？

• 作者: 関 眞次
• 出版社/メーカー: 日本経済新聞出版社
• 発売日: 2011/08/26
• メディア: 単行本（ソフトカバー）

少しSF風の小説として描かれており、人生の残り20年の計画を主人公が７つのFをキーワードに考えていく内容です。タイトルとしては40代ですが、40代後半から私のような50代が対象だと思います。7つのキーワードは、以下の通りです。

① Finale ― 人生の目標、仮のゴール
② Family ― 配偶者、子供、両親、親族
③ Field ― 活動の場。何をしたいのか？
④ Faculty ― 能力、技術。何ができるか？
⑤ Finance ― 財産、お金。生活必要資金
⑥ Friends ― 友人、知人。誰が本当の友だちか？
⑦ Fight ― 元気。やる気。心と体の健康

主人公である50歳の安部玲二の前に、14年後の未来の本人が現れ、iNoteというデバイスを与えて、それを通して7つのキーワードに関して主人公に考えさせるというストーリーです。パラレルワールドというSFの要素が入っており、途中で予想もしなかったような展開になります。

高度経済成長期であれば、60歳の定年退職を迎えてから、その後の自分自身の人生設計を考えれば良かったのかもしれません。なぜなら、組織を離れるのが定年になってからだったからです。しかし、今日では、組織を離脱するのは、定年に限られる訳で無く、独立、転職、あるいは早期退職など、早い段階で起こり得ることです。そのため、本書は、40代から自分自身の人生設計を考えてもらうためのきっかけとしての物語になっています。

私自身は、11月で52歳になります。ソフトウェア開発にどれだけ直接従事していたかということを振り返ってみると次のようになります。

1978年4月～1984年3月　大学で情報工学を学んだ期間です。
1984年8月～1996年8月　製品開発に従事し、米国駐在も経験した期間です。
1996年9月～1998年4月　直接自分でプログラミングをするという開発は行っていない期間です。
1998年5月～2003年1月　自分では直接プログラミングしなくても、技術教育やライブラリー設計をしたり、設計・コードレビューを多く行った期間です。途中、短いですが、再び米国駐在しています。
2003年2月～2008年12月　部門長でしたが、製品開発に直接従事し、設計からプログラミング・デバッグまで多くを行った期間です。
2009年1月～現在　残念ながら直接製品開発に従事していない期間です。

一方、2000年からは私的な活動として、雑誌の記事や書籍の執筆、技術書の翻訳を行っていますし、2009年からは一般の講演も行うようになっています。

この本のサブタイトルではありませんが、自分の人生のシナリオを描き直す時期かもしれません。

書籍『Being Geek』（３）

Being Geek ―ギークであり続けるためのキャリア戦略

• 作者: Michael Lopp
• 出版社/メーカー: オライリージャパン
• 発売日: 2011/06/25
• メディア: 単行本（ソフトカバー）

副題にあるようにキャリア戦略なので転職の話が色々と書かれているのですが、その中で「転職先の価値を見極める」（p.27）には転職先には「新しさとは別の、独自の価値があるかどうかが大切である」と述べられた後に、次のように述べられています。

　会社に独自の価値があるか、また、その価値とは何かがわかれば、次に問うべきことは、「そこで本当に自分のやりたいことができるか」である。むしろこの方が重要な問いだろう。それが自分の将来を左右する。また、この問いに答えるには、自分が本当にやりたいことは何かを考えなくてはならない。
　本当にやりたいことは何か、一言で明確に答えられなくてもいいだろう。私にもまだ明確な答えはない。だが、答えるのが非常に難しい問いだからといって、答えなくてもいいという意味にはならない。たとえおぼろげな目標だとしても、転職先の会社が、その目標に向かう上でプラスになるかどうかを考えることはできる。その会社に移ることで、目標に一歩でも近づけそうだ、と自分が感じるかどうか、それが最も大事である。
　つまり、転職先を選ぶというのは、ただ会社を選ぶというよりも、自分の進むべき道を選んでいるということなのだ。その道が本当に自分の進みたい道なのか、それをじっくり考えて決断すべきだ。

私自身が4回転職し、この部分は非常に耳が痛い話です。自分が何をやりたいかとうことは、若い頃には明確であった訳ではなく、色々な職場を経験して、徐々に明確になってきている気がしています。

しかし、4回目の転職がその目標に一歩でも近づいたと感じるかと問われるとしたら、大幅に後退したと言わざるをえません（感覚的には10年は戻った感じです）。では、何も得られていないかというと、そうでもなく、後退した結果、転職する前の位置までの道のりがどのようなものであったかが良く理解できるようになりました（「教育、場、権限」）。

後退した結果、同じ道のりを歩んで後退前の地点まで戻ることはあり得ないと思っています。それは過去の道のりであり、今歩んでいる道のりとは異なるからです。今の道のりで後退前の地点を遙かに超えたと言えるような地点まで歩めるのか、あるいは、もっと手前で別の道を歩むかは今は分かりません。

転職（5）

「転職（４）」で少しだけ現状を振り返っています。さらに、追記です。

技術教育を通して様々な事柄を教えていっても、開発の現場で実践される可能性は非常に少ないです。その主な理由は、開発現場での日々の活動や改善に対して、私が直接開発メンバーとして関与していないため、私からの教育やアドバイスを受けても、結局は現場の思惑で物事が動いていってしまいます。

つまり、教育に関しては、他に教える人がいないので単なる教育者としての活動を行わされているに過ぎず、さらに、教えたことが開発現場で実践される訳でもないのが現状です（「教育と場」）。

一方で、様々な開発グループに対する教育やコンサルテーション活動の他に、私自身は開発を行うグループに属しています。その開発グループに対して、残念ながら属している言えるような開発活動を私自身は行っていません。

私の経験からするとどう考えても1990年代までの開発手法であるため、様々な課題に気づくことが多いです。しかし、残念ながらそれらの課題が長期的なソフトウェア開発に与える影響に関して、現場のメンバーや技術リーダーには認識されないため、私自身が説得する気力をすでに失っています。

たとえば、レビューを受けてきたことがない人のコードをレビューして、色々と指摘して、最後は一緒にペア・プログラミングして、Eclipseの効率的使用法も教えながらコードを良くしたのに、「納期が厳しいのに本人に余分な工数がかかった」と言われてしまいます。

開発活動を行っていない実際の理由は、私自身に何らかの開発が任されていないことです。何も任されていないのですから、開発していないのは当然です。※

結論から言うと、私自身は、「seeking a change of employer」状態です。とは言っても、現在行っている社内向けの「プログラミング言語Java」教育は最後まで終了させるつもりです。また、始めたばかりの『Linux Kernel Development』読書会は、もし再び転職するようなことがあれば、希望者だけで週末に継続して行うことになるかと思います。

※ 開発環境を整備しないと、とても開発する気にはなれないので、開発環境の整備を提案して、そのための活動は行ってはいます。しかし、やりたいことが「環境整備、テスト駆動環境作り、テストコード作成など」で、「開発をしたいのではない」と周りが勝手に思い込んでしまうのには困ってしまいます。

【2011年7月14日追記】　
開発環境を整備したら、レンタル契約切れのサーバの契約更新も仕事だということで振られて、完全にサーバ担当者扱いです。この会社では、マネージャは何もせずに、すべての雑務を現場に押しつけるようです。