砂日記ばーじょん2.0

IT関連の仕事中に浮かんできたポエムとか読んだ本の感想とか書いていきます。

映画ボヘミアン・ラプソディ最高だった

(どうしても前置きが長くなってしまうんだけど許していただきたい)

僕のような30代がクイーンのファンであるということは比較的珍しい。

映画ボヘミアン・ラプソディのクライマックスとして描かれたライブエイドの時僕は0歳だったので当然覚えてないし、フレディ・マーキュリーが亡くなった時点でもまだ7歳だった。

クイーンというバンドは30代の多くにとって、存在を知ったときには既に過去のバンドなのだ。

僕がクイーンに出会ったのは中学生の時だった。
僕のクイーン好きは母の影響が大きくて、母も若い頃から日本ツアーに参加したこともあるくらいクイーンが好きだった。

家に何枚かのクイーンのCDアルバムと、レンタルCDからダビングしたテープが何本かあって、
僕はテープに入ったアルバム『Made In Heaven』、特に『I was born to love you』に大はまりし(確かビールのCMで流れてたのがきっかけだったと思う)、リピートしすぎてテープを駄目にしてしまい怒られたりした。

なので一番好きなアルバムもMade In Heavenなんだけど、好きになった最初はクイーンの歴史とか来歴も全く知らなかったので、フレディ存命中のライブを視聴している時に「このライブではI was born to love youは演るの?」とか質問して苦笑されたものである。 *1

第一志望の高校の入試当日の朝にテンションを上げるために流したのもクイーンだった。

高校合格の祝い金で、家に無かったクイーンのアルバムを買い揃えた。母はしめしめと思ったことだろう。

で、アルバムのライナーノーツを読んでようやくクイーンの歴史を知るようになったんだけど、*2
前述したとおり、クイーンは自分にとってやはり過去のバンドなのである。

フレディはもういない。フレディがいるクイーンの新作アルバムはもう出ない(未公開音源の発表とかはあったけど)。

ライナーノーツを読んでオペラ座の夜ヒットまでの経緯とか、その後の浮き沈みとか、メンバー間の軋轢とか、バンドエイドを通じてまた1つになったこと、再び絶頂を迎えようととしたところでフレディの病気が発覚し、終焉に向かっていったこと、それは分かってフムフムと思ったんだけど、リアルなものとして感情にあまり刺さらなかったんだよね…。

20年弱という閃光の歴史に、僕の世代はリアルタイムで立ち会うことができなかった。

この映画ボヘミアン・ラプソディによって、僕はついにフレディ・マーキュリーの、クイーンというバンドの生き様に立ち会うことができたのである(前置き長かった)

本題 映画ボヘミアン・ラプソディ

まずこの映画はいくつかは事実と異なる脚色がされている。

詳しく言ってしまうとネタバレになるので詳細は伏せるが、よってこの映画は単なる伝記映画ではない。
そこは賛否あるところかもしれないが、それゆえ、フレディ・マーキュリーの内面の孤独や葛藤がより鮮明に描かれていることは僕にとってはありがたかった。

フレディは何を愛し、何を目指し、何に葛藤してたのか。過去の記録や関係者のインタビューからは想像しかできなかったけど、ストーリーとして映像化されることで、フレディ・マーキュリーという人間が何者なのか、クイーンというバンドが何だったのか、改めてちゃんと知ることができた気がする。

彼は子どものように欲張りで、強がりで、寂しがり屋で、愛に飢えていて。

メアリー・オースティンとの関係をピックアップした演出は必然だったと思う。

・・・ポエムっぽくなってきたので映画の話する・・・。

良かったところ!!若干ネタバレ注意!

ブライアン・メイとロジャーの監修が入ったことで、実際にこういうやりとりがあったんだろうなぁっていう話が多く再現されたこと。

レコーディングの様子。初期アルバムでは「No synths!(シンセサイザーは使っていない)」と毎作書かれていたけど、じゃああの不思議な音たちはどうやって表現していたんだってのが一部分かったこと。

ドラムの上にコインを並べてみたり、マイクに被せ物したり・・・。実験的だったんだろうな。地頭のいいバンドだから、色んなアイディアを試したんだろう。

スマイル時代のライブの様子、BBCの様子。口パク葛藤。

オペラ座の夜』制作中のメンバーのやり取り。
ガリレオって、誰!?」聞いてなかったの!w
あとロジャーの『I'm in love with my car』の扱いwwwこれはロジャー発の自虐ネタ?www
そしてボヘミアン・ラプソディがラジオ放送されるまでの紆余曲折。あっこれ有名なエピソードだ。

フレディ・マーキュリーの再現度は高かった。あのキレ、パフォーマンス。
自分もトレーニング積んで徹底的にライブ観て練習すればできるようになるんだろうか。なんて。

他のメンバーも。メイのギターもロジャーのドラムもクセを再現してて良かった。

メンバーの中で一番好きなジョンは、他メンバーに比べてトークしている映像が極端に少ないから、「ジョンってこんなことも言う人だったんだ!?」と興味深かった。
一方でフレディに「お前には何もない」とか辛辣なこと言われても激高するでなく「電気工学はダメかな」と苦笑混じりに返す様子は「あぁジョンならそう言いそう」て感じだった。

後半、ギャラ問題から広がるメンバー間の対立、休止、ソロ活動。ライブエイドを契機とした再集結。

フレディのソロアルバム『Mr. Bad Guy』大好きなアルバムなんだけど、色んな迷いや苦しみもある中で生まれた作品でもあったのかな。

そして映画観た人みんな絶賛してるけど、当時の実際の音源を使用したライブエイドのシーンは凄すぎた。映画館で聴くべき。

ボヘミアン・ラプソディのラストからそのままラジオガ・ガにつなぐ瞬間の盛り上がり。

涙腺決壊して、ボロボロ泣きながら観たよ。

音圧がすごいの。バンドの演奏じゃなくて、観客の音圧が。7万人の大合唱。

できれば生で観たかった。あと20年、早く生まれたかった!!

クイーンが活動していた時代を生きることはできないけれど、
こうしてこの映画でクイーンの歴史の一部が再現されたことで、彼らの生き様にリアルで触れることができました。

本当にありがとうございます。

*1:Made In Heavenはフレディの死後にリリースされたアルバムで、I was born to love youは元々フレディのソロで後からメンバーの演奏を加えたものである。よって当然クイーンのライブでフレディの存命中に歌われたことは一度も無い

*2:当時インターネットなんて便利なものは当然無かったし、関連書籍も家に無かったので、クイーンの音楽以外のことを知る術は限られていた

JJUG CCC 2018 Springに参加した!

www.java-users.jp

昨年も参加したJJUG CCC Springに今年も参加しました。
以下感想です。

JavaWebサービスを作り続けるための戦略と戦術

www.slideshare.net

  • ビズリーチさんがJavaWebサービスを作り続けてきた軌跡と実績の紹介。
  • 全体の1/3を過ぎたあたりで残り5分というこれまで見てきた中で最も時間配分のペース間違えた講演だった。
    • 御本人の体調もあまりよろしく無かったらしい。
      • 大事な話は前半とメルカリへの愚痴に詰め込まれていたと捉えることにしよう・・・。
  • どこが参考になったというよりかは、やっぱりどこの会社もそこに苦労するんだよね・・・という共感の大きなプレゼンでした。

Concourse CI入門 ライブ環境構築ビルド

資料:Concourse CI入門 ライブ環境構築&ビルド

  • Concourse CIには全く予備知識も興味も無かったのですが、うらがみさんを一度拝んで見たかったので。
  • Concourse CIはマイクロサービスのアーキテクチャを取り入れた(web / Worker / DB)に分かれた構造になっており、Docker Composeを使った手軽な環境構築、スケーリングのしやすさがウリなんだとか。
  • とはいえまだ色々試している最中で、よくわかってないところも多いという感じだった。

収益を支える中規模アプリケーション開発奮闘記

www.slideshare.net

  • Smart Newsさんの運用型広告配信サーバアプリ開発でやっていること。
  • コーディングレベルのレビューの話と内部的な性能問題の話が主で、アプリ開発奮闘記と事前に期待していたのとはちょっと違っていたけど、なかなかコアな問題から、それ身近でも聞いたことある・・・というのまで、幅広い内容だった。

如何に “データが壊れない” 管理画面を作るか - 管理画面開発の裏側

www.slideshare.net

  • Smart Newsの話続けて。こちらはスポンサーセッションだったので宣伝しっかりしてた。
  • Smart Newsの配信広告アプリは多様なコンポートネントが存在し、依存性が発生しやすい。連携の過程でデータの整合性が保たれなくなるリスクも大きい
  • そこで、接続点を中継したりデータを利用しやすい形に整形するハブ役(汚れ役)コンポーネントを作ったということ。
  • 依存性を閉じ込めて複雑度を下げるなど、分かりやすくて使えそうなテクニックが色々紹介されていた。

JavaエンジニアのためのDocker入門

speakerdeck.com

  • 講演聞いたあと、重い腰を上げてDockerをインストールしました。 ※まだHello Worldも出力できてないけど・・・。
  • 本当に初心者が参加しているのか訝しんでしたけど、少なくとも自分は完全に初心者だったしコンテナの説明とか、docker composeはなんぞやとか、とても参考になりました。
  • 正直まだDocker使って個人的にやりたいことは見えてないですが、勉強したいと思います。

残り2セッションあったけど、都合により早退。色々話聞けてモチベーションアップになりました。

Java Day Tokyo 2018に参加した!

参加したものについて簡単にコメントを残します

www.oracle.co.jp

Java EE アプリケーション開発コトハジメ

資料

  • JavaEE初心者向けセッション。
  • JavaEEの開発に全然参加できていないので、備忘的に参加・・・。
  • JavaEE7ベースでの解説が目立った(JavaEE8も基本的なところは変わらないから)

JDKの新しいリリースモデル

資料

  • チーム内に今のJavaのバージョンについて尋ねたら、3月にJava10がリリースされて9月にはJava11が出ることを知っている人はいなかった。
  • かろうじて、「最近Java10が出たとか・・・?」程度
  • とても丁寧にまとめられていて資料だけ読んでも十分参考になるので、部内で説明するときとかにも使えるかも。

Java SE 10、そしてJava SE 11への移行ガイド

資料

  • Java11へどのようにマイグレーションしていくかの解説
  • ケース別にチェック項目がまとめられていてわかりやすかった。
    • ケース1:Java8より古いバージョンの場合
      • チェック1:@Deprecatedが本当になくなります
      • forRemoval = trueとなっているやつは利用不可
    • チェック2:JDK内部API(sun..とか、com.sun..とか、java.awt.peer)にはアクセスできなくなります。
      • 例:sun.misc.Base64Encoderはコンパイル通らなくなるのでjava.util.Base64.Encoderへの移行を。
      • 「--add-export」オプションで非公開の内部APIを公開することができるが、急場しのぎなのであくまで暫定措置と認識しましょう
    • チェック3:リフレクション
      • リフレクションでprivateな変数に無理矢理アクセスするような黒魔術には「--add-export」効かない。
      • 「--add-opens」を使うとアクセスできるようになるが、やはり急場しのぎ
    • チェック4:JavaSE8までに含まれていたJavaEEのモジュール(JAX-RSなど)が消える。
      • JavaSE11以降は、JavaEEのモジュールを使いましょう
    • ケース2:JDK9で追加されたモジュールシステム(Project Jigsaw)を使いたい場合
      • チェック5:モジュールを使いたい場合は、module-info.java を作ろう。
        • jdepsツールを有効利用しよう
      • チェック6:モジュールシステムと非モジュールシステムの相互依存に対応しよう
        • このあたりからよくわからなくなってきた。モジュールシステムやってないとイメージつかみにくい・・・
    • ケース3:OpenJDKを使っている場合
      • チェック7:JavaFXSolarisはOpenJDKには入りません
        • OracleJDKを使いましょう
    • ケース4:すでにJava9以降の場合
      • チェック8:Incubator Modulesはjdk.incubator.httpclientからjava.net.httpにパッケージが変わります。

50分で最新技術学習の基礎を身につける

資料

  • 最新技術用語についてググって勉強しようとしたけど知らない単語が出てきて結局よくわからなかった・・・という問題を解決する
  • 「パラシュート勉強法」で基礎ではなく「軸となる用語」を学ぶやり方 50分で以下が言えるようになった(多分)

f:id:snufkin127:20180531191312p:plain

千葉県合同交歓演奏会挨拶文および実行委員長様のブログ記事へ

この記事は、以下記事のはてブコメントに載せるために書き起こしました。
(ブログ記事にコメント欄が非公開のため、遠回りな伝え方になっています)

■ご意見ありがとうございます
http://blog.livedoor.jp/ichifunawoct/archives/9054417.html

はてなブックマーク

 

顧問の勝手な言い分。:ご意見ありがとうございます。

高橋先生 SNSでの声に耳を傾けていただきありがとうございます。 吹奏楽部顧問の皆様にお願いがございます。 どうか以下のURLをご一読ください。 http://sunadiary.hatenablog.com/entry/2018/01/28/161124

2018/01/28 16:14

 
高橋健一先生および吹奏楽部顧問の皆様
SNSの声に耳を傾けて頂き感謝致します。
一連のご発信、始まりは吹奏楽部がブラック部活動と呼ばれることへの反論であったかと思います。
私も千葉の吹奏楽部出身者として、良い思い出を多く持っているため、吹奏楽部がブラックと呼ばれることは大変残念に感じています。

一方で、一部の吹奏楽部の中には、顧問が強権を振るい、生徒の自主的な活動という部活動本来の趣旨とはかけ離れた運営をされている吹奏楽部が存在し、休みが1日もない過酷な練習で起立性障害等の病気に倒れてしまう生徒、顧問の指導と称した罵詈雑言で双極性障害にかかってしまう生徒、同調圧力に潰され辞めたくてもやめられず、辞められても学校内での人間関係に苦しみ不登校になる生徒がいます。それをブラックと呼ばずして何と呼ぶべきか、という意見は無視できないところもあると感じています。


SNSのコメントを見て気付いていただけたかもしれませんが、マスコミが煽っているのではありません。部員や保護者、OBOGが声をあげているのです。
 

ブラック部活動問題は吹奏楽部に限った話ではありませんが、文化系部活動の中で吹奏楽部の上記事例が突出していることは事実であり、吹奏楽連盟はじめ多くの学校、顧問がきちんと吹奏楽部がブラック部活動と呼ばれている事実に向き合い、真剣に対策を講じていかなければ、吹奏楽部がブラック部活動と呼ばれる日に終わりは来ないと思います。

全国の吹奏楽連盟、学校、顧問、大人の皆様の力が必要です。
どうか、力を貸していただけないでしょうか。
よろしくお願い致します。

教員の労働問題について、ネット上で今年起きたことのまとめと情報リテラシーに対する雑感

adventar.org

本記事は、「子供/保護者/学校」×「情報リテラシー」 Advent Calendar 2017 - Adventarの20日目の記事です。
19日目は山田 夕子さんの「「子供」の世界から、高等教育(大学・専門学校等)、あるいは社会へと巣立っていく皆さんとご家族に贈る、「自分とルール」の関係がどう変わるかのまとめ」でした。(タイトルは書き出しを引用させていただきました)

教員の労働問題についてってタイトルですけど、テーマが情報リテラシーなのでそっち寄りの話に持っていきたいと、思うのですが、持っていけるかな・・・。

前置き

僕は現在学校とあまり関係を持っていないふつーの会社員です。
そんな僕が教員の労働問題、厳密には部活動問題ですが、それに出会った経緯は5月、以下の記事参照です。
教育界のえらい大人が吹奏楽部はブラックという差別意識を広め始めたのですべての吹奏楽部の未来がブラック - 砂日記ばーじょん2.0
部活問題から入り、段々教員たちのTwitterでのツイートを読んでいくうちに、教員の労働問題をハマっていく次第となりました。

教員の労働問題について、これまで起きたこと、今年起きたこと。

教員の労働問題が大きな盛り上がりを見せたのはここ1,2年のことです。
あるブログをきっかけに「学校ってブラック企業みたいじゃない?」という声がネット中心に叫ばれるようになりました。
今年、署名活動を行っている教職員の働き方改革推進プロジェクト、部活問題を扱う部活問題対策プロジェクト、教師や保護者の生の声を集めた教働コラムズなど、一般教員の有志による様々なコミュニティがネット上に形成されました。
さらに大学教授の発信などを通して、今年はメディアでも教員の労働問題が取り上げられることが増えてきました。

www.sankei.com

thepage.jp

現在に至っては、文科省管轄で進められている有識者による分科会学校における働き方改革特別部会に、一般の教職員らが声明を出すまでになっています。

www.bengo4.com

教員の働き方改革は既にひとつの大きなうねりとなっており、将来的には学校のあり方そのものが見直されていくのかもしれません。

【本題】教員のツイートと情報リテラシー(のようなそういう話でないような)

教員の働き方改革を叫ぶ声はネットを中心に活発に行われており、これもひとつの情報リテラシーの現れだと思っています(今回はそういうことにさせてください)
伴って特にTwitterでは教員のツイートが増えてきています。
教員がTwitterを利用する目的は様々です。上記の通り学校環境の改善を訴えるアカウントもいれば、愚痴目的で利用しているアカウントも多数見受けられます。現場では色々溜まるものがあるのかもしれません。
しかし、職業が職業なだけに、中にはうーんと首をひねりたくなるようなツイートも存在します。
管理職や同僚の愚痴ならまだよくある話ですが、保護者や生徒の悪口と取れる、本人の前では言えない内容など。
匿名で、特定出来ない形で呟いてるんだから愚痴くらい言わせて欲しいとツイッターの教員達は言います。
情報リテラシーの観点では、それはどうなんだろう・・・。
また、保護者のアカウントと対立したり教員アカウント同士で煽り合いのような口論する場面にもよく出くわします。
教員は聖職なんて言われた時代もあったようですが、彼らもまた普通の人間なのだと、色々と考えさせられます。

ここで私がその是非を語ることはしませんが、もし、興味があれば教員のツイートを覗いてみてはいかがでしょうか。

以上です!

(結局情報リテラシーの話だったのか?コレ)
(無理矢理感は否定しない。1つぐらいこういう記事があっても、まぁいいじゃん。ちなみに、うちの子どもは親のスマホを使い、まだ文字入力ができないので音声入力で欲しいおもちゃを検索したりします。1人でどんどん使い方覚えていくから頼もしくもあり恐ろしくもあり。うーん、情報リテラシー!)
(ほんと無理やりだな)

21日目はKeiko Kosekiさんによる、「コピペとスクショのはなし」です。
僕の妻はスマホ歴3年ですが、先月コピペのやり方を覚えました。スクショのやり方はまだ知りません。

もっと開発したくてSIerから事業会社に転職して1年経った今、僕はやりたかった仕事ができているのか

adventar.org

本記事は、退職者その2 Advent Calendar 2017 - Adventar の4日目の記事となっております。
3日目の記事は、kuwaccho0711さんの「東京の会社を退職し青森にUターンした話」でした。

皆さんスッキリとした読みやすい記事を書いていらっしゃって、クソ冗長になってしまった自分の記事を出すこと若干躊躇してしまう。

ざっくりと書いたこと

SIerから事業会社に転職した動機、転職活動の進め方、転職して1年たった現状の振り返り、という流れでいきたいと思います。
これから転職活動をしようと考えている方の何かしらのヒントになれば幸いです。

前職について

  • 1000人規模の金融系SIerシステムインテグレーター
  • 一応中堅どころの会社で、キャリアを積むと大体がマネジメントやPL(プロジェクトリーダー)、PM(プロジェクトマネージャー)になり、上流工程のみをやる感じ。
  • 自社も含め4~5箇所の現場を10年間で経験した
    • 最後の常駐先が最も長く、4年くらい常駐開発していた。
  • よくあるSIerのキャリアを積んできた(最初はプログラマーとしてコーディング、テストに関わり、設計、要件定義と段々上流工程に向かっていく感じ)

転職までの経緯

  • 最後の常駐先(事業会社)での色々
  • 最初は元請けとして僕と先輩社員の自社社員2人と、下請けとしてパートナー会社要員2人の合計4名が準委任契約でアサインされた。
  • PHPJavaでのBtoCサービスの開発を要件定義から運用保守まで一貫一任でやらせて頂いて、とても充実した経験ができたし転職活動でも強みになった。
  • 常駐から1年半が経ち、新規サービスの開発でパートナー要員を倍増したところで、先輩社員が諸事情で離脱。
  • 以降、社員が自分ひとりで、開発とパートナー要員管理の二足のわらじを履いて仕事をすることになった。
  • 社員は補充されず、一方でパートナー要員が増えていくにつれて、管理業務の比率が増えていった。
  • 顧客からはサービス開発を求められ、自分もエンジニアとしてのキャリアを希望していたが、上司は技術的な関心が薄く、仕事の内容や成果を報告しても評価されにくかった。いかにパートナー要員を維持・増員していくかに関心が強かったように思う。
    • 準委任契約だったので、顧客から増員要求があってパートナー要員の調達に成功すればそれだけチームの売上が伸びる。
      • 開発でどれだけの価値を提供するかより、要員をどれだけ増やしたかの方が指標として分かりやすいのは当然ではある。
      • また、2日目の@garbagetownさんのエントリを読んで思い出したことだけど、地味に辛かったのが協力会社要員も含めた勤務時間の管理。準委任契約は、顧客と決めた月間最低勤務時間が規定されている場合があり、最後の現場では140時間だったがそれを割ってしまうと支払って頂ける金額が時間単位で減ってしまう。
      • だから営業などからは割るなと言われるのだが、忙しい現場では無かったため、月の営業日数によっては休暇を取得してしまうと残業しないと規程時間を割ってしまう、ということがしばしば発生した。多少貰える金額が減ろうと定時で帰って自由に休暇取ればいいじゃんという考えだったが、完全に放置するのはチームの運営者としてマイナス評価になり得る。
      • 時にはパートナー会社の方たちに不要な残業をお願いしなければならず、調整を要したときは少なからずストレスであった。
    • そんなこんなでもやもやする思いを抱えながら、Developers Summit 2016 - Hack the Realに参加したところ、アジャイル開発、DevOps、ビッグデータなど、自分の知らない技術が大きく進んでいることを知り、危機感を覚えた。
    • 定年までこうしてマネジメントのキャリアを積んでいき、代わりに技術からどんどん離れていってもITエンジニアとして食っていけるのかという不安が日に日に増していった。
  • もうひとつ、最後の常駐先で「自社のサービスを育てる」という体験が協力会社の立場ながらできたことが刺激になった。
    • SIerの仕事は基本的に顧客から仕事を請けて、納品したらはい次の現場、である。
    • そうではなく、サービスインしてからが始まり、そこからさらにサービスをどう人々に使ってもらうかを考え続けていくこと。社員として自社の事業に深く関わりたいという思いが強くなっていった。
  • かくして、僕はエンジニアとしての成長と自社サービスへの貢献ができる会社への転職を志すことになった。

転職の進め方ついて

  • リクルートエージェント1社に頼った。
  • 複数のエージェントを活用するのが一般的?とネットには書いてあったが、管理が大変そうだったので1つに絞った。自分としては正解だったと思う。
  • 1つに絞ったため他社との比較はできないが、リクルートエージェントは大手なだけあって採用試験の情報を豊富に持っていることが強み。
    • A社は面接が大体x回あって、1次面接では課長クラスと人事部採用担当が出てきて、過去には○○といった質問が出た。みたいなのを多く共有してもらえたのは助かった。
  • 弱みとして感じたのは、1人のエージェントが多くの転職者をかけもちしているため、1人1人へのサポートは結構雑ということ。
    • 顔合わせした時の印象は良かったが、その後のやりとりでは説明の食い違いや連携ミスが発生したりもした。
    • エージェントにはそれぞれアシスタントなるサポート役が付いていて、面接の予約手続きなんかはほぼアシスタントの仕事。形式的な連絡も大体アシスタントの人とやっていた。事前の紹介もなしに突然出てきたので最初戸惑ったけど、色々サポートしてくれてエージェントさんと同じくらい感謝している。
  • 僕は求職期間2ヶ月で大体20社くらい採用試験に臨んだ。お祈りされたことも、自分から途中で辞退したものもあったが、結局内定をいただけたのは今の勤め先のみ。志望順位は2番手だったので、結局、あまり興味がないところはエントリーはしたけど企業研究をロクしなかったことが伝わってしまったと思うし、行きたいと思ったところは気合も違っていて、採用側もそんな自分をの意気込みを感じてくれたんだと思う。面接の練習という点では志望外の会社も受けたのは正解だったけど。
  • 今のところ再転職の予定はないが、もし次があるなら期間を定めずひと月1社くらいのペースでじっくりやってみたい。

前職勤務先への報告について

  • 僕の場合は特殊なケースかもしれないが、会社には転職活動を始める段階(4月末)で、8月末までに退職するという意思を示した。
  • 当然リスクはあったが、僕の場合前述の通り、社員が僕1人で替わりがいない状況だったことや、最後にお世話になった常駐先のお客さんに迷惑をかけたくなかった思いもあり、早めに交代の社員を用意してもらいたかった。結果として無事交代要員は見つかり、引継をやりきって後を濁さず発つことができた。
  • なお、最後の常駐先の居心地が良かったのでそこに転職すれば良かったんじゃないの?って話もあり、先方も歓迎ムードを出してくださったけど、収入面で折り合わなかった。

現職ついて

  • 16年9月に大手メーカーの通信系グループ企業に就職し、システム開発部門に配属された。
  • 入社前は「アジャイルで継続的デリバリーでモダンなシステム開発をなんとかかんとかで~」と聞いていたので技術的に圧倒的成長できる環境を期待していたが、配属されたチームは会社の主力事業を扱いつつ10年もののレガシー開発が今も続いており、perlとストアドプロシージャによるバッチ処理(自動テストなし)が現在進行形で生まれている。そんなところである。
  • もちろん他のチームはアジャイル開発をやっていたり、技術志向な部隊もあるので、御用聞きSIerの前職よりも魅力のある場所だと思っている。技術に限らず、自分よりも優秀な社員がゴロゴロしていて、たまに自分は足を引っ張っていないか不安になる程だ。
  • 一方、企画・要望は上から絶え間なく降ってくるので、結局、それらの要望を受け要件定義を行い、設計以降を協力会社に発注するという、前職と変わらないというかより上流寄りな仕事になってしまっている。
  • 現状としては「技術力で食べていく」というところは正直あまりできていないが、比較的要望が通りやすい職場なので、トレンドのキャッチアップを怠らなければいつでもプログラマーに切り替えることはできると考え、悲観はしていない。
  • 「自社の事業に深く関わる」というところは概ね達成できている。今年は転職から1年経っていないうちから金額の大きな案件をやらせていただき、モチベーションは高い。
    • 繰り返しだが前職よりも自由度が高く、働きやすい会社だと思うので、1年経った今でも周囲に追いつけていないところも多々あるが、徐々に自分のやりたいことに手を出していければなと思っている。

まとめ

  • 転職はいいぞ

次回はTONY0922さんによる「事業会社に転職して半年経ったので、ふりかえり」です。 「SIer→事業会社」への転職話を引き続きお楽しみください。

新装版 達人プログラマーを読んだ

新装版 達人プログラマーを読みました 

新装版 達人プログラマー 職人から名匠への道

新装版 達人プログラマー 職人から名匠への道

 

 1ヶ月くらいで読めるかと思っていたけど読書できない時期などもあり1ヶ月半ほどかかってしまった。

 

改訂版ということで最近の技術について併記する形で載せられているものの、今はこのやり方ではあまりやらないかな、という部分もあったけど、15年以上前に本書で語られた話の多くの部分が今でも通用するというのは基礎概念を身に着けたプログラマーは長生きするし強いということを証明している(15年というのが長生きかどうかというのはあれだけど、少なくとも10年目の自分はまだまだプログラマーとしてレベルアップできるな、とは思った)

 

自動テストによる品質保証の有効性って2000年時点で既に言われてたの?正直ここ10年くらいの話だと思ってた…

 

あとは、さすがにアジャイルという言葉は出てこないが、つまりこれアジャイルですよね、とか。

 

「ソフトウェアは建築と言うよりもガーデニング(つまりコンクリートではなく、より有機的なもの)に近い」というのは学生時代に聞きたかった…リファクタリングの文脈での説明だったけど、今やってる7人月程度のプロジェクト管理は変な枝が伸びてないか、枯れた葉っぱがないかみたいな確認の毎日だ。開発はベンダーに請け負ってもらってるけど、本当にこのままリリースできるのか、新たな問題が起きていないか見回りと剪定に追われている。

 

最近、プログラムに触れることが仕事では中々無いんだけど、上流も下流もおろそかにせず、マネージャーとしてもプログラマーとしてこれからも成長していきたいなと思っていたのでした。