ただのにっき

■ 今日は書くことがないな。また夫婦して風邪ひいて、買い出しに行ったほかはダラダラ。高橋の世界最高記録に感動したり、長嶋引退試合にヤジを飛ばしたり。

■ 夕食は近所の巨人ファン経営のラーメン屋へ。心なしか寂しそうであった。野球やめてサッカーにしなよ(笑) >マスター

■ お、いつの間にか第2期募集になってますな。広告の付かない無料のtDiaryつったらここしかないぜ。つーか最近、XREAって不安定すぎ。

■ tDiary: YYYYMMDD.html形式(2)

なるほど、そんな罠が。じゃあ、こんな感じでもOKですかね。

if ENV['REDIRECT_URL'] and not @cgi.valid?( 'date' ) then
   @cgi.params['date'] = [ENV['REDIRECT_URL'].sub( /.*\/(\d+)\.html$/, '\1' )]
end

本体に入れても影響のないコードを模索中……。

■ rxvtでscreen

おぉ、パッチがあるのですか、すばらしい。たしかrxvtって、最近は背景透過もできるんだよね。Eterm代替ができてscreenもVJEも使えるなら、乗り換えるしかあるまいよ。

じゃあ、これでAsumi用のRPMを作らなければ……あぅ。

■ 久保田早紀(3)

このネタだけで10件もツッコミが入るなんて、この日記、同世代人しか読んでないんじゃないかという気になるよ……。でも、太田裕美にははまらなかったなぁ。

そうそう、「今は教会で唄ってる」という情報は知っていたので、「教会」をキーワードにすれば探せたんだよね。Googleとけっこうひっかかる。先日はいいキーワードが思いつかなくて、「久保田早紀は今」で検索したらポルトガルに住んでいるみたいな、なんだか妙に妄想度の高い情報が出てきて苦笑してしまった。イメージ的にはそれもアリだが。

■ 長尾たかし

あちこちで話題になっているこれ。

• コンピューターの世界から、「日本語」が消えたっ
• 我国の危機の本質

最初のコラムは、間違ったことを書いてるのは承知の上で、無知な有権者を扇動するのが目的なんじゃないかと思ったりもしていたが(ネタにしか見えなかったし)、次のコラムの言い訳がもはや日本語になっていないのを読んで、ただのバカなんだと確信(地元が大阪らしいので「アホ」だとあまり侮蔑にならない)。たぶん、ProjectXのTRONの回を見て、ぜんぶ鵜呑みにしちゃったんだろうなぁ、この人。独自OSと独自プロトコルでIT鎖国してしまうのが、この人にとっての「IT立国」なんだろう。痛すぎ。

プロフィールを見ると今は別に議員じゃないらしいので、もし立候補するようなことがあっても間違って当選させたりしないようにおながいします >大阪の方々　代わりに自民党が当選しても文句は言いません(笑)。

■ アンテナよけの設置(3)

一日ようすをみていたが、「本日のリンク元」のアンテナよけ機能は順調に動作しているようだ。はてなダイアリーからのリンクから始めた「日記にアンテナを埋め込むのはやめよう運動」は、個人的には終了とする。「いちゃもんつけられたなぁ」と感じていた方々には謝罪したい。refererを受ける側では対策できないと思い込んでいた、こちらの非である。

残るは、「本日のリンク元」を発生源とするノイズへの対策だなぁ。まぁ、リファラ実験を見る限りでは、METAタグのRefreshを使うだけでおおかたの場合に対応できそうだという感触はあるんだけど(Lynxはもう、無視していいっしょ?)。

■ アンテナよけの設置(4)

よく考えてみると、この機能をONにしておくと、「users:tDiary.Netのアンテナに入れて欲しいんですけど」が意味をなさなくなってしまうのであった。あう〜、何か考えなくては……。

追記: たいへん泥臭い方法で対処しますた。ふはは。

■ tDiary 2.0.2がruby 1.8.3の秘孔をつく拳(2)

昨日の件だが、ruby-listに投げたところ、[ruby-core:6083]を教えてもらう。

で、このメールにあるとおり、parse.cだけコンパイルしなおしたらバッチリ動くじゃねーの。おぉ。おれの予想なんて、ぜんぜんあてにならんな……。

あとでtDiary.orgにアナウンス書かなきゃ。

追記

書いた。

追記2

ruby-coreまでじっくり読んでる人はそんなにいないことがわかって安心した(謎)。

■ はてな記法→HTML in CPAN

Text::Hatena via……あれ、どこだっけ?

これは以前書いた煽りに対する回答のひとつなのか? つーかこの記事、うちの「人気記事」の4位なのか! みんな、はてなが好きだねぇ。

■ RSSが生成されていなかった

ツッコミされて初めて気づいた。いやー、意図的なんてとんでもない。tDiary.Netでは、ユーザは何もしなくてもRSSを生成するようになっているんだけど、自分の日記だけ2.1系に移行したらそんなサービスは受けられなくなるということを、すっぽり忘れていたという。間抜けすぎ。

しかしなんだ、最近はRSSを更新しそこねると、ネット上から抹殺されたのに近い状況になりつつあるね。うちの読者のかなりの割合がRSSリーダ経由みたいだし。怖い話だ。

■ 昨日みたいな感傷的な日記に2桁もブックマークが付くってどうなのよ

かみさんに「そんなに増井さんが好きなら一緒にAppleに行っちゃえば」と言われた。なんだそりゃ(笑)。ありえねぇ。

そう言えば、こないだの飲み会で、Ruby stableのメンテナを雇ったらいい会社の候補にAppleを上げたら、高橋さんに「そんなバカな」的な顔をされてしまった。おれはアリだと思うんだけどなぁ。OS付属言語の仕様が不安定じゃ困るだろう。似たような境遇の会社としてはLinuxディストリビューションを出してるようなところがあると思うが、Appleほどの余裕はないだろうし。

■ 川崎 3-3 広島

TV観戦。

前半はここ数試合の悪い部分を引きずった感じだったが、後半になって目が覚めたよう攻撃的になった。特に我那覇は、まるでジュニーニョが憑いたかのようなキープ力を発揮して、まるで別人。これでジュニーニョとマギヌンが復活すれば、攻撃は大丈夫か。

問題はやはりDFだ。GKを吉原に変えても、寿人を何度も完全にフリーにしちゃうようなのは、どうかしているとしか。なんで急に連携がおかしくなっちまったんだろうなぁ。いくら得点しても、同じだけ失点してたら勝てる試合も勝てねぇ。

■ セキュリティはなぜやぶられたのか(ブルース・シュナイアー)

遅ればせながら。

のっけから9.11の「攻撃側」のプロジェクトマネジメントがいかに優れていたかを分析し始めて(いや実際優れているわけだが)、度肝を抜かれる。本書の執筆が2003年だそうだから、まだ一般向けのメディアでこういうこと書くのはタブーだったんじゃないだろか。勇気あるなぁ。というか、このままマネジメント本になっちゃってもよかった気がするが、その後はちゃんとセキュリティの話になる。

全体を通じて力説されているのは、セキュリティは特別なものではなく、生きとし生けるものすべてに関わるごく普通のことだということ。そしてセキュリティの評価をするときに指標にできる、一般的な5つのステップについて、厖大な量の事例を参考にしながら身につけることである。

とにかくうんざりするほど事例が多くて、整理すれば半分くらいの厚さで済んだんじゃないかと思うんだけど、読み終えてみると必要なだけの量だったのかもと思う。大きなところでは9.11のような大規模なテロの話を扱って、9.11後の対策にいかに効果がないかを暴き、有権者として何ができるかを考えさせる。いっぽう身近なところでは「食品が食べられるかどうか見た目や匂いで"認証"する」こともセキュリティだと説く*1

他にも、映画館でチケットの「売り場」と「もぎり」が別々なのはなぜかとか、考えたこともなかったようなところに効果的なセキュリティ対策が施されていたり。そういえば以前考察したナンバープレートをなぜ隠すのか問題についてもいろんなリスクをあげてあって、なるほどなぁという感じ。

我々は生活のありとあらゆる場面でセキュリティに囲まれており、どの課題に対してどんな対策をするべきかを決断し続けて生きている。セキュリティ問題は継続的で変化に富んでいるので、けっして終わることがない。だからこそ専門家に任せることなく自分で考える必要がある。……ということを、じっくり理解できる名著。

余談。どうも用語がいくつか気になって仕方がなかったんだけど、特に「剛性が高い」という言い方。普通「剛性」は高い方が良いという印象を与えるから、セキュリティに関しては逆に「剛性が高いのは悪い」と言うのはどうかと思う。読んでるあいだ中、ずっと混乱した。硬すぎて壊れやすいことを日本語では「脆い」とも言うわけで、もうちょっと言葉を選んでも良かったんじゃないか。たぶんセキュリティ業界では普通の言い方なのかも知れないけどさ。

あと本書に限らないけど「リスクをとる」って言い方も混乱するよなぁ。たぶん「take」から来てるんだろうけど、「とる」だと「取り除く」と「受け入れる」のどっちだかわからない。前者の意味で誤用されている例がすごく多いことからわかるように、適切な用語とは思えない。今からでも変えられないもんだろうか。

ということを言い始めると、この邦題もちょっとひどいよなと思うわけだが。ちなみに原題は「Beyond Fear」で、恐怖に駆られて見当違いで効果の低いセキュリティ対策に走るのではなく、冷静にトレードオフを計算しろという本書のテーマにしっかりマッチしている。邦題はまるで、クラッカーの手口分析の本みたいだ。

■ 車載動画デビュー

先週のツーリングで撮ってきた動画をニコ動にうｐした。けっして動画向きとは言えないCANON IXY DIGITAL 55を、これまたけっして車載向きとは言いがたいGorillapodを使ってBMW R1200GSに固定した。

Gorillapodはかなり柔らかい構造なので、振動しちゃってどうしようもないだろうと予想していたんだけど、思いのほか安定していて驚いた。まぁ、動画を見ればわかるように、長時間固定し続けることが難しいので、実用的には論外なんだけど。ちゃんとしたマウンタを探さねば。

あとは動画向きのデジカメだよなぁ。やっぱXactiがいいんだろうけど、バイク用となると防水タイプを選ばざるを得なくて、そうなるとHDじゃないのが寂しい感じ。もっとも今回の動画(元は640x480)でもまぁまぁの画質なのでいいか。

ところできれいなエンコード方法を探していたら(とにかくたくさんの予備知識が必要で困った)、ニコエンコという関連ツールとおすすめ設定のセットになったものがあり、おかげで簡単にできた。こういうのは助かる。

ただ、車載動画は動きが大きいせいか、それでもやはりノイズが目立つ気がする。高画質への道は長い。

■ ソフトバンクが大量通信ユーザに帯域制限

通信品質確保対策の導入について:

前々月の月間パケット数が、パケットし放題、パケットし放題S、パケット定額ライト、パケット定額の場合、300万パケット以上（PCサイトブラウザ、 PCサイトダイレクト利用時は1,000万パケット以上）、パケット定額フルの場合、1,000万パケット以上のお客さまについては、当月1ヶ月間、パケット定額サービスが適用されるパケット通信の速度を制御する場合があります。

はっ。1000万パケットなんて、そんなそんな。使ってるわけねーじゃん。ちょっとMy Softbankで確認してやんよ!(↓)

おれ死亡のお知らせ……。

とりえあず、自宅では面倒くさがらずにWiFi経由で使うことにする。

■ パーフェクトソフトウエア(ジェラルド・M・ワインバーグ)

読みながら、なんとも評価しにくい本だなぁと思っていた。

ソフトウェアテストに関して書かれた本である。が、いわゆるノウハウ的なことはほとんど書かれていない(せいぜい「バグの重要度は4段階にせよ」という指針くらい)。じゃあ何が書かれているかというと、テストに関わる人間について、実例を交えつつその「心理」を解き明かしている。

(テストファーストでない限り)開発の最後の工程であるテストには、人間の(きたない)心理がもっともよく現れる。そんなテストを取り巻くさまざまな場面に遭遇したとき、本書のような知恵があれば、きちんとテスト結果を評価し、正しい(もしくは可能な限り良い)判断を下せるようになるだろう。と思う。

けどまぁ、そう簡単にはいかないだろうなぁ。

で、最後まで読んで、訳者あとがきに「本書はテスト技術者にとっての『ピープルウェア』である」的なことが書いてあって、かなり納得した。つまり、技術面でさまざまな進歩が見られるようになってきたテスト技術者にとって「精神的なよりどころ」や「心の理想郷」みたいなものへの道筋をしめした本ってことだ。

そう考えるとけっこういい本かもしんない。もっとも、だとするといささか読みにくいのが難点だけど。一読して意味を取りにくいのは訳文のせいかなぁ。

https://www.amazon.co.jp/dp/9784822281106

パーフェクトソフトウエア
ジェラルド・M・ワインバーグ
日経BP
￥778

■ Amazon-Auth-ProxyをSinatraに移植してHerokuで動かす

先日発表になったGoogle App Engineの値上げはGAE上で無償サービスを運用していた人たちをパニックに陥れたが、tDiaryとて無関係ではない。amazon.rbが使っているProduct Advertising API用リバースプロキシがGAE上で稼動しているからだ。

GAEの値上げ自体は11月まで猶予されたが、それでもやはり、ああいうロックインされやすい環境に依存するのは危険だ。で、同じサービスをまちゅさんがheroku + Sinatraに移植してくれたので、そちらに引っ越すことに。たぶん10月末に予定されているtDiaryの次のリリースからはこちらを使うことになると思う。

さて、リバースプロキシだけでなく、認証プロキシの方もいつまでもCGIじゃねーだろというかもっと移植性の高い環境で動かさないとね、ということで。Sinatra移植に挑戦してみた。仕事でRuby使ってるつっても主にデータ処理なのでWebアプリの新作はもう何年も作ってないわけで、新しい技術のキャッチアップはぜんぜんしていないのだ。もちろんRailsでもいいわけだけど、そんなデカいものを作る予定もないのでまずはSinatraから。

というわけでGithubの方にいろいろ追加→amazon-auth-proxy。元のCGIをそのままライブラリとして使っているのでかなりひどいアーキテクチャだが、RSpecで不完全ながらテストも書いたし、Rack上で動くようにしたし、Bundler対応もした(というか対応しないとHerokuで動かせないみたい……なのかな?)。なんかモダンじゃーん。

で、これをHerokuで動かす。この手順を簡潔にしておけば、誰もがプロキシを運用できるはず。まずはgemでherokuをインストールし、「heroku create」でアプリケーションを作成する:

% gem install heroku
...
% heroku create amazon-auth-proxy-tdtds
Enter your Heroku credentials.
Email: t@tdtds.jp
Password:
Found the following SSH public keys:
1) id_dsa.pub
2) tdtds.pub
Which would you like to use with your Heroku account? 1
Uploading ssh public key /home/sho/.ssh/id_dsa.pub
Creating amazon-auth-proxy-tdtds... done, stack is bamboo-mri-1.9.2
http://amazon-auth-proxy-tdtds.heroku.com/ | git@heroku.com:amazon-auth-proxy-tdtds.git
Git remote heroku added
% 

これでamazon-auth-proxy-tdtds.heroku.comというサイトができた。ここにプログラムをgit pushすればデプロイできるのだけど、さて、ここで問題が。設定ファイルには秘密にしておかなければならないAmazonのキーが含まれるので、これをGitHub上に公開するわけにはいかない。たぶん良いプラクティスがあるのだと思うが、とりあえずローカルにreleaseというブランチを切って、そこに設定ファイルを含めてHerokuにpushすることにした。

% git checkout -b release
% cp amazon-auth-proxy.sinatra.yaml amazon-auth-proxy.yaml
% vi amazon-auth-proxy.yaml
...KEYなどを書き換え...
% git add amazon-auth-proxy.yaml
% git commit -m 'added yaml file for release.'
...
% git push heroku release:master
Counting objects: 90, done.
Compressing objects: 100% (86/86), done.
Writing objects: 100% (90/90), 12.94 KiB, done.
Total 90 (delta 44), reused 3 (delta 0)
-----> Heroku receiving push
-----> Ruby/Sinatra app detected
-----> Gemfile detected, running Bundler version 1.0.7
       Unresolved dependencies detected; Installing...
       Using --without development:test
       Fetching source index for http://rubygems.org/
       Installing diff-lcs (1.1.3) 
       Installing rack (1.3.2) 
       Installing rspec-core (2.6.4) 
       Installing rspec-expectations (2.6.0) 
       Installing rspec-mocks (2.6.0) 
       Installing rspec (2.6.0) 
       Installing tilt (1.3.3) 
       Installing sinatra (1.2.6) 
       Using bundler (1.0.7) 
       Your bundle is complete! It was installed into ./.bundle/gems/
-----> Compiled slug size is 680K
-----> Launching... done, v4
       http://amazon-auth-proxy-tdtds.heroku.com deployed to Heroku

To git@heroku.com:amazon-auth-proxy-tdtds.git
 * [new branch]      release -> master

ありゃー、いりもしないRSpecまでインストールされちゃってるな。これはGemfileで開発用のgemだけ分離するような書き方があるのだろう(と、tDiaryのGemfileを見ながら学習)。まぁいいや。なんにせよ、本当に簡単で拍子抜けするくらいだなぁ。これが現代のPaaSか!(今ごろなに言ってんだ)

というわけでいちおう動くようになったけど(プロクシなのでブラウザからアクセスしてもなにもないよ)、まだ異常系もロクにできていないのでもうちょっといじってから本番投入するとしよう。

■ 「鉄腕バーディー」、ついに完結

ついにバーディーが完結したので、単行本を待ってさっそく読んだ。畳んでない伏線とかいろいろあるけど、掲載誌をかえて10年続いた連載が、いちおうちゃんと終わりをみたのだからめでたいことだ。最終的にSFとしてはわりとオーソドックスなプロットになったけど、キャラも立ってて、マンガとして楽しかった。エピローグもいい。

で、「10年?」と思って書庫をあさってみたけど、確かに「この」シリーズはEVOLUTIONになる前の無印一巻が2003年。ゆうきまさみのブログにあるように連載開始が2002年なのでたしかに10年。でもなー、古いファンとしては上の写真にある1996年の「初代」があって、これも入れるとバーディーとは16年以上の付き合いなわけですよ。そういう意味でも感慨深い(続編だと思って今シリーズを二巻から買ってしまったのもいい思い出[笑])。

さらに言えば、今回の結末、初代の存在も認めるかのような世界観で〆られたわけで、これもまた嬉しい。

鉄腕バーディー EVOLUTION (13) (ビッグコミックス)
ゆうき まさみ
小学館
￥339

鉄腕バーディー 第1巻 (少年サンデーブックス)
ゆうき まさみ
小学館
￥2

■ Ustream上の動画をYouTubeに移した

Ustreamがアーカイブ映像の保存期間の変更についてというアナウンスを出していたので、慌てて過去の動画をダウンロードした。10月9日までなのでかなり急な話だ。一部の動画がダウンロードできない(404になる)のだけど、なんでだろう。まぁいいけど。

で、ほとんどが猫動画でその他の車載動画はさほど価値がないので、猫動画だけYouTubeにチャンネルを作ってそちらへアップロードしなおし。

• Gustav - YouTube
• Dora - YouTube

最近は猫動画撮ってないなー。たまには撮ろう(←と書くだけ書いて忘れるパターン)。

しっかし、こういう運用の変更って過去のデータはそのままに、新しいデータから適用って感じにするもんだと思うのだけどなぁ。過去にさかのぼって適用、しかも猶予はたったの10日って、Ustreamはあんまり経営状況よくないのかしらん。

2014-10-06追記

11月1日まで削除開始時期が延期された。よっぽど文句がたくさん来たんだろうな(笑)。そりゃそうだ、いくらなんでも急すぎるし。

■ MongoDBにrepairDatabaseをかけたらファイルサイズが半分になった

Wassrが終了してから明日で2年、ということは、わさますでmassrを運用しはじめてからも2年以上経過しているということになる。ちゃんと開発も利用も継続しておりますよ、massr。

ちなみにわさますmassrはHeroku上で運用してるんだけど、ストレージにはMongoLabの無料プランを使っていて、その上限がファイルサイズ500MB。で、確認したらなんと496MBも使っていた。あぶねーなおい(笑)。

有料プラン($15/mo)に移行するかねという相談をしたが、その前にデータが減らせないか試してみようということになり、repairDatabaseというコマンドを実行したら*1、なんと半分になってしまった。ということは、もう2年くらい延命したってことだ。ありがたや。

■ ガス給湯器をリプレイスした

この家を建ててから10年以上がすぎて、ここ1、2年なぜか夏場にだけエラーを表示していたガス給湯器を、ようやくリプレイスした。エラー表示にはなるし、たしかに出力も下がってるんだけど、使えないこともないからだましだまし使い続けていたんだけど、お湯が出なくなると困るので、本格的に故障する前に交換することに。

これまではノーリツだったんだけど、こんどのはリンナイ。ひとつまえの型をお安く手に入れた。新しいだけあってリモコンのデザインはだいぶUIが向上した感じはある……が「エネなんとか」という省エネ機能がてんこ盛りでちょっとうんざりする。

リンナイのリモコンは賑やかなことで有名で(ニコ動あたりで検索するとリンナイ vs ノーリツ的な動画がみつかる)、そりゃもう、チャイムやら合成音声やらでうるせーのなんの。まず最初にやったのがマニュアル見ながら音量を一番小さくすることだった。マニュアルの(目次でなく)表紙の目立つところに項目が載ってるくらいには、自分とこの製品がうるさいという自覚があるようだ。耳の遠い年寄りなんかのことを考えると、音量絞った状態では出荷できないんだろうなぁ、といちおうの理解はしておくが。

■ OSS Gate東京ワークショップ#11にサポートメンターとして参加してきた

奇数月の月末なので、恒例のワークショップ。今日の会場は初めてお借りしたサイオステクノロジーさん。いつも思うけど、都内にこれだけ広いイベントスペース用意できてるの、すごいよなぁ。こちらも十分な広さと設備があって、しかもビルの入口にちゃんと案内まで出していただけて、たいへん助かった*1。

今日はビギナー・サポーターのバランスが良くて、平均ビギナー2人/サポーター1人くらいの割合。初めてのサポーターが2人いたのでそこはマンツーマンにして、ベテランサポーターに3人面倒をみてもらうようにして、おれはサポートメンターに徹した。

すでに直したいネタを持ってきてる人から、自分が使っているツールやライブラリのどれがOSSなのか把握してない人まで、あいかわらず参加者の幅が広いけど、ちゃんとサポートできたように思う。ゴールのフィードバックまでたどり着けた人ばかりではなかったけど、それでも満足度は高かったので。

最近は、職場の同僚からの口コミでやってくるビギナーが増えてきてるなぁという実感がある。やっぱり同僚がちゃんとOSS開発に慣れ親しんでいると、お互い仕事がしやすいってのもあるよねぇ。

次回は11/25、場所は未定。

■ 31年勤めた富士通グループから退職した

この日記では明に所属企業を書いたことはなかったけど、仕事がらみのイベントとかでは普通に名刺を配ったりもしていたので、ご存じの方にはご存じだったと思うが、新卒で入社してからずーっと富士通の子会社に所属していた*1。

今年はその富士通でマネージャになってちょうど20年になる。20年前にはまるで世をはかなんでいるような日記を書いているけど、けっきょくそのまま居座ってマネジメント畑を耕していた。20年のキャリアつったら、普通に考えてもプロ中のプロですよ。ずっとエンジニアのつもりだったのに、気がついたらマネジメントのプロフェッショナルになっていたという。人生なにがあるかわかったもんじゃないね。

富士通に限らず、日本の多くの伝統的な企業には役職離任という制度があって、定年より前に一定の年齢に達すると管理職を解かれて一般社員相当の身分になる。制度そのものには(少なくとも企業側には)一定の合理性があるとはいえ、20年間も部下を持ってマネジメントをやってきて、能力が落ちたわけでもないのにある日突然宙ぶらりんなポジションにされてしまうのも納得がいかないので辞めることにしたのだ。まぁ会社としてもそういう行動を期待しての制度運営っぽいのでwin-winだ。

タイミング的には昨年末から、リファラル狙いでのんびり転職活動を始めたものの、そもそもマネージャ職の求人というのはそんなにない(当たり前だがエンジニアの数分の一以下)。なかなかマッチする会社が見つからないでいる中、コロナ騒ぎで求人市場自体が細くなる。そんなこんなで当初の想定よりもだいぶ苦労したものの、ようやく素敵な会社と出会えたので、決断した。

かなりの余裕をもって上司に退職の意思を伝え、いわゆる最終出社日は今月9日だったにもかかわらず、事務方の稟議プロセスがなかなか進まなくてハラハラしたけど、退職予定日の今日になってようやくすべての書類をそろえられたので、本日をもってめでたく退職となった(はず。たぶん)。

日本のSIerというとIT業界では極めて評判が悪い職場だし、実際おれも炎上プロジェクトに放り込まれたときは最悪レベルのパワハラを受けて体を壊したりもしたけれど、そういうところは実のところ例外的で、全体としては悪くなかったかなーと思う。でなけりゃ30年以上も勤めたりしないよ。とくに最後の10数年間は裁量の幅も大きく、自分で設定した目標を自分のペースでかなり自由にやらせてもらえたので楽しかったね。部下にも恵まれたし。使えない上司は少なくなかったが(笑)、そういうのを上手く乗りこなすのも含めてマネジメントスキルだしな。

最後の仕事は研究所のリモートワーク環境整備(技術面だけでなくカルチャー面でも)で、安定して運用が回りはじめたところだったので、辞めるとしたら本当にちょうどいいタイミング。振り返ればなかなか悪くない31年間だった。お疲れさん！

以下蛇足。

大きな企業の退職プロセスを当事者として間近で眺めるチャンスはそうそうないものなので、この一か月はヒヤヒヤしつつもなかなか面白かった。

最初のイベントは上司への退職願の提出なんだけど(これをトリガーにして稟議プロセスが走り始める)、フォーマットも決められてるし、Microsoft Wordでちゃちゃっと作って、署名だけ手書きして提出したわけ。そしたら上司が「手書きじゃない退職願なんて受け取るの初めてだ」とか言うわけですよ。うん、おれもそう思う(笑)。でも、社をあげて「DX企業になる」って掲げてるときに、手書きじゃなきゃ受け取らないとか言ってちゃダメじゃないですかね、と屁理屈をこねたら納得してもらえた。持つべきものは物分かりの良い上司です。いつかDXが進んで、メール1本で退職できるようになるといいね。

その後、総務部門から書類一式が届くと聞かされていたんだけど、これが待てど暮らせど届かない。ようやく分厚い封筒が配達されてきたのがなんと退職5日前。いくらリストラ真っ最中で大混乱の間接部門だからって遅すぎる。

で、中身をみてその原因が推測できたんだけど、ようするに「60歳定年退職」をターゲットにしたプロセスしかないんだな、この会社。何年も前からX Dayがわかっている退職に向けて準備を進められるようになってるから、いきなり途中で辞める社員のスピード感に合わないのだ。なんたって「退職10日前までに処理せよ」と書かれた書類が入ってるんだもんな*2。もちろん定年前に辞める社員はおれが初めてなわけがないが、このプロセス、通常は利用者(==退職者)からフィードバックを受けるチャンスがないから、今まで改善が進まなかったんだろう。

富士通はいま、時田社長の号令で大改革が進行中だ。リモートワークを標準にしてオフィスを半減させるとか、ジョブ型雇用に移行するとか、他の伝統的国内企業とは一線を画すスピード感で変わりつつある。人材の流動性も今後一気に高まると思うので、定年を前提とした退職プロセスじゃ早晩やっていけなくなるだろう。DX企業化、手始めにここから始めてみてはどうですかね?