また会社辞めます
1年と半年ほど勤めた会社を退職することにした。経緯について振り返っていきたい。
入社の理由
退職の話の前に入社の経緯から振り返る。もともとこの会社には「遠隔診療ビジネスの立ち上げに携わる」という名目で入った、はずだった。入社時にはテクノロジーで日本の医療に関する課題(僻地医療、通院中断など)を解決していきたいというビジョンが社長から伝えられ、大いに共感したことを覚えている。
あと、前のSIer企業がそれはもう向いていない仕事だったので、一刻も早く転職したかったという事情もありよく考えずに転職を決めたのは間違っていない。入社前に勉強会などで転職先の社員の方と面識があったこともあり、(今思うと)異様にスムーズに入社が決まったことを覚えている。
退職の理由
事業とのシナジーを感じない
なんだかんだ言って一番大きい。もちろん入社の時には任された事業に希望を感じていたが、その後会社の方が変わっていった。いや、正確には会社が変わりつつある所で自分が入ったが、結局元に戻りつつある、と表現した方が正しい。
もともと就活関連事業から始まった会社なので、今でも主力事業は就活および就活関連のオウンドメディアである。しばらくしてエンジニアを採用し自社サービスを内製するようになり、「メディアの会社」から脱却しようと様々な構想が立ち上がり、そのうちのひとつである遠隔医療分野に自分がジョインした。しかし最近改めてメディアを強化する方針が明確になり、自分の担当業務も遠隔診療システムからいつの間にかメディアサイトの運用保守に変わっていた(コンテンツは医療がテーマではあるが)。発足当初はメディアサイトを広告塔として自社の遠隔診療サービスの集客経路のひとつにすると聞いていたが、今ではメディアサイト自体のセッション数やアフィリエイト収入が主なKPIになってしまっている。
遠隔医療事業が医療メディアサイトの運営に矮小化された一方、会社は「メディア強化」方針に従いメディアサイトが次々に立ち上がった。消費者金融、保険、婚活、他社から買収した恋愛コラムなどなど…一体この会社は何を目指しているのか? ていうか一時期のD●NAと同じ流れじゃないかコレ? 疑いすぎかもしれんが、自分ははっきりと「迷走」の流れを受け取った。
技術的な成長の限界
こういう会社の方針なのでせいぜいメディアサイトしか作れない。ご想像の通りシステムには大して複雑な処理はなく、仕事の依頼も多くは「バナーを設置してほしい」とか「テキストを変える」とかシンプルなものである。ちょっとRailsができる、くらいの技術力であれば問題なく務まる。1プロジェクトに関わる人数が異常に少ないのでレビュー体制はボロボロで、コードの品質も上がるはずがない。たまに他社事例を知るとレベルの低さに愕然とすることばかりである。
しかも上記の「メディア強化」方針のためSEO関連の施策が多い。個人的にはGoogleの手の平の上で踊らされている感覚でどうしても好きになれなかった。ていうか、もともと遠隔医療システムを展開していくつもりじゃなかったのか? 何で俺は検索順位とかセッション数ばっか気にしているのか?
なぜ、エンジニアリングの程度が低くても会社が存続していられるか。これは前出の就活関連事業が盤石の主力事業として会社を支えているからに他ならない。やはり弊社は「営業の会社」だった。エンジニアなんてただの便利屋である。創業の経緯はもちろん理解して入社したが、そこからの変革が進んでいなかったのを見抜けなかったのは自分の失点である。
裁量労働制を正しく運用していない
ぶっちゃけ然る所に報告すれば一発アウトな事案だと思っている。自分含めエンジニアは裁量労働制として勤務してはいるのだが、
- 勤務時間の固定(遅刻の場合報告義務あり)
- 残業代は固定
- 22時以降の就業は事前申請が必要。なお、賃金の割増はない(※)
- (ルールではないが) 業務における裁量は限定的、な感じがある
いや、こういう働き方が悪いと言っているのではない。ただ、こういう方針なら裁量労働制を名乗るなよと言いたい。正直、残業代を払いたいたくないから裁量労働制と言っているだけの典型的なブラック経営では? とまで疑っている。ちなみに自分は金が増えないのに残業するのはアホらしいので極力定時で帰っている。どうせ窓際部署で大した仕事でもないし。
(※) これは裁量労働制であってもアウトである。つまり、社内「裁量労働制」適用者で22時以降に勤務した労働者がいたとして、この「社内規定」を根拠として割増賃金が支払わなければ、裁判で訴えられれば負ける。この会社、労基法のプロはいないのか? ちなみに私はアホらしいので22時前には絶対に帰る(なるべく、ではない)。
転職活動を振り返る
実は去年の9月ごろに転職サイトに登録し、ゆるく活動していた。前回の転職活動と比べればかなりストレスなく活動できた。
- 勤務地が都心なので仕事後の会社訪問が楽
- 残業が少ないので時間調整しやすい (※)
- Ruby on Rails の実務経験がある。これ重要
(※)自分だけは閑職なのでコレだったが、全社的には深夜残業泊まりこみ当たり前である。
今振り返ると結構な数の会社に訪問した。10〜15社くらいか? お祈りされたりしてまあまあストレスはあったが、いい結果になってよかった。
新しい会社を選んだ理由
基本方針
転職候補は、割と初期の段階からBtoBのビジネスに絞っていた。ある場所で話したら珍しがられたが、自分は日本の会社はもっと変わらなければならないと思っている。今後もBtoB重視の方針は変わらないだろう。
事業
転職先の事業を一言で表現すれば、製造業を中心とした会社同士のマッチングサービスである。事業実績も確認でき、そこから見る限りではユニークなビジネスに関われると感じた。また最終面接の場では社長から長期的ビジョンが示され、日本の製造業全体の再編までも目指していると伝えられた。今度は「入ってみたら違った」ということがないように祈る。
環境
もっともユニークな取り組みだと思ったのがリモートワークの採用である。全ての従業員は週あたり2回までリモートワークにより出勤しないで仕事を進めてもいい制度がある。これに関しては現職では基本的に認められていないこともあり魅力を感じた。ていうか今の会社リモート可の基準がよく分からないんだよな…子育て中とか親の介護とかだとできるらしいがそれなら俺だって…まあもう辞めるけど…
また、かのMatz氏を呼んでの定期的な勉強会の開催、外部イベントの参加補助など、エンジニア視点の環境が今と比べると比較的整っていると感じた。新天地でしっかり成長しようという気分になる。
縁
この会社に最初に訪問したのは去年の9月と、実はかなり古い。その間、その時面談を担当していた社員の方と イベントで偶然会う ということが3回ほどあった。特に去年9月のRuby Kaigiは全くの偶然で相当驚いた。
実はこれはいい方向に作用した。つまり面接 前 に担当者と会っておくと、履歴書や面接での質問から読み取るより何倍も詳しく自分の人となりを伝えることができる。ここで面接を設定すれば、もう始まる前から終わっているようなものである。エンジニアにとって勉強会の参加が大事な理由がここにある。転職したい会社があるなら、面接の前にその会社に行くことが近道。
おわりに
正直なところ、現職でも環境はそれなりに良く、人間関係も問題なかっただけに2年足らずで退職という結果になったことは自分でも惜しい。しかし、それらの良かった点をかき消すほど事業とのミスマッチは大きかった。
次の会社はそこまで大きなミスマッチは流石にないはず。まず転職を考えた時点でそこは注意したし、実際の社員とも何度も接する機会があった。6月からまた生活が一変することだろう。会社の大きな目標に自分がどこまで貢献できるか、自分自身はどう変わって行くか、今は楽しみにする。
ニコニコ動画のサムネイルを一括ダウンロードするRubyスクリプト
ニコニコ動画には、動画のサムネイルと概要情報を小窓にして埋め込める機能がある。見た事がある人も多いだろう。
[サンプル]
今回、こういう埋め込みがたくさんあるページからこの画像だけ持ってくる作業を自動化した。実行環境は Ruby2.3.3 (やや古いが)、HTMLの解析にお馴染み nokogiri を使っている。
サムネイルの中身
小窓の正体は <iframe>
である。中身を覗くとこういうアドレスの埋め込みになっている。
https://ext.nicovideo.jp/thumb/sm3504435
これは普通のURLなので、やろうと思えばブラウザでアクセスできる(見た目は悪いが)。
さて、欲しい画像はこの中にある。つまり <iframe>
からこのアドレスだけ持ってきて、改めてアクセスする必要がある。やや荒いが
parser .xpath('//iframe') .map { |iframe| iframe.attribute('src').value } .select { |iframe_url| iframe_url.match %r(http://ext.nicovideo.jp/thumb/sm\d+) }
とした(他に <iframe>
があるとも限らんので)。
画像の特定
改めて http://ext.nicovideo.jp/thumb/sm\d+
の中身を見てみると、サムネイル画像のURLは
https://tn.smilevideo.jp/smile?i=3504435
となっていることが分かる(これで例のミクちゃんが見られるよ!)。普通の <img>
タグなので取得は簡単。
# URLの読み込み→Nokogiri は事前にやっておく→ thumb_parser thumb_img_src = thumb_parser.xpath('//img[@class="video_img"]').attribute('src').value
これで画像のURLが取得できる。
画像ダウンロード
ここまでやったんだから画像のダウンロードまで自動化したい。URLの画像データをローカルに保存するには open-uri を使う。 (Stackoverflow さんいつもありがとうございます)。画像ファイルの形式は一見分かりにくいが .jpg なので
open(thumb_img_src) do |image| file_id = thumb_img_src.scan(/\d+$/)[0] File.open("images/smile_#{file_id}.jpg", 'wb') do |file| file.puts(image.read) end end
とすれば images/
以下に画像がずらっとダウンロードされる。ヤッタ!
成果物
といったコードを書いたのでGistに公開した。
ここで題材として使わせてもらったのはこのブログ記事になる。
で、これで取ってきた画像をなんやかんやして
今年10周年を迎える2008年公開のボカロ曲まとめてみたらちょっとショックだったのでみなさんご査収ください pic.twitter.com/ce1BlGOhaI
— ねこばばおにいさん🤘 (@strviola) 2018年1月26日
の画像を作った訳ですよ!
まじかああああああもう10年(略
以上、いろんな意味で10年の歳月を実感する記事でした。
今年の目標
2018年、あけましておめでとうございます。
更新しやすいタイミングなので久々に更新するが何ヶ月も空いてしまった。なんでこうなったのか、ちょっと去年をふりかえりたい。
まずこのブログは「技術ブログ」として生まれ変わる予定だった。そのために自分はどうやら完成度や充実性や独自性を気にしていたようで、更新自体に尻込みしていたような気がする。
それとも、ネタが無かったのか。いや、そんなことはなかった。やはりRailsエンジニアとして仕事をしていると日々直面する課題はある。そしてうまいこと切り抜けたりするが、そこで得た知見は…そうだSlackに書いていた。うちではSlackを社内SNS的にも使っていて、そこに調べたリンクなんかをメモしていた。知見を言いふらしたい欲は社内でも強かったはず。あと量は減るがQiitaやesaにも書いていた。
つまり今まで社内クローズドな環境に書いていたものをブログに書いていけば充分イケるということだ。これからそうしていこう。目標はまず量!質はとにかく公開してから!間違っていたらあとから直せばいい。個人のブログだしな。
そういや、調べ物をしていると割と古い情報が検索上位に来ることが思ったより多い。Rails4はまだ使える方で、Rails3のどことなく古くさいコードスニペットも散見される。自分の環境は全部Rails5なので、アイデアが既存記事と被っても「Rails5で動く」ことを伝えられればその価値もあるだろう。
今年の目標は、 月2本の記事公開! (あとで見直すかも)
Done is better than perfect.
とりあえずやってみようぜ、多分イケるから。
今年もよろしくお願いします。
古い Mac で Ruby を 2.4.1 にしようとした話
背景
Mastodon が流行中だ。ソースコードが GitHub で公開されている、 Ruby on Rails を採用しているとのことで私も動かしてみることにした。インスタンスを立てる前に、まずは localhost で動かすことを目指す。
リポジトリを手元に Fork & Clone して bundle install
したところ
「 Ruby2.4.1 を使え。古事記 (.ruby-version) にもそう書かれている」
しまった。 Ruby 自体のバージョンアップなんてそういえば数ヶ月していなかった。まずここから修正する必要がある。
筆者の端末は MacBook Pro (Retina, 13-inch, Late 2013) である。それまで携帯端末向けにしか搭載されていなかった Retina ディスプレイが Mac に採用された最初の機種だ。買った当初は「 Retina なのに大画面!しかも薄い!」と感動していたものだが、時は流れ「年季の入った」と呼んでも差し支えない状態になってしまった。
そんな状態でも手続きを踏めば最新のプログラムを動かすことはできる。こういう時は
とする。途中までは順調に進み、最後の rbenv install 2.4.1
しようとしたところ
BUILD FAILED
何か…コンパイル自体に失敗している…? こうなったらログを読むしかない。どうやら ossl_x509store.c
でコンパイルエラーを起こしている。こういう時は何かしら環境がマズいはず。エラーメッセージでググればどうにかなるだろう。
Sierra にアップデート
エラーメッセージで検索するとこんな記事が出てきた→ 年季が入ったmac(笑)にrbenvでruby 2.4.0をインストールしようとしたらハマったのでメモ - Uyama.coffee
おそらく同じエラー、環境も似通っているので参考になる。記事によると以下の5点を試したところ正常にインストールできたとのこと。
最初のは怖いので Sierra にアップデートを最初に試してみることにした。時間がかかるしネットで遊ぶ分には不自由しないので El Capitan のまま放置していたがいい機会だ。アップデートスクリプトを走らせてその日は就寝。翌朝、初期設定を済ませたあと改めて rbenv install 2.4.1
を実行したところ
BUILD FAILED
Xcode を更新
いや、一発でそんなにうまくいくはずがない。 Xcode は開発環境に加えてC言語関係のバイナリコマンドも付属する。バージョンアップは iTunes Store から行うがこれがまた長い。しかしこれでコンパイラも無事更新されたことだろう。
BUILD FAILED
いや待て、さっきの記事にはもう1個コマンドが紹介されていた。 xcode-select –install
だ。試すとダイアログが出て、いかにも仕事してくれそうな感じだ。よくなったと思いまたコマンドを叩くと
BUILD FAILED
Homebrew を更新
やっぱりねー使うの Homebrew なんだからそっちも更新しないとねー
Homebrew 自体の更新 (brew update
) は直近で行ったので、各 brew の更新を試す。 brew upgrade
の後に brew 名を入力しないと全ての brew が更新される。これもコマンドによっては何年も更新していなかったりしたので一晩レベルで時間がかかるが、その方がよりしっかり効いている実感がある。翌日改めて rbenv install 2.4.1
を実行!
BUILD FAILED
迷走…
正解を求めて様々な資料を調査したが、一つ学んだのは手当たり次第に試すべきでないということ。某所の「この記事は公開から1年以上が経過しています」の表示がある記事の信憑性は非常に低い。英語の記事もしかり。見つかった記事には
など、リスクが高かったり一時的だったりする手法がある。エンジニアには記事の内容が本当に効くか判断できる目が必要である。
ここまでやってダメだったとするとアレしかないか…
brew doctor
実行パスの警告を表示してくれる brew doctor
コマンド。実行すると尋常でない数の警告が表示された。 こんなことになっていたのか… そういえばこの Mac, マシン自体もそんなに新しくない上にデータ自体はそれ以前に使っていた MacBook (2008年購入) を引き継いだので、内部はもっと荒れていたと推測される。
とった対策は大体以下の通り ↓
ちなみにシンボリックリンクと通常のファイルが混在するディレクトリから通常のファイルのみを削除するにはこのワンライナーが使える。
ls -l path/to/delete/* | grep '^l' | awk '{print $NF}' | xargs rm
全部ではないもののある程度警告を潰して改めて rbenv install 2.4.1
を実行!
Successfully installed
😂😂😂😂😂
結論
brew doctor
先生の言うことはちゃんと聞こう。
以上、ボロボロの Mac に最新の開発環境を乗せようとして苦労した話でした。
大江戸Ruby会議06に行ってきました
先週末、3月18日〜20日は春分の日を含む3連休であった。天候にも恵まれたため外出したという方も多かったことだろう。自分はというと、月曜祝日に 大江戸Ruby会議06 に参加した。Rubyエンジニアとして非常に知見を深めることができたので、ここで感想など書いていく。(最初の「Ninja talks」は諸事情により参加しませんでした…) 内容自体は多分スライドが上がると思うのであまり深くまでは踏み込まない。
各セッションの感想
招待公演: Ruby考古学 (石塚圭樹氏)
Matz氏と並びRubyごく初期の開発メンバーである石塚氏が、当時のメールやコミットログからRubyの成長過程を紹介した。これ多分 他では絶対聞けない 。今回紹介されたログで一番古いものは1992年まで遡る。さらに “Ruby” 以外の名前の候補 “Oyster”, “Coral” なども紹介された (海を連想するのはPerl「真珠」を意識?) 。 めっちゃ貴重 。ここまで遡ると「新しい言語を作る」という意気込みが一番強く感じられ、どういうことかというと他の言語を 名指しで批判 していた(PerlやC++など)。普段当たり前に使っているプログラミング言語も、感情を持った人間が開発したものだと当然のことを改めて認識できた。
また、開発にかかった時間が実感できたのも大きい。Rubyの誕生日はその名前が決まった1993年2月23日とされている。この後順次機能が実装されていくが、その日付も紹介されていた。メソッド呼び出しのカッコを省略できるようになったのは1994/10/13, ブロック呼び出し構文として do ... end
が実装されたのは1996年、といった具合だ。正直、今までRubyはMatzという1人の天才から羽ばたくように生まれてきたイメージを持っていたが、実際は全くそんなことはなくて、多くの人が何年も地道な改善を続けてきた結果だと考えを正すことができた。世の中そんな順調なシステムなどない。
ちなみに以下のツイートが若干バズった。というかMatz氏本人にRTされた。
Ruby誕生から2年後、rescueをresqueとスペルミスしていたことにやっと気付く #oedo06
— ねこばば専務🤔 (@strviola) 2017年3月20日
フルタイムコミッター対戦
企業に所属しながら勤務としてRuby言語自体の開発に携わる「フルタイムコミッター」。今回は4名を招待して対戦する企画である。えっ、 「対戦」? …と思っていたら、始まったのはまさかの クイズ大会 である。この4名にはあらかじめ企画の趣旨を伝えてあり、Rubyのコミットに関するクイズを数問用意してあった。当日は1人が出題して他の3人が回答し、正解数の多い人が優勝。 マニアック すぎて面白かったので抜粋して紹介する。ちなみにこのセッションだけスライドが存在しないので記録を多くした。
Q1 RubyではGCの設定を環境変数として渡すことができる。この変数の種類はいくつか。
いきなりレベル高いよ!! そもそもGCの設定を環境変数として渡す機能自体初めて知った(こうするらしい。これが全てではない)。正解は 14種類 とのこと。
Q2 Ruby Issue Tracking Systemに登録されているissueは現在13000を超えているが、記念すべきfeature 10000は?
正解はこれ (ブログなので検索もできるしWebサイトへのリンクそのものを貼れるのは便利なところ) 。内容は浮動小数点数の精度をhashで渡そうというもの。これで 正解者がいる んだから恐ろしい。
Q3 Ruby 2.4.0 の文法で非終端記号はいくつ存在するか。
どこかのソースコードで定義されているようで、出題者は「grepして数えた」と述べていた。正解は 166 らしいが、さすがにピッタリ当てられた人はいなかったので一番近い「200くらい」と答えた人が正解になった。
Q4 今から10年前、2007年には12回のコミットがあり、うち9回はこの会場にいる人による。残り3回は同一人物だが、その人は?
驚くことに初球打ち正解がでた。Matzその人である。ていうか呼び方、「さん」もない「まっつ」なのね。内容は「スレッド周りだったはず」とのこと。
Q5 Rubyを構成するファイルのうち、最もコミット回数が多いのは version.h (※コミットの度に必ず更新されるため) だが、2番目は?
これは単純に興味があったがなかなか正解が出なかった。string.c, array.c などいかにも多そうなファイルが出るも及ばず。正解は io.c であった。なるほど、ファイル入出力か…
Q6 組み込みモジュール Math で一番最近追加されたメソッドは?
確か出題者本人の得意分野だった気がする。正解は3乗根を求める cbrt とのこと。もう「分かるか!」なんて思わなくなっている。
Q7 Rubyリポジトリの中で .rb
ファイルはいくつあるか?
Rubyの処理系はC言語で書かれた部分とRubyの部分があり、そのうちRubyスクリプトファイルの数が出題された。ちなみにこれには出題者からヒントがあり、 「素数」 。会場は多いに沸いたのであった。正解は 2383 で、「さっき思いついて .prime? してみたら true
だった」(出題者)。全然当たらないので最後の方は2分探索になっていた。
他にも出題があり、1時間くらいあったが全く飽きることがなかった。
Ninja talks
Rubyプロダクトに関わって活躍している方「Ninja」による1人あたり約30分のセッション。この日は6人のセッションを聴講し、どれも非常に濃い内容だった。一部感想と共に内容を紹介したい。
esaとRubyistと私 (赤塚妙子氏)
弊社でも利用している esa.io の共同創業者である赤塚氏が、自身のデザイナーという視点からRubyコミュニティについて述べた。この中で「デザインの役割とは方向性を示すこと」という話が興味深かった。
話が若干飛ぶが、イベント終了後の懇親会で、赤塚氏も含め何人かと会話した。その中でRuby界隈でよくある、「コミッターがスターになる」「新機能の取り入れに積極的」などの特徴がなぜ生じるのか議論した。すなわち、Ruby自体のデザイン、つまり方向性がそうなっている。新機能はどんどん追加するし後方互換性も結構捨てる。だから「新しいもの好き」が集まってくる。
赤塚氏はMatz氏を「デザイナー」と呼んでいた。プログラミング言語には当然利用者がいる。プログラミング言語をデザインするとは、すなわちその言語の利用者、さらにその利用者のコミュニティまでデザインすることである。これを本人は 無名の質 という考えを引用して紹介していた。
Ruby 2.4 Internals (笹田耕一氏)
クックパッド社でフルタイムコミッターとして活躍する笹田氏のセッション。これこそRubyカンファレンスの醍醐味である。Rubyの内部実装に触れるのは非常に刺激的だ。実装だけでなくテストやベンチマークの話もあった。Ruby2.4.0のリリースとして「 lambda
が速くなった」があるが、このベンチマークとして使用されたのが 「lambdaだけでFizzBuzz」 という尋常でないプログラムである。作者に「初めて役に立ったよ」と感謝したんだとか。
これとは別にRubyのコミットに関するセッションがあり、共通して感じたのが品質への意識である。まず課題を発見し、実装はもちろんあらゆるテストやベンチマークを実施し、報告書も提出する。バグを埋め込んだとしても発見者に感謝する。単なる「利用者」「お客さん」に収まらず共に作り上げていく、OSS開発の魅力に触れることができた。
おわりに
非常にボリュームのあるイベントだったので全ては紹介しきれないが、印象に残った部分をなるべく伝えたつもりである。参加者も全体で200人くらいいたはず。多くの人と関わるということはそれ自体勉強になることであり、それらが強力なバックグラウンドのある人であればなおさらである。カンファレンスへの参加、今後も続けていきたい。目標は9月にあるRuby Kaigiだ。
「簡易アプリ」英語で何と言う?
SIerからWeb企業への転職を果たし、Ruby on Railsエンジニアとなってからおよそ半年が経過した。概ねストレスも少なく心身ともに負担も小さい穏やかな生活を送っている。前回の更新(内容は忘れた)から半年間、書きたいことがなかったわけではないが、大声で主張したいことは勢いでTwitterに書いてしまうことが向いていると気づいたのがここ最近の発見である。当ブログは「技術系ブログ」として改めてスタートを切りたい。第一号はウォーミングアップの意味も込めて「軽い」話題から。
さて、本題である。私は入社してから現在まで、今の所移動もなく同じプロジェクトの追加開発を手がける日々を過ごしている。ある程度開発者として認識されてきたようで、比較的大きい変更を手がけることも増えてきた。そこで本日依頼されたのが、掲題の 「簡易アプリ」 のサーバーサイド実装である。
何が機密情報に当たるか分からないので詳しくは伏せるが、弊社は「地方創生」を事業として推進する方針があり、高齢化が進んだ農村にも積極的に営業をかけていて、その関係で自分の携わっているアプリの利用者には高齢者が多い。そういった背景もあって、利用者から「今のアプリは色々と複雑だ。最低限の機能だけ使える簡易版が欲しい」という声が上がったようである。
開発に着手するにあたって git checkout -b
しようとした時、ふと疑問が思い浮かんだ。「簡易アプリ」って、英語で何て言おう…? 私の前職のように、文字の制限などお構い無しに 日本語ローマ字をガンガン使う プロジェクトも存在するが、今の自分のプロジェクトでは可能な限り英訳している。
この単語は単なるブランチ名に留まらず、これから「簡易アプリ」全体を代表する単語として、モデル名やメソッド名に多用するプレフィックスにしていきたい。そう考えると、プログラムの保守性の観点からも重要な単語である。いくつかの辞書系Webサービスを見ながら考えていたら、いつの間にか小一時間経っていた。意外にいい訳が見つからない。
- “Simple” … 最初に思いついたし、Google先生も真っ先に挙げてきた単語だが違う気がした。 “simple” である方が正解で、そうでない方は望ましくないという印象を受ける。一方、今回は簡易アプリでない方も引き続き主力商品として継続する。
- “Easy” … 「簡易」から「簡単」を連想するとこうなる。確かに操作は簡単なんだろうが、「気楽」「快適」みたいな余計なイメージも入り込む。単に機能が少ないだけであって快適とは言えないだろう。
- “Abridged” … 「要約された」「短縮された」などの意味の単語。不勉強で申し訳ないが今日初めて知った。意味としてはいい線行っているが、日本人同士の会話で「アブリッジドの…」と言ったところで通じるだろうか?
- “Digest” … 「部分的に抜き出す」という意味ではかなり良い。しかしエンジニア的には セキュリティの文脈 で使う印象が強すぎるので、余計な勘違いを避けるためにこの単語は使ってはいけない。
他、類義語時点などを見て回ったが、「簡易」から「単純」「簡潔」といったイメージと異なる単語、果ては「朝飯前」「お茶の子さいさい」といった慣用句まで出てくる始末。日本語での検索はいったん諦めた。
気持ちを切り替えて、英語の類義語検索サービスである thesaurus.com を見つけたので検索してみる。 “Simple” 類義語の真ん中あたりにあった単語 “Light” … これだ!
思い返してみれば、特にiPhoneアプリ界隈で、本来有料で販売するアプリの無料体験版として “〜 Light” を名乗っているアプリを何度か見てきた。「機能を制限」かつ「本当は派生的な位置付け」を意味する単語として “Light” は最適な意味を持つ。かくして「簡易アプリ」は “Light Application” としてスタートを切った。
まとめ
- 日本語のコンセプトをきっちり表す英単語を見つけるのは意外に難しい。例えそれが、結果的に日本での知名度がかなり高い単語であっても。
- アプリ開発業界に於いて “Light” という単語は独特の地位を築いている。すなわち、「機能制限版」かつ「派生的な存在」であることを一気に表せる唯一の単語である。
ということで、特に技術的に苦心したというほどでもないが、個人的に発見だったので記しておく。これから少しずつこんな感じで記事を書いていきたい。
今の部署でなければ、もっと長続きしたんだろうか
退職届を提出してから、逆に社内の制度や特色ある取り組みをよく見るようになった。結婚や出産関係の届け出、入社10年目になるともらえるリフレッシュ休暇、海外出張制度、3年目対象のキャリアフォロー面談、結局どれも使うことなかったな…。アイデアソンのための綺麗な部屋、社内のプロジェクトを発表する内覧会、これも「社外常駐だから」「仕事があってねぇ…」とかなんとかで全く関わらなかったな…とか思いながら。
その中に、最近のニュースとして「当社社員が執筆に協力した論文が発表」とあった。北国のとある会場で行われる学会で、弊社の社員が発表するらしい。弊社の親会社が持っている研究所から案件を受注し、共同で研究を進めていた様子だった。ちゃんと先進的なプロジェクトもあるもんだと思った。
発表者の中に、俺の同期の名前があった。
色々なことを考えた。方や入社3年目にして着実に成果を残し、社外で発表するまでに成長した。方や仕事との向き合い方に本気で悩み、結局は退職という結果になった。もっと自分に向いている部署に配属されていれば、あるいはもっと早く希望を伝えていれば、2年半ではなくもっと持ったのかもしれない。
俺の同期入社は約20人いるが、入社から2年半経った現在、退職者はまだ1人しかいない。俺が2人目になってしまった。そういえば、あいつら今頃どうなんだろうな…1年前にあった発表会などの記憶を元に、同期の顔を思い出してみる。
Aさん (男) : さっき出た、学会で発表する予定の同期。俺と同じ修士卒で、入社1年目にして産学連携関係のプロジェクトに配属され、英語の技術論文をいくつも読みつつプロジェクトを進める必要があったらしい。今度の発表はその成果かもしれない。正直言って、英語の山のような論文と向き合うのは俺は大学院で一度経験したことなので、ここだったら大変だったかもしれないがそれなりに成果出していたんじゃないかという思いが捨てきれない。
Kさん (男) : 同期の中で一番「この会社が好き」な感じがする。Aさんと同じ本部のはずで、イチからシステムを作る機会に恵まれたようだ。顧客(スポーツジム)のことをよく知るために実際に入会して要件を考えた、と誇らしげに話していたのを覚えている。ちなみに、俺の異動先としてもっとも有力だったのがこの部署。確かに、俺の部署よりは向いてそうな感じがする。Kさんにとっては「面白い仕事たくさんあるよ」だったそう。
Sさん (男) : 同期の中で唯一、俺と対等に会話する(他の同期は 敬語を使う。 完全に先輩扱い)。サシで酒飲みながら仕事の話を聞いたことがあるが、出てきたのは愚痴ばかり。進路はなかなか希望通りにいかなかったようだ。配属からしばらくはひたすら書類仕事であり、数ヶ月後にCOBOLながらコーディングの仕事を任された時には「ありがとうございます!!」と反応したらしい。正直、ここだったらもっと短命だったろうな…ただ、残業がほとんど無いらしく、そこは魅力的である。
Tさん (男) : 1年前の発表の時点ではあまり印象に残らなかったが、最近別の資料で名前を見て思い出した次第。というのも、端的に言えば 赤字大炎上プロジェクトの火消し に駆り出されたメンバーの一覧にあった。このプロジェクトについて12年目の先輩に聞いてみたところ、客が官公庁か民間企業かの違いはあるが「こことあんま変わんない」とのこと。おお、怖…
Kさん (男) : 一番の苦労人。週に3回は日付が変わってから帰宅する、配属初月に残業時間が100時間を超えた、など噂が尽きない。しかし、そうやってリリースしたサービスがニュースになると、それを同期のLINEで報告するなど、やりがいは感じている様子。ちなみにこの人の部署、俺の上司が毛嫌いしている。曰く「あそこは昔の酷かった頃のウチだ」。
Mさん (男) : 今のところ、2014年度入社組で唯一の退職者。プログラミングが大好き、無駄なことはしたくない、といった雰囲気が一番強かった。しかし配属されたのはテスター部隊。あらあら。結局、1年半も持たずに退職していった。
で、このMさんとは本人の退職後に一度会ったことがある。その後は小さい会社でiOSエンジニアとして働いていたが、しばらくして会社ごと消滅し、今は当時の経験を生かして求職中、とのことだった。結局どこに決まったんだっけか。俺と似て、一定数いるベンチャー志望のエンジニアだったようだ。
…
うーん、こうして書いてみると、いい環境で若手が活躍している部署の方が少ないな…。20人もいて、よくみんな頑張っているものである。多分、この業界には「SI指向」と「ベンチャー指向」の少なくとも2種類の人間がいて、それぞれ落ち着くべきところに落ち着く力学が働くのではないだろうか。これはまたの機会に考えたい。
タイトルで書いた質問に答えるとすれば、 「YESだが、可能性は低い」 とか 「今の現場は結構マシな方」 といったところか。なーんだ。