So-net無料ブログ作成
検索選択

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

コメント(0) 

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

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

8年間の会社での業務や退職理由については述べませんが、業務以外の私的活動の成果をまとめてみると次のようになります。
現在翻訳している技術書は最終校正段階ですが、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代からのスターティングノート―あなたはもう、自分の人生シナリオを描きましたか?

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

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

少しSF風の小説として描かれており、人生の残り20年の計画を主人公が7つの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』(3) [転職]

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

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


副題にあるようにキャリア戦略なので転職の話が色々と書かれているのですが、その中で「転職先の価値を見極める」(p.27)には転職先には「新しさとは別の、独自の価値があるかどうかが大切である」と述べられた後に、次のように述べられています。
 会社に独自の価値があるか、また、その価値とは何かがわかれば、次に問うべきことは、「そこで本当に自分のやりたいことができるか」である。むしろこの方が重要な問いだろう。それが自分の将来を左右する。また、この問いに答えるには、自分が本当にやりたいことは何かを考えなくてはならない。
 本当にやりたいことは何か、一言で明確に答えられなくてもいいだろう。私にもまだ明確な答えはない。だが、答えるのが非常に難しい問いだからといって、答えなくてもいいという意味にはならない。たとえおぼろげな目標だとしても、転職先の会社が、その目標に向かう上でプラスになるかどうかを考えることはできる。その会社に移ることで、目標に一歩でも近づけそうだ、と自分が感じるかどうか、それが最も大事である。
 つまり、転職先を選ぶというのは、ただ会社を選ぶというよりも、自分の進むべき道を選んでいるということなのだ。その道が本当に自分の進みたい道なのか、それをじっくり考えて決断すべきだ。
私自身が4回転職し、この部分は非常に耳が痛い話です。自分が何をやりたいかとうことは、若い頃には明確であった訳ではなく、色々な職場を経験して、徐々に明確になってきている気がしています。

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

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

転職(5) [転職]

転職(4)」で少しだけ現状を振り返っています。さらに、追記です。

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

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

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

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

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

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

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

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

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

転職(4) [転職]

今日でちょうど一年となります。期待していた仕事を、過去一年間でできたのかで評価すると、残念ながら評価点はかなり低くなります。

個々のソフトウェアエンジニアが継続的に学習を続けて、組織全体が成長するという観点では、一年前と比べると良くなってきてはいます。しかし、その変化は、非常にゆっくりとしたものです。また、本を読めば書いてあることさえ、教育コースを作って教えなければならないという状況に、あまり変化はみられません。(「教育と場」)

自分自身の成長という観点からは、会社の業務を通しての技術的スキルの向上はほとんどないです。その主たる原因は、「Be the Worst」にはほど遠い環境だからかもしれません。一方で、ソフトウェア開発の最終成果物であるコードを軽視するというソフトウェア開発組織の文化を経験できたことは、「読みやすいコードを書くことの重要性」やそのための「継続した学習」を強調している私にとっては、逆説的に言えば、(未経験なことを経験しているという意味で)良い経験になっているかもしれません。

この一年間を振り返ってみると、今後何年も留まる理由を、残念ながら今は見いだしていません。

ちなみに、今日でちょうど丸一年ですので、今まで5社に勤務した中で、3番目に長い会社となりました。4番目はジャストシステムですが、364日在籍したので、1日少ないです。

転職(3) [転職]

今の会社へ転職して、今月末でちょうど6か月になります。転職に際しては、こんなことができるようになるという期待も当然あって、転職するか否かを判断しています。ということで、それらの項目を半年レビューしてみると次のようになります。

項目
内容
評価
XXXXXXXXXXXXXXXXXXXXXXXXXXXXX
XXXXXXXXXXXXXXXXXXXXXXXXXXXXX
新たに多くの若手を含めた人材育成を行える機会が増える
XXXXXXXXXXXXXXXXXXXXXXXXXXXX
ソフトウェア技術者として、設計・実装・デバッグを行う開発が行える
XXXX

項目1、2、4に関しては、内容は伏せてあります。

項目3に関しては、「プログラミング言語Java」、「ソフトウェアエンジニアの心得」、etcと色々な教育を行っていますので、〇という評価です。会社での工数のほとんどがこれに費やしているとい言っても過言ではないです(【追記:2010年7月16日】参照)。

項目5は、会社での工数の4割弱程度は、設計・実装・デバッグを行うことが希望であるということで、採用面接時にも述べていますが、実際には全くそのような活動はやっていないし、やらない組織に属していますので、評価はです。

単純に考えると、工数のかなりの時間を費やしている項目3が〇だから、全体評価が〇になるのですが、そんなことは全くありません。私個人にとっての全体評価では、項目5がである限り、他の項目の評価は意味がありません。

そして、やはり、どんな会社でも、入社してみないと分からないことが多いのも事実です。

【追記:2010年2月23日】
最初は教育中心の支援的な活動でも仕方ないと考えていました。しかし、製品開発に直接従事して、設計・実装・デバッグまでを行える見込みはなさそうです。つまり、今回の転職は、私にとっては失敗だったと言わざるを得ないでしょう。

【追記:2010年3月2日】
2月23日の追記の表現を修正しました。:-)

【追記:2010年3月10日】
教育では話し続けることが多いため、連日行っているとさすがに体力的に疲れます。受講された人は、ある程度は教育そのものを評価してくれているでしょうが、「ソフトウェアエンジニアの心得」教育でも書いたように、マネージャ層は興味ないのが現実かもしれません。

【追記:2010年5月18日】
4月から開発系の業務へ異動しましたが、ソフトウェア開発のやり方が、私自身にとっては1990年代に戻ってしまった感じです。

【追記:2010年7月6日】
教育と場」をブログに書きました。そして、項目3の評価を、〇から△へ変更。

【追記:2010年7月16日】
技術教育は多く行ってきましたが、育成という観点からは全く無いに等しいのです、△からXへ変更。項目5は、まだ変更なしです。

【追記:2010年7月21日】
教育と場」とも関連しますが、今、行っているの技術教育は、「プログラミング言語Java」コース以外は、単なる集合教育であり、本来私が想定していた若手の育成とは全く異なる内容です。

【追記:2010年8月19日】
転職して今月末で一年になりますが、振り返ってみると開発業務はほとんどやれていません。

【追記:2010年10月20日】
項目5をXXに変更。

【追記:2011年03月11日】
項目3と5にXを一つ追加

【追記:2011年07月14日】
完全に全項目が駄目です。ということで、真剣に次を考え始めています。

【追記:2012年03月27日】
最初にこの記事を書いてからすでに2年が経過しましたが、4月からまた全く開発をしない組織への異動となってしまいました。

【追記:2015年01月07日】
2013年7月から自分がリーダを行う開発グループを持って、その後、増員することで、実際の開発を通して育成ができるようになったので、項目3を〇に。しかし、逆に、自分自身の工数は、全く開発に費やすということはできていません。今後、グループが大きくなればなるほど、自分自身では開発ができそうにないので、項目5のXが4個です。

【追記:2017年6月21日】
自分がリーダを行う開発グループは、2年前の2015年5月末で解散。その後、部下を持つこともなく、直接育成する若手もいない状態なので、項目3をXに修正。

【追記:2017年8月31日】
この記事の更新も今日で終わりです。

6ヶ月目 [転職]

転職して、昨年9月から働き始めて、今日から6ヶ月目です。過去の転職でもそうでしたが、会社というのは、会社の外からは分からないことが多く、実際にそこで働き始めて分かることが多いです。逆に、同じ会社にずっといる人は、自分の会社が他の会社とどのように違うのかが当然分かりません。

私自身は、会社としては、今の会社が5社目ですが、全く新しい人達と一緒に仕事を始めた職場としては、米国での3ヶ所を加えると、実質8社目です。それだけ、様々なソフトウェア開発組織でソフトウェアを開発してきたことになります。

しかし、ある会社の中での成果や評価は、やはり、その会社の中で閉じられてしまいます。そのため、今後は、ますます、外向きの活動をソフトウェアエンジニアにも、求められてくる時代がきているような気がしています。

ソフトウェア開発では、DRY(Don't Repeat Yourself)ということで、重複したことを行わないことが重要であるとされています。しかし、会社の中で自分の頭で考えて生み出したものでも、転職という機会に(頭の中に残っていても)失われていきます。新たな会社で、同じことを繰り返さないためには、普遍的な事柄というのは、やはり、外向きの活動として公けに残していく必要があると考え始めています。