LIFE Cook

人生を豊かにするために(料理ブログではありません)

「AWS認定Solutions Architect - Professional」だけ取った

はじめに

AWS 12冠」ではなく、AWS Solution Architect - Professional (AWS SAP)の資格だけ取った。

自分はこれまで資格取得にはあまり力を入れてこなかったし、 難関資格を取得したのは初めての経験だ。

そのため、「1カ月勉強して合格しました!」というような華々しい結果でもない。 しかも一度、不合格を食らっている。 AWS SAPの勉強だけやってたわけではないが、かなりの時間を費やしてしまった。

そういう自戒の念も込めて、今回学んだことを記事にまとめておこうと思う。

なぜ資格を取ろうと思ったのか

元々、資格に興味が無かったのは最初に入社した会社の影響だ。

新卒で入社した某家電メーカーでは、資格の保持などに全く興味がない会社だった。 「勉強するより手を動かせ!」的な体育会系であったこともあるが、資格を持っていなくても凄いエンジニアがゴロゴロいたので、 自分も資格を取ろうとは思い至らなかった。

しかし、初めて転職してその見方はガラリと変わることになる。

2社目の某自動車部品メーカーでは、AWSの導入に力を入れていて、 AWS資格を持っている人が重宝された。

凄腕エンジニアだった私の上司もAWS SAPを持っていたし、 AWS12冠を達成していた同僚はAmazonに転職していった。 世のサラリーマン達がいかに資格の取得に頑張っているかを思い知らされた。

という訳で、周りに影響されてばかりなのだが、自分も一つぐらい資格を取ろうと思った次第である。

AWS SAPを選んだのは次の理由からだ。

  • 既にAWSを使った開発経験が4年ほどあった
  • インフラやバックエンドの苦手意識を克服するため
  • AWSの全サービスを網羅する勉強をしておけば、たいていのWebサービスは作れるだろうと思ったため
  • ずっとソフトウェアエンジニアというキャリアを続けてきたため、アーキテクトという肩書が欲しかった(笑)
  • 高収入への期待
  • www.itmedia.co.jp

    資格と給与の関係では、「Google Cloud Certified Professional Cloud Architect」や「AWS Certified Solutions Architect - Professional」など、アーキテクト関連が上位になっているところが目立ちます。

    失敗談

    成功体験の話より、失敗の経験の方が価値があるという。 まずは、失敗談を書いておこう。

    Practitioner/Associateから取得するべきだった?

    AWSの資格にはレベルがあり、 Solution Architectに関して言えば、 下位レベルの資格としてCloud Practitioner, Solution Architect Associate(SAA)がある。

    https://digitalidentity.co.jp/blog/wp/wp-content/uploads/2020/07/image1.png 引用元:AWS認定公式

    おそらく、AWSの資格はこの下位レベルの資格から順に取っていくように設計されている。 しかし、既にAWSでの開発経験があったこと、 たくさん資格を取ることに前向きではなかったこと、 試験費用と勉強時間をケチりたかったなどの理由で、 これらをすっ飛ばしていきなりSAPに挑戦してしまった。

    その結果、一度不合格を経験し、いろいろあって資格取得まで1年ほど時間がかかってしまった。

    実際に受けていないので何とも言えないが、 SAAぐらいは取っておいた方がスムーズにSAPも取れたのではないかと予想している。

    まさに急がば回れということだ。

    模試を解くだけでは非効率

    事前にSAPの勉強法を調べたのだが、 多くの合格者が模試を解きまくることを推奨している。 AWS資格以外でもよく過去問をいきなり解くことを勧めている話もよく聞く。

    qiita.com

    私の場合もUdemy BusinessのAWS SAP模試をひたすら解いていた。

    しかし、AWS SAPは問題数75問、試験時間3時間にもなる難関試験だ。 模試も同じ構成で作られており、途中停止はできるものの、毎回同じぐらいの時間がかかってしまう。 75問解いてから答え合わせになるが、その頃には最初の問題や気になった箇所など忘れてしまっている。 全問を解くのも大変だが、75問分の回答を読み続けるのも脳みそがパンクする勢いだ。

    結果的に不合格を経験し、勉強法も再考することになった。

    AWS SAPの勉強法

    実際に合格に至ったことで、効果があったと思われる方法をまとめておく。

    教材

    AWS認定資格試験テキスト&問題集 AWSソリューションアーキテクト - プロフェッショナル 改定第2版』

    まず挙げるのは、『AWS認定資格試験テキスト&問題集 AWSソリューションアーキテクト - プロフェッショナル 改定第2版』だ。 特に良かったのは、ネットワークの説明が秀逸だったこと。

    dev.classmethod.jp

    どの分野なのかを分類して、苦手分野がどこかを特定して、そこだけを集中してやるようにしました。これで、私はネットワークがとても苦手だとわかりました。

    SAP合格者の多くがネットワーク周りの問題が苦手だったと呻いていたが、自分も例外ではなかった。

    この本にはネットワークの章があり、 図解でAWSのネットワーク系サービスの構成要素が分かりやすくまとまっていた。 自分はこの章を5、6回読んで、完璧に内容を頭に入れた。

    それ以外にも個人的には以下の点が良かった。 この本無くして合格はできなかったと思う。

    • 新テスト形式のSAP-C02に対応している

    • SAP試験範囲の全サービスについての説明がある

    • 図解を用いた分かりやすい解説

    AWS認定ソリューションアーキテクト - プロフェッショナル ~試験特性から導き出した演習問題と詳細解説~』

    2冊目の『AWS認定ソリューションアーキテクト - プロフェッショナル ~試験特性から導き出した演習問題と詳細解説~』は電子書籍で購入した。

    1冊目に挙げた参考書に比べてSAP試験特有の嫌らしい問題、 つまりは読解力が試され、複数の解釈ができるような表現やひっかけがある問題が多いように思えた。

    特に良かったのが、一問一答形式で問題が掲載されているところ。 これについては後述するが、隙間時間にスマホで勉強するのに最適の1冊だった。

    Udemy Business: AWS認定ソリューションアーキテクトプロフェッショナル模擬試験問題集

    最後は、Udemy Businessの講座なのだが、もうこの講座は無くなったらしい。 当時所属していた会社がUdemy Businessを契約していたおかげで、無料で受けることができたので、 仕事の合間にちょくちょくやっていた。

    既に書いたように1回75問の問題を解かなければならないので、 これだけだと非効率だ。

    ただし、SAPの試験範囲は恐ろしく広く、 既に書いた2冊の参考書でも全てをカバーしているとは言えない。 (実際、試験では上の2冊ではほとんど出てこなかったDataSyncがよく登場した。)

    そのため、どういう問題が出るのか、何を問われるのかといった問題の雰囲気を捉えるのには役立つだろう。

    今なら通常のUdemy講座でもSAP試験対策の講座があるようだし、 自分が調べた中では CloudLicense(旧TeckStock)での対策コースが充実しているらしい。

    cloud-license.com

    通勤電車で一問一答

    Udemyの講座はスマホでも見れるのだが、これが見やすくは無かった。 小さい画面では問題文が読みづらいし、何より75問もあるせいで問題のロードに時間がかかりすぎた。

    そこで活躍したのが、 電子書籍で購入していた『AWS認定ソリューションアーキテクト - プロフェッショナル ~試験特性から導き出した演習問題と詳細解説~』だった。

    この本はサンプル問題をベースに説明を展開していく構成になっていて、 最後の模試以外は一問一答形式で問題と回答が並んでいる。

    これが電車の中や会社の昼休みに手を付けるのにちょうどよかった。

    TOEICの記事にも書いたが、 社会人が勉強するには隙間時間を如何に上手く活用できるかがカギになる。

    trycycler.hatenablog.com

    今回の経験でもそれを思い知った。

    なんだかんだでノートに回帰

    最初はUdemyの模擬試験で問題をひたすら解いて、 分からなかったところをOneNoteにまとめていった。

    しかしSAP試験では、試験範囲の広さもさることながら、 各種AWSサービスの細かい設定なども問われることもあり、 難しくしようと思えばいくらでも難しくできるような問題内容である。

    そのためか(あるいは年齢で記憶力が落ちたためか...)、 模擬試験を何周しても、毎回間違える問題や覚えられない項目があり、 合格できる兆しがなかなか見えなかった。

    そんなとき、記憶力アップのための秘訣についての記事からヒントを得て始めたのが、 紙のノートを使った学習である。

    人間が知識を定着させる一番の方法は「復習」らしい。 そこで、毎日新しく学んだことや気になったことをノートに書いて、 次の日には前日の記載内容を見てから試験対策を始めるようにした。

    正直、ノートをまともにつけたのは学生の時以来だが、 学生の頃と違う点がある。 それは長期保存するための記憶媒体としてではなく、 あくまで次の日に復習するためだけの短期記憶媒体としてノートを使ったことだ。

    お世辞にもきれいに書いてるとは言えない

    次の日に見るためだけに書いているので、 きれいにまとめる必要もない。

    これだけならOneNoteやNotionといったノートアプリを使ってもできるが、 システム構成図などをラフに書ける手書きならではのメリットからも紙のノートが最適だった。

    速読のコツはアーキテクチャをイメージすること

    初めてSAP試験を受けて不合格になったとき、 最後まで解き切ることができなかった。

    3時間で75問なので、1問あたり2.4分で解かなければならない。 しかし、問題文が異常に長いものや細かいシステム要件が散りばめられた文章の読みづらさから、 これが意外と難しい。

    これをすばやく読めるようにするには、 読みながら頭の中でアーキテクチャをイメージできるようにならなければならない。

    特にこれをすればできるようになるというものはないのだが、 問題文を読みながらアーキテクチャをイメージできるようになってきたら本試験に臨む頃合いだろう。

    おわりに

    今回、SAP取得するまで時間はかかってしまったが、 自分なりの勉強方法を見つけられたことは良かったと思う。 資格ではなくても今後何かの役には立つだろう。

    それに時は金なりなのだが、 試験勉強にほとんど費用をかかっていないのは良い点だろう。 Udemyは会社で契約したものだったし、不合格を食らった試験費用も会社の福利厚生で何とかなった。 ここで紹介した教材以外だと、無料のサンプル問題などをちょこっと触ったぐらいだ。

    資格を取った効果については、 やはりAWSを使ったシステムアーキテクチャの理解度は上がったと思う。 普段使わないサービスの知識まで知見が広がったのが大きい。 外道父さんのAWS関連の記事などをよく読むが、 「あー、あのことを言ってるな」と解像度高く読めるようになった。

    blog.father.gedow.net

    ただし、「AWS12冠」を取る気はないかな... BigData SpecialityやMachine Learning Specialityあたりは興味あるが、 本当に必要になったらでいいと思っている。 SAPでさえも、オンプレミスからAWSへの移行に関する問題は頻出だが、 それを使う機会が来るかどうかは疑問である。

    エンジニア界隈ではコンピュータサイエンスの学位を取りに、 大学に入り直す人もいる。 自分はそこまで学術肌でもないし、そこに時間とお金をかける覚悟は無い。 でも仕事をやっていて、理論や知識不足を感じるときはあって、 そういうのをインスタントに補う手段として資格取得も悪くないなと思えた。

    レファレンス・チェックはやめてほしい

    はじめに

    日本の製造業にてソフトウェアエンジニアとして働いて10年あまり。今年そこから脱出して、晴れて外資系企業で働くことになった。

    trycycler.hatenablog.com

    その過程で、個人的には面接より厄介だったことがあった。

    レファレンス・チェックである。

    レファレンス・チェックとは

    レファレンス・チェックとは、企業の応募者について、その人をよく知る第三者にインタビューして、 第三者視点によるその人の人となりや過去の仕事への取り組み方などを確認するプロセスだ。

    doda.jp

    要は、企業側にとっては、問題のある人を誤って採用しないためのリスク回避策だ。

    日系企業でレファレンス・チェックをやっているという話は聞いたことがないが、 外資系企業では割と当たり前にやっているらしい。

    また人によっては、レファレンス・チェックは絶対必要だという。 応募者の勢いに負けて採用してみたが、実は問題児だったというケースは珍しくないらしい。

    レファレンス・チェックの依頼

    応募者にとって問題なのは、レファレンス・チェックを誰に頼むかである。

    これは応募者が探さなくてはならない。 それも一人ではない。私の場合は、3人推薦者を出してくれと応募企業から指示された。

    当然、現職の企業に、他の企業に応募していることなど伝えられない。 基本的には、レファレンス・チェックの推薦者は前職の上司に頼むように言われる。

    しかし、前職の上司の連絡先など覚えているものだろうか? 今はSNSが普及しているので、かつてよりそういった情報を探しやすくなっている。 実際、自分もLinkedInで前職の上司に連絡を取ったり、前職の同僚から連絡先を教えてもらったりした。

    レファレンス・チェックの弊害

    しかし、ここでいくつか問題が発生した。

    レファレンス・チェックはコンプライアンス違反になりえる?

    実際にレファレンス・チェックのチェック項目を見たわけではないのだが、 仕事内容のかなり詳細なところまで聞かれるらしい。

    これがコンプライアンス違反になる可能性があるのだ。

    (採用が決まった後で、参考までにレファレンス・チェックの内容を教えてほしいと、応募先企業にお願いしたのだが、断られてしまった。)

    私が依頼を出したかつての上司は、以前にもレファレンス・チェックを対応したことがあった。 彼は、あまりに詳細なことを問われるので、人事部にどこまで話していいか確認したそうだ。 当然と言えば当然だが、人事部の回答は「会社が公開していない情報は話すな」だった。 そうなると話せる内容がかなり限られてしまうらしい。

    結果、彼がかつてレファレンス・チェックを対応した応募者は採用されなかったとのことだ。

    時間が経ち過ぎている問題

    仕事の詳細な点まで聞かれることからくるもう一つの問題は、 時間が経ち過ぎていて、推薦者が当時のことを覚えていないという問題だ。

    最近では1年ぐらいで転職している人もいなくはないが、 私の場合は、前回の転職から3年が経っていた。 そのため、前職の上司となるとそれ以前に一緒に働いていたことになる。

    実際、私がレファレンス・チェックを依頼した元上司は、 一緒に働いたのが一人は5年以上前、もう一人は10年近く前にもなる。

    また、マネージャークラスとなると、普段から多くの人と顔を合わせているのもある。 この依頼した二人のうち一人は、コンプライアンス違反の件と記憶が曖昧という理由から、依頼を取り下げることになった。

    まあ、自分が他人の記憶に残るような仕事をしてこなかったというのもあるのかもしれないが。。。

    退職した人間をポジティブに評価してくれるのか?

    外資と比べて日経企業ではまだまだ転職による人材の流動性は低いと思われる。 そのため、そもそも退職していった人間をポジティブに評価してくれるのかという不安がつきまとう。

    ポジティブに評価するかはさておき、退職していった人間のために、 ただでさえ忙しいマネージャークラスの人に時間を取らせてしまうのも申し訳ない。

    最終的に自分がレファレンス・チェックを依頼したのは、 推薦者自身も転職して、当時の企業を離れている人達だった。

    まとめ

    私の場合は、運がよく推薦者を二人出すだけで済んだ。 それは、応募先企業の人事に、今回のレファレンス・チェックの件で散々文句を言ったことと、 二人の推薦者の両方がポジティブな評価を出してくれたからだ。

    やはり自分の運命を他人に委ねるのは気持ちのいいものではない。 一方の推薦者側も、他人の、ある意味人生を左右する、役回りを引き受けることには気負いしがちだ。 レファレンス・チェックの必要性は分からなくはないが、 特に(自己責任論の強い?)日本ではあまりやってほしくない方法だと思う。

    ただ、こういったケースにも対応できるように、 常日頃から全身全霊で仕事に向き合うべきということなのだろう。

    製造業のソフトウェアエンジニアを辞めました

    Image of software engineer working in Japanese traditional manufactures

    はじめに

    社会人になって10年余り、日本の製造業でソフトウェアエンジニアをやってきたが、2023年を以て辞めることにした。

    製造業とぼかしているのは、家電メーカーで8年、自動車部品メーカーで3年のキャリアをまとめて表している。

    社名を出すのは控えておくが、どちらも日本を代表する大企業ではある。 (自慢っぽく聞こえるのは勘弁してほしい。)

    いわゆる退職エントリーになるので、ネガティブなことも書くつもりだ。 ただし、曲がりなりにもお世話になった企業であるのと、特に2社目の自動車部品メーカーでは、

    「うちの評判を悪くするようなことをしたら許さんぞ!」

    という書類に、退職時にサインしているのもある。。。

    いろいろあったが、自分はモノづくりが好きだし、ソフトウェアエンジニアとしてのアイデンティティはこれらの企業での仕事を通して培ったのは間違いない。 ネガティブな印象もあるかもしれないが、彼らが世界に向けて製品をリリースして日本経済を牽引してきたのは、日本の誇りだとも思っている。 そんな環境で働けたのは貴重な経験だったと思っているので、自身の体験談や思うところを文字に残しておこうと思う。

    私自身のキャリア

    前回の記事でも書いたが、自分のキャリアを簡単に書いておく。

    • 2012: 某家電メーカーに入社
      • 組み込みSWエンジニアとしてキャリアスタート(2012~)
      • WEBエンジニアに転向(2016~)
      • アプリケーションエンジニアになる
      • AWSに触れる(2018~)
    • 2020: 某自動車部品メーカーに転職

    良かった点

    メーカーは上流工程のみで、基本的にソフトウェア開発はSIerに丸投げというイメージがあるかもしれないが、 幸運なことに自分はずっと内製開発の現場で働いてこれた。 その経験を通して良かった点を挙げてみる。

    優秀なエンジニアと一緒に働けた

    何といっても最初にこれが挙げられる。

    一言に優秀と言っても、イケイケのベンチャー企業や名だたる外資ビッグテックでも優秀なエンジニアと働けるチャンスはあるだろう。 それらと異なるのは、製造業のエンジニアの多くは組み込み系のエンジニアからキャリアをスタートしているところだ。

    組み込みソフトウェアはサーバーで動作するソフトウェアと比べて、使用できるコンピューティングリソースやプログラミング言語の制約がはるかに厳しい。 そのためメモリー効率やストレージ容量、IOのレイテンシー、プログラムやアルゴリズムのパフォーマンスなどにも配慮した開発を経験しており、 ソフトウェアやシステムの理解度がかなり高い人達はいる。

    中にはハードウェアや電子回路にも精通していて、 AWSなどのパブリックサーバーとRaspberry Pi、時には既製品の家電などを分解、改造して、プライベートでちょっとしたIoTシステムを作ってしまう人もいた。

    彼らと一緒に仕事ができたのは大いに刺激になったし、 自分が目指すエンジニア像は、そういった先輩に由来している。

    チャレンジャーとしての醍醐味

    日本の製造業は、実際かなりGAFAMのことを意識してビジネス活動を行っている。 ビジネス領域が彼らと競合しているからだが、当然資金力では外資ビッグテックには適わない。 しかしだからこそ、彼らが参入してこないマーケットを模索したり、彼らと戦える技術やビジネス戦略を磨いている。

    (ただし、大企業がリスクを取って、その戦略は実行に移すかは保証できないのだが、、、)

    実際、日本企業が提供する製品で、世界シェアNo.1をキープしている製品は少なくない。 私自身は、それを足掛かりにして、放送業界や建築土木業界などに関わる仕事にも恵まれた。

    日本の低い賃金事情もあり、外資ビッグテックで働くことは、エンジニア界隈では羨望になっていると思う。 ただし、それは海外の凄腕エンジニアが開発したサービスを後からメンテすることだったり、 言ってしまえば、既に強者となった企業をさらに強者に押し上げるに過ぎないともいえる。

    それより下剋上を目指した方が仕事として面白くないか、という話だ。 もちろん、これをどう捉えるかは人それぞれだし、下剋上ならベンチャーで働けよと言われればそれまでである。

    多彩な事業領域

    日本の製造業は歴史が長い分、事業の多角化を行ってきている。 そして、社員の流出を防ぐ目的で、そういった事業間の人材の移動を促す仕組みを導入している企業もある。 社外に転職されるぐらいなら、社内で人材を流動性させた方がマシという訳だ。

    私の場合はそういった社内ルールを使って、組み込みエンジニアからWEBエンジニアに転向することに成功した。 その際、会社が作った合弁会社への出向となったので、 大企業の給料をもらいながら、ベンチャーの環境で働くというユニークな機会にも恵まれた。

    私が在籍していた会社では、他にも金融や不動産、エンタメ分野の事業部への異動も可能だったと思う。 いわゆる社内転職になるが、一般的な転職よりはるかに労力は少なくて済む。

    欠点は、会社が変わるわけではないため、給料は変わらないことだ。 そこは外資系企業やコンサル企業への転職には適わないが、経験はプライスレスだ!

    徹底したソフトウェアの品質管理

    ソフトウェアの品質管理プロセスを経験できたことは、エンジニアとしての知見の大きなプラスになったと思う。 おかげで、開発業務において、品質管理まで先回りして意識したプランや試作を練られるようになった。

    常時ネット接続して利用するWEBサービススマホアプリと異なり、 組み込み製品では簡単にソフトウェア・アップデートができない。 後でバグに気づいても、簡単には修正できないのだ。

    そのため、製品リリースの際の品質管理は徹底している。 ただし、これはSQAにかける予算がなくて、開発エンジニアがある程度肩代わりしているためでもある。

    また、品質管理は徹底していても、プロダクトの品質が良くなるとは限らない。。。

    今の時代基準を考えると品質管理が「徹底し過ぎている」きらいもある。 アジャイル開発が主流の今日では、製品リリースに高いハードルを設定するよりスピーディーにバージョンアップしていくスタイルが好まれているように思う。

    最新ツールは使い放題

    お堅い日系大企業は流行りのツールの導入に慎重なイメージがあるかもしれない。 かつてはコードをGithubに上げようものなら、「うちのソースコードクラウドに上げるなんて言語道断だー!!」と吠える偉い人がいたらしいが、それも今や昔。 開発でお馴染みのツールは使い放題だった。

    • Github
    • Slack
    • JIRA/Confuluence
    • Zoom

    ただし、これは所属する組織や上司の意向にもよる。 これ以外にも、上司の意向でFigma, DeepL, Typora, JetBrains, Github Copilot, OnePasswordなどのライセンスも買ってもらえた。

    xtech.nikkei.com

    もちろん、ChatGPTの利用も許されていた。 会社の機密情報を入力しないことが前提だが、社会人たるものそれぐらいのコンプライアンス意識は持っている。

    トップダウン vs ボトムアップ

    製造業に限った話ではないが、トップダウンボトムアップ、それぞれの傾向の会社で働けたのは良い経験になった。

    家電メーカーの方はトップダウンだった。 仕事が次々と降ってくるので忙しかったが、経験値の低いビギナー社会人としては良かったと言える。 おかげで実戦経験は否応なしに増えた。

    自分が入社したときは、家電業界はリーマンショックのダメージから回復できておらず、 まさに株価が底を打ったタイミングだった。 そこから次々と施策を打ち、復活するにまで至ったのは一社員としても感慨深いものがある。

    働いていたときは、「この会社、何も変わってなくない?」とか同僚と話していたが、 退職してみた後で、すごい体験だったなと改めて思った。

    これに対して、自動車部品メーカーはボトムアップだった。 社員が有志で企画してエンジニアリング・コンペや労働環境の改善活動をしているのは、 トップダウン環境で馬車馬のように働らかされてきた身としてはものすごく新鮮だった。

    また、自分がいかに仕事に対して受け身な姿勢だったかも反省させられた。

    しかし、やはりトップダウンの企業の方が意思決定のスピードは速い。 家電メーカーで働いていたときは、そんなこと気づけなかった(むしろ遅いとすら思っていた)。 結局、仕事の早い遅いはマネージメントの問題なのだ。

    給料

    外資テック企業には及ばないが、 日本のエンジニアの給与水準から見れば高めの給料をもらえていた。

    特に家電メーカーの方は、自分が辞めたあとに株価が大きく上昇し、 社員の給料も大幅アップしたらしいので、退職タイミングを誤ったことが悔やまれた。

    先に転職していった先輩たちは、ほとんどが外資かコンサルに行った。 給料アップを目指すと、それぐらいしか行先がないのだ。

    自分は在籍中に家を購入できなかったが、 住宅ローンの審査もパスしやすいらしい。 銀行からの信用度も抜群だ!

    悪かった点

    どんな会社にも欠点はあるし、何はともあれ辞めてしまった身なので、 不満点も挙げておこう。 しかし、心なしか「良かった点」より項目数が多くなってしまった。。。 まあ愚痴なんてそんなものだろう!

    給料の伸びが遅い

    これは時代背景もある。 自分が入社した当時、家電業界は赤字続きでなかなか給料が上がらなかった。 そのため個人の努力で収入が上がる感覚がつかめず、自分の収入を上げるために、試行錯誤するマインドセットがなかなか身につかなったと感じている。

    「隣の芝生は青く見える」だけかもしれないが、 ベンチャーなどで会社の急成長にのって収入を上げていった人や、 副業を複数かけもちして収入を増やしている人の方がよっぽど逞しいと想像する。

    あくまで想像なのだが、そういう人の方が最終的には早く資産を築けそうだ。

    アプリ軽視がひどい

    製造業2社で働いたが、アプリ軽視の傾向は本当にひどかった。 ここでいうアプリとは、クライアントアプリケーション、すなはち、ユーザーとの接点になるブラウザアプリやスマホアプリ、ユーザーインターフェース、フロントエンドなど全般を指す。

    家電メーカーでは、アプリ開発エンジニアを評価する文化がそもそも無かった。

    この会社の製品は、昔からユーザーから「使いづらい」と文句を言われてきてたので、 アプリに投資しないのはもはや伝統だった。 元々のハードウェア偏重の文化もあり、ソフトウェアに対しても「下回り(機械学習アルゴリズム、バックエンド)をやっている人の方が偉い!」という明確なヒエラルキーも感じられた。

    しかしこれはある意味正しい。 実際、巷でも機械学習エンジニアやデータサイエンティストが高給をもらっている。

    私自身は、WEBエンジニアになったときに、アプリ開発からスタートしたこともあって、それ以降もアプリ開発を任された。 しかし、他の社員もアプリ開発は”できない”、”やりたくない”、なので、押し付け合いの感が否めず、 結局、これが会社を辞めるきっかけになった。

    自動車部品メーカーの方はそういうギスギス感はなかったものの、 アプリ軽視の姿勢は同じ、というより彼らは完全にアプリを舐めていた。

    簡単にアプリが作れると思っているらしく、 「UI、3日で作って。よろしく!」みたいなことを平気で言われることがあった。

    また、理解がないくせにやたらとアプリを欲しがるのも困りものだった。 理由は顧客へのデモで見せたいからなのだが、そこにビジョンは何もない。 「とりあえず何か動くもの」「とにかく顧客の気を引くもの」がほしい程度のモチベーションで言ってくるので、要求は雑そのものだ。

    ただ逆に言えば、細かいことは何も言われないので、好きに作れるというメリットもあったといえばあった。

    詰め込み過ぎのプレゼンテーション資料

    製造業に限った話ではないかもしれないが、社内のプレゼン資料は徹底的に情報が詰め込まれたものが好まれた。 完全にプレゼンのアンチパターンをいっているのだが、どうやら全ての情報が書かれていないと気に入らないらしい。

    さらに言うと、複雑なワークフロー図やアーキテクチャー図のようなものを示すことで「仕事をやってる感」を示しているようでもあった。 毎回「ビジーなスライドで申し訳ありませんが、、、」といって資料を見せているマネージャーもいたが、 その複雑さたるや、まさに「モダンアート」だった。

    面倒なのは、そういった資料作成をこちらにも押し付けられることだ。

    以前にUdemyで、孫正義のプレゼン資料を作っていたという前田鎌利氏の講座を受けたことがあった。

    academy.president.jp

    前田氏によると、プレゼン資料作成の極意は、「常に見る人の視点に立った資料作成を行うこと」とのことだった。 それに沿うなら、彼らの資料は見る人のことなど考えていない。 自分がたくさん仕事をしていることを見せつけられれば、それでいいのだ。

    優先順位をつけられないマネージャー

    労働生産性が主要国最下位だけあって、日本人は優先順位付けが苦手なイメージがある。

    家電メーカーはトップダウンの企業だけあって、「あれもやれ、これもやれ、全部やれー!!」とひたすら圧をかけていた。 当然疲弊してしまう社員も多くいて、優秀で真面目な人ほど休職してしまう、そんな職場もあった。

    自動車部品の方は、「あれもいいね。これもいいね。よし全部やってみようか!」という感じだった。 こちらが優先順位付けや星取表を持って行ってもあまり意味が無かった。

    昔から「日本製品は品質がいい」と言われてきた。 それは、値段の割に機能がたくさん盛り込まれていることを意味していたのだと思う。 しかし、それは意図してそうなったのではなく、優先順位をつけられず手あたり次第にぶち込まれただけなのかもしれない。

    対外発表の機会はほとんど無い

    大企業あるあるだが、対外発表に対してものすごく高いハードルが設定されている。

    技術にオープンなチームでも、社内手続きが面倒過ぎてあきらめてしまうケースも何度か見た。

    また、対外発表したい旨をマネージメントに話しても、「なんでそんなことするの?」と、 そもそも対外発表の意義を理解できない偉い人も少なくない。

    会社の機密を守りたいのもあるのだろうが、彼らは他社と競争することを恐れているのだと思う。 特に自動車業界はお世辞にもビジネス活動のスピードが速いとは言えない。 他社と競合していることが知られたり、真似されでもしたら、ひとたまりもないのだ。

    対外発表は会社としても実績アピールや認知度の向上、採用促進につながるし、個人にとってもキャリアに箔がつく! そういう経験を求めるなら、やはり純粋なソフトウェアカンパニーに行くべきだろう。

    Brilliant Jerk

    Brilliant Jerkという言葉をご存じだろうか? 優秀だけど、人間性に問題があり、チームをはじめ周りに悪影響を及ぼす人を指すのだが、 日本のエンジニアには特に多いとされている。

    家電業界にいた頃は、まさにBrilliant Jerkと思われる人を何人も見た。 自分が在籍した会社は、かなり技術をリスペクトする風土があったが、 リスペクトするあまり、技術力がある(と思われる)人がやりたい放題するのを許してしまうところがあった。

    私が知っているBrilliant Jerkの一人は、海外留学から帰ってくると、とてつもなく横柄になり、 課外活動をやりまくった挙句、外資に転職していった。

    彼らは基本的に相手を論破するのが大好きだ。 また、コードレビューをするのも、されるのも嫌がる。 そのため、若手の頃は先輩にコードレビューを依頼するのが至難の業だった。

    嘘っぱちのソフトウェアファースト

    「ソフトウェアファースト」という言葉をご存じだろうか? 少なくとも日本では、元Google及川卓也氏の著書が起点になっていると思う。

    ソフトウェア・ファースト

    type.jp

    ソフトウェアファーストをざっくり言うと、 「ソフトウェアを自社でコントロールする能力を持つことが、これからのビジネスの主導権を持つことにつながる。そのためにソフトウェアを内製化しましょう。」 というコンセプトだ。

    電気自動車や自動運転が話題になり、 自動車業界ではこの「ソフトウェアファースト」がバズワードになっているのだが、そのままの意味では用いられていない。 あくまで「ソフトウェアが中心的な役割を担う自動車やモビリティサービス」という意味で用いられている。

    多重下請けの権化の自動車業界が「ソフトウェアファースト」を実践すると、業界そのものが崩壊するのだ。

    製造業のソフトウェア外注にはちょっとした歴史があって、 2013か2014年頃にオフショアブームが起こった。 大手IT企業の真似をしてソフトウェア開発を人件費が安かった中国、インド、ベトナムなどの企業に外注しようとしたのだ。 その頃は、「日本のエンジニアは手を動かす業務から離れ、マネージメントに集中すべきだ!」 という考えがまことしやかにささやかれた。

    しかし、その結果はオフショア先が出してきたバグだらけのコードを日本人エンジニアが必死になってデバッグする負のスパイラル。 全く効率的でないことに気づき、オフショアは下火になった。

    ところが、自動車業界はここから立ち直れなかったらしい。 私が在籍した自動車部品メーカーでも、ソフトウェアを内製化しようという声は上がったし、 何なら及川氏を招聘して社内講演までやっていた。

    しかし、ソフトウェアの内製化は、反対派がうにゃうにゃ言って全く実現しない。 自分達が開発するとコストがかかるというのが彼らの意見だ。 彼らには、ソフトを内製化するテスラがぶっちぎりで高い利益率を叩き出しているのが見えないらしい。

    根強く残る昭和の文化

    先日、知人から『不適切にもほどがある!』というドラマが面白いと聞き、見てみた。

    www.tbs.co.jp

    このドラマは、昭和の人間が令和にタイムスリップしてくるというストーリーで、 ある意味極端な、昭和の古き悪しき文化を面白おかしく描いている。

    その一例として、阿部サダヲ演じる、野球部のコーチである主人公が、部員全員にケツバットをするシーンが出てくる。 部員の一人が練習中に水を飲んだことの罰として、連帯責任という理由で部員全員を並ばせてケツバットをしていくのだ。

    詳しくは語るつもりはないが、、、 私が在籍した自動車部品メーカーでも同じようなことが行われていた。

    断っておくと、体罰や言葉の暴力があった訳ではないし、そういうことが頻繁に行われている訳でもない。 ただし、この「連帯責任」は令和のこの時代でも好まれているようだった。

    その理由としては、「組織で起こったトラブルを他人事と思わず、全員が教訓にする」ことを推奨しているからなのだが、 責任の所在をあやふやにする効果もあるのかもしれない。

    私が経験したのは、同じ組織内の数人がトラブルを起こし、それをきっかけに50名以上いる社員全員が罰ゲーム的なこと(社会奉仕活動みたいなやつ)をさせられるというものだった! そこまで苦痛や辱めを伴うものではなかったし、あまりの時代錯誤に唖然としてしまったのもあって誰も何も言わなかった。 しかし、今の価値基準に照らし合わせれば、余裕でパワハラだろう。 まさに「不適切にもほどがある」だ。

    最近のニュースに思うこと

    つい最近まで自動車業界で働いていたので、 今話題の自動車業界の不正について思うところがある。

    www.itmedia.co.jp

    私が働いていた会社は件の2社ではないし、 自分の周りで不正が行われていた様子もなかった。

    しかし、ダイハツへのインタビューで目についたコメントがあった。

    www.asahi.com

    「ト〇タの期待に応えることが最優先だった」

    これは私がいた会社でも同じだった。

    また、似たことが書かれた記事もあったが、 プロジェクトマネージャーが社外(OEM)にいて、社内でのプロジェクトマネージメントが機能していないケースもあった。 PM不在のプロジェクトは当然カオスになるのだが、マネージメントからすれば責任の所在が不明確な方が良かったのかもしれない。

    おそらく、私のかつての同僚たちは今回の件を受けて、Eラーニングのコンプライアンス研修でも受けさせられているだろう。 しかし、問題はそこではない。 法律やルールを犯してはいけないことぐらい誰だって知っている。

    あくまで個人の感想であり、もちろん一部の人間に限った話だが、 彼らには主体性や自立心がまるでないのだ。 上司のため、顧客のためなら自身の損得を顧みず、(時に犯罪レベルの)自己犠牲を取ろうとする。

    その辺は家電業界も負けていなかった。 私が経験したいくつかの部署では、「上司の言うことは絶対です!」と吠えている社員が必ず一人はいた。 彼らは上司に「死ね」と言われれば、喜んで死ぬのだろう。

    bestcarweb.jp

    xtech.nikkei.com

    自動車業界がこの不正から脱却できるのかだが、おそらく無理だろう。 これらの会社では、既に過度な自己犠牲を厭わない社員を評価し、昇進させ、高い給料を払ってきたはずだ。 今さらそれらが全て間違いだったから、地位もお金も全て返してくださいとはならない。 それに今は株価も絶好調だ。

    ほとぼりが冷めれば、彼らはまた得意の自己犠牲を、したりさせたりするのだろう。 私が製造業で学んだことの一つは、 「法律やルールは書き換えれば変わる。しかし文化を変えるのはかなり難しい。それがたとえ悪い文化でも」だ。

    今後について

    思いのほかダラダラとした感想と10年分の毒を吐いてしまったが、 こういうのも含めて「君たちはどう生きるか」が問われているのだと思う。

    特に「主体性」は重要なキーワードだ。 及川氏の「ソフトウェアファースト」が言うようにソフトウェアは個人においても、企業においても主体性を確立する重要なツールだと思っている。 転職はしたが、これからも私のエンジニアライフは続くので、自身の主体性を確立するべく努力していきたい。

    大企業勤務のエンジニアが1年の副業を終えて

    昼は本業、夜は副業

    はじめに

    2023年の一年間は副業を始める機会に恵まれ、12月をもって終了しました。

    本業では大手の自動車部品メーカーでソフトウェアエンジニアとして働く傍ら、スタートアップでもクラウドサービスのバックエンドエンジニアとして働き、とても貴重な経験を得られたと思っています。

    副業関連の記事は既にたくさんありますが、それでもサラリーマンの副業経験者は全体の1~2割程度! まだまだマイノリティーですので、私の体験談をまとめておきたいと思います。

    www.nikkei.com

    自分のこれまでのキャリア

    これまで日系の大手製造業で10年あまりソフトウェアエンジニアをやってきました。内訳は家電メーカーで8年、自動車部品メーカーで3年になります。

    • 2012: 家電メーカーに入社
      • 組み込みエンジニアとしてキャリアスター
    • 2016: Web系エンジニアに転向
    • 2018: 新規事業の立ち上げに参加
      • AWSに触れる
    • 2020: 自動車部品メーカーに転職
      • Webアプリ開発、データ分析、リーダー業務など
      • 新規事業のPoC活動

    家電メーカーの方では、社内転職制度が充実していたこともあり、組み込みソフトウェア・エンジニアからWeb系エンジニアに転向、会社が立ち上げたジョイントベンチャーで働く機会にも恵まれました。

    副業をはじめたきっかけ

    副業について調べ始めた

    2022年に副業をやってみたいと思い、いろいろ調べていました。Offersなどの副業マッチングサービスに登録して、いくつかの企業とカジュアル面談をしたこともあります。

    しかし、当時はこれらのサービスを通して出会えた企業が求めていた人材像は、

    • 週5日コミットしてくれること
    • 将来的に正社員になることを念頭に、まずは副業でジョインしてもらえること

    を条件としていました。

    あくまで本業の仕事をキープしつつ、それ以外で自分のエンジニアリングスキルを試したい、収入の手段を増やしたいと思っていた自分にとっては受け入れがたい条件でした。

    また、副業について調べつつも、週に数日働くだけで十分な成果を出せるかを懸念していました。本業での経験からエンジニアの仕事が少ない稼働時間でこなせるものだとは到底思えませんでした。

    知人からの紹介(結局は人脈?)

    そんなことから半ば副業を諦めかけていた時、知人から副業をやってみないかと紹介を受けました。

    副業を紹介してくれた知人は元々ベンチャーキャピタル関係の仕事の経験がある方で、 関わっている会社の同僚が起業して、エンジニアを集めているということでした。

    atmarkit.itmedia.co.jp

    事前情報として、起業メンバーもいい人たちだと聞いていたので、安心して参加することができました。

    副業を通して得られたこと

    副業を始めるにあたっての手続きや準備については割愛します。

    自身のスキルが本業以外で通用したこと

    晴れて個人事業主となり、紹介していただいた企業と業務委託契約を結びました。

    私は週8時間で契約を結びました。

    既に書いたように週8時間で成果を出せるか非常に不安でしたが、幸い開発対象のサービスがReact/Material-UIと、これまで何度となく開発してきた構成でした。

    稼働時間が少ないため、ある程度割り切って、最初は不具合修正から着手。 自分がこなせるタスクを見積もり、できない部分は初期解析結果や必要な手順を明らかにして、他のメンバーに引き継げるようにしました。

    プロダクト開発が次のフェーズに入り、開発体制を刷新する段階になって、人手が足りていなかったバックエンドチームに参加。元々、バックエンド開発の経験を充実させたかったため、願ったり叶ったりでした。

    そこでも、本業で触っていたAWSのIaCやTensorflowの知識を活かすことができ、プロダクトの実現に貢献することができます。

    こういった成果が出せた背景は、契約した企業がSlackやタスク管理ツールを使った情報伝達の基盤を確立してくれていたこと、中心になって舵取りをしてくれるエンジニアがいたおかげもありました。

    それでも、今回副業を終えるにあたって、少ない稼働時間で成果を出せた点については高く評価していただけました。自分にとっても大きな自信につながったと思います。

    フリーランスエンジニアと交流できたこと

    優秀な方と仕事ができたことも大きなメリットだったのですが、コロナ禍を経て自由な働き方をしているエンジニアと知り合うことができたのは大きな収穫だったと思っています。

    今時のスタートアップではよくあることなのかもしれませんが、所属するエンジニアのほとんどが副業で参加していました。その全員がリモートで開発をしており、中には沖縄や長崎に移住している人もいました。

    note.com

    toranoana-lab.hatenablog.com

    私自身は製造業で働いてきたこともあり、完全にリモートで働くというのは想像しづらかったです。 特にハードウェアが関わる仕事になるとまず無理です。

    やはり身近な人間で新しい生活スタイルをしているのを知ったことで、自分の価値観や人生の選択肢も広がったと思います。

    スタートアップのスピード感を実感

    具体的に言えば、”自分の仕事の成果がすぐにビジネスに反映される感覚”です。

    これはエンジニアリングのみの力ではなく、営業力やビジネスモデルもあっての結果ですが、最初にPoCから始まって顧客が1社、2社と順調に増えていきました。

    また、開発しているサービスがテレビで取り上げられたこともあり、単純ですが胸を張る思いでした。

    当時、本業の方ではPoCをやろうとして、なかなか顧客が見つからなかったり、見つかっても最終的には利益に繋がらなかったりと不完全燃焼な状態が続いていました。 そこには大企業ならではのスピード感の無さやリスクを回避しがちな姿勢が理由としてあったと思います。

    そういった背景から本業より副業の方がやりがいがあったと思います。何より契約先のスタートアップは本気で上場を目指してましたので、成功に対するモチベーションも高かったです。

    自分のパフォーマンスを引き上げられた

    人間、追い詰められないとなかなか動かないもので、 責任を課せられずに、プライベートの時間にここまで開発タスクをこなせなかったと思います。

    自分は週8時間契約で、基本的に土曜日に副業のタスクをこなしていました。 たった一日ですが、それでも貴重な休日のうち一つを使ってしまうため、プライベートでやらなければならない雑務や手続きなどに手が回らなくなるフラストレーションはありました。

    これは他の人も同じらしく、同じく副業で参加していたエンジニアやデザイナーの中にも、副業をやめて本業に集中することにした方や、社員としてそのスタートアップに参加することを決意した方もちらほら見られました。

    一方で、生活の中でやらなければならないことや普段の過ごし方を、効率化したり、切り詰めたりすることで、より生産的に動けたことが一つの発見だったと思います。

    実際、他の副業エンジニアの中には、本業で週5日勤務しつつ、副業で週24時間契約をしている方もいました。 どうやって時間を確保しているのか聞いたところ、土日で16時間確保し、残りの8時間は平日の朝か夜に働いているとのことでした。 なかなか真似できるものでもありませんが、それぐらい頑張っている人がいることを知れたのも、大きな刺激になりました。

    私の知人には、夜9時に寝て朝3時に起き、個人事業を行っている人もいます。

    副業やリスキリングが叫ばれていますが、それを成す上で必要不可欠なタイムマネージメントを考えるきっかけになったと思います。

    なぜやめるのか?

    ここまでポジティブに書いてきた副業をやめることにしたのは、本業で転職することになったためです。 転職先の企業が副業を許しておらず、フリーランスエンジニアの肩書は捨てることになりました。

    今後

    計らずも副業をやめることになってしまいましたが、逆に副業をやっていたがためにできなかったこともあります。

    1. 今回の副業中に求められたが、自分にスキルがなくできなかった技術分野

    2. 個人開発、書籍執筆など無形資産の形成

    3. 金融資産の形成

    自身にスキルがなくできなかった技術開発は、主に機械学習周りの知見になります。 私はバリバリの機械学習エンジニアという訳ではありません。しかし、今回の経験でどういったところに需要があるのか、機械学習アプリを運用する上でどのようなマネージメントが必要になるのかなど知ることができました。 これを機会に勉強したいと思っています。

    二つ目の無形資産の形成は、エンジニアとしてやっておきたいことの一つですし、自己ブランディングも含んでいます。

    副業はやめてしまいましたが、収益を得られないからこそできることもあります。

    ライフピボット 縦横無尽に未来を描く 人生100年時代の転身術 できるビジネスシリーズ

    この書籍でも紹介されていますが、プロボノNPO活動など、副業でなくても自身のスキルをアウトプットする手段はたくさんあります。

    一応、2023年には個人開発で一つ目のプロダクトのリリースは達成しました。

    trycycler.hatenablog.com

    しかし、まだまだ満足していません。これも収益を上げるところまでは成し遂げたいと思っています。

    最後の金融資産の形成は、今までもやってきたのですが、インデックス投資に積み立てるだけのほったらかし運用です。

    折しも新NISAが始まり、投資可能枠も大幅に拡大しました。副業収入が無くなることもあり、投資プランを再考したいと考えています。

    まとめ

    抽象的ですが、副業をやって最も良かったことの一つは、行動した分だけ自分の収入を増やせる感覚をつかめた点だと思っています。

    私が社会人になったとき製造業、とりわけ電機業界は赤字にあえいでいました。そのため長い間、給料はなかなか伸びず、個人の行動のみでビジネスを成長させ、収入を増やすことは難しいと思い込んでいました。

    しかし、副業が解禁されて個人がビジネスをしやすくなったことで、自身の仕事やキャリアのマネージメントを会社の枠組みを超えて考えるきっかけになりました。

    一方で、労働集約型の仕事を本業と掛け持つのはなかなか厳しいというのも現実です。知識集約型のビジネスで稼ぐ割合を増やしていくことを目指したいです。

    医者に〇されかけた話

    はじめに

    今年、自分に実際に起こった出来事で、医者との向き合い方を改めて考えさせられた話になります。

    実は、去年に胃腸を悪くしてしまい、それ以来、症状を抑える薬を飲んでいます。幸い、胃腸の方は問題なく正常を維持しているのですが、薬を飲み始めて2カ月後に受けた人間ドックで心臓の不整脈が見つかりました。

    そこで主治医に相談して循環器内科を受診したところ、いきなり心臓手術を勧められ、かなり戸惑いました。

    結果的に、心臓手術は全く必要ないことが分かったのですが、そこに至るまでの経緯を記しておこうと思います。

    いきさつ

    最初の違和感

    今思えば、最初に感じた違和感が功を奏したと言えます。 循環器内科を受診し、不整脈の具合を確認するため、ポータル心電図によって24時間の心拍状況をモニタリングしました。

    ポータル心電図の結果で最初に言われたのは、「心臓が2秒以上止まっているタイミングが1日のうちに2万回以上起こっている」でした。

    この半年後、再びポータル心電図をしたのですが、症状はよけいに悪くなっていました。1日の不整脈の回数は5万回ぐらいに増えていたと思います。

    当初から言われていたのは、"カテーテルアブレーション"が必要かもしれないということです。

    カテーテルアブレーションとは、足の付け根あたりからカテーテルと呼ばれる電熱線がついた医療器具を心臓まで挿入していって、問題のある部位を焼きつぶす手術です。

    カテーテル手術の同意書

    心臓の部位に直接処置をするので、心臓手術ということになります。もちろんリスクもあって、全く改善しなかったり、余計に不整脈がひどくなる場合や、手術中に問題が起こって心臓外科のICUに運び込まれることもあり得ます。

    不整脈に関しては、多少自覚症状はあったものの、生活に支障は出ていなかったので、これには面喰いました。そこにやたらと心臓手術を勧めてくるので、「何かおかしくないか?」という漠然とした違和感を感じていました。

    ちなみにこの時の担当の医師からは、「次に来るときはご家族にも同席してもらって...」とまで言われました。余命いくばくかを宣告されるときのお決まりのセリフです。

    セカンドオピニオン

    いろいろ悩んだ末、不整脈の専門医に相談してみることにしました。とは言っても、誰に相談すればいいか分かりませんし、紹介状もありません。 そこで、不整脈に関する本を購入してみました。

    -動悸・ドキン・胸のつまり感・息切れ・めまい- 不整脈 脈飛び 頻脈・徐脈 期外収縮 心房細動 最新最強脈正し自力克服大全 (健康実用)

    最初は医学的治療を用いずに何とか改善できないかと思って選んだ1冊でした。この本に寄稿している医師で、近場に医院を運営している方に予約を入れて、相談してみました。

    相談してみたところ、その医師はなんといっぱつで、胃腸の治療に飲んでいる薬の副作用ではないかと指摘してくれました。

    調査

    セカンドオピニオンの結果を受けて、自分が飲んでいる薬の副作用について調べてみました。今では医薬品の情報はインターネットで簡単に調べることができます。

    医療用医薬品 : リアルダ (リアルダ錠1200mg)

    不整脈とは明確に書かれていないものの、以下のような記述を見つけました。

    胸部痛、心電図異常、胸水等が認められた場合には、投与を中止するなど適切な処置を行うこと。

    また、Ask Doctorというオンラインで医師に病状を相談できるサービスでは、私と同じくリアルダという薬を服用して、動悸が激しくなったと言っている人も確認しました。

    主治医の対応

    自分が見つけたウェブサイトの資料をコピーして、主治医に別の薬に変えてみたいと相談しました。 正直ここでごねられたら、病院を変えるつもりでしたが、

    • 不整脈が見つかったのが、薬を飲み始めてまもなくであったこと
    • それまで、不整脈を疑われたことなどなかったこと
    • 私が持って行った資料に書かれた副作用の情報

    これらを根拠にすんなり薬を変えてくれました。

    この2か月後に受けた人間ドックでは、不整脈は確認されませんでした。

    不整脈を診断した医師の対応

    再びポータル心電図を行い、循環器内科の医師からその結果の説明を受けました。 結果、不整脈はほとんどなくなっていました。

    私が、「服用していた薬の副作用の可能性があり、別の薬に変えた」という旨を説明したところ、

    「あれだけあった不整脈がほとんどゼロになったということは、薬の副作用で間違いないですね」

    と言っていました。

    しかし内心では、「心臓手術をあれだけ推していたやつが何言ってるんだ!?」と穏やかではありませんでした。

    検証

    薬の副作用に気づけない主治医

    まず愕然としたのが、私の主治医の薬や情報に対するリテラシーの低さです。

    私が服用している薬の副作用の可能性があることを、胃腸の方の主治医に相談したとき、その医師は書棚から"薬の百科事典"のような古臭い本を1冊取り出して、副作用の欄に目を通しました。 そして、

    「心筋炎や心膜炎は書いてあるけど、不整脈なんて一言も書いてないよー」

    と言っていました。

    しかし、仮にも心臓に何かしらの副作用が起こりうる薬を処方しているのですから、そこに考えが及ばない時点で医師として力量不足ではないでしょうか。

    ちなみに、私が見つけた薬の情報は「リアルダ(薬名) 副作用」でgoogle検索すれば上位1~3件にヒットします。この程度の情報にもアクセスできていない医師に不安を感じずにはいられませんでした。

    心臓手術の実績が欲しかった?

    私が通っていた病院は、2021年に不整脈専門の部門を立ち上げていたことが分かりました。 実際、手術の説明を受けた時にも、最新の機材が揃っていることを強調されました。

    カテーテル手術は比較的安全な手術ではあるようですが、それでも患者視点では、実績のある病院に任せたいものです。

    また他の医療関係者からは、心房細動という症状が無い限り、カテーテル手術は必要ないという意見も聞きました。担当の医師からは心房細動の説明がほとんど無かったです。

    今回あまりにも手術を勧められたので、手術実績が欲しかったのではないかと勘繰らずにはいられませんでした。

    医師の経済事情

    セカンドオピニオンを求めた医師に、手術をやたら勧められていることを言ったところ、次のようにおっしゃっていました。

    「大きな病院では、薬出して、手術しないとお金にならない」

    また、知り合いの医療関係者に今回の件について話したところ、こうおっしゃっていました。

    「医師は病院から、とにかく病床を空けるなと言われている」

    確かに、自分も会社勤務をしていて、お金が大事なのは分かっているのですが、そのためにモルモットにされるのは言語道断です。

    希少なケースだった?

    ここまで医師に対して批判的な内容を書いてきたが、医師に対して同情できる部分はあります。

    実際、私が行っている病院では、いつも外来患者が待合室で列をなしています。医師からしても、一人ひとりの患者の病状から処方している薬の副作用までを細かく把握することは不可能でしょう。

    また、私が調べた範囲では、明確に副作用として不整脈と記載された資料はほとんど見つかりませんでした。 私自身もここまで重大な薬の副作用を経験したことは無かったため、気づくのに遅れてしまいました。医師からしても希少なケースだったのかもしれません。

    医師との向き合い方

    病院を変えるか?

    今回のことを受けて、病院を変えようかとも考えましたが、思いとどまりました。この記事で病院名を公にするつもりもありません。

    そう考えるに至ったのは、医師が生活習慣病に対応するには限界があることを思い知ったからです。

    感染症ならウイルスや病原菌を除去することで治せます。たとえ、それが難しかったとしても、ウイルスを殺すことができれば治るはずです。

    しかし、生活習慣病はそうもいきません。生活習慣病の原因は患者の生活習慣や体質です。これらを治せるのは医師ではなく患者自身です。

    医師からすれば、患者個々人のそういった状況を細かく把握することは不可能でしょう。 特に総合病院の医師は、医療の専門家ではありますが、個々の病気の専門家でもないし、薬の専門家でもありません。いわばジェネラリストだということです。

    今後の医師との付き合い方

    重要なのは、それを前提として医師の言葉を過信しないことです。

    とりわけ生活習慣病にかかってしまった場合、医師任せにするのではなく、自身で病気について情報収集し、自分に合った治療法を模索する必要があります。

    社畜サラリーマンが個人開発でプロダクトをリリースするまで

    はじめに

    先日、個人開発で作ったAlexa Skillをリリースしました! その名も「経済指標カレンダー」です。

    Amazon.co.jp: 経済指標カレンダー : Alexa Skills

    実は前々から、個人開発で作ったサービスをリリースすることに憧れを持っていました。 小さな目標ですが、それを一つ達成したことになります。

    技術的な内容はQiitaで記事にして公開しているので、 今回は初めての個人開発を経て、得た教訓や苦労を中心にまとめたいと思います。

    とはいえ、苦労話として技術面のトライアンドエラーの話は避けては通れないので、 時間が無い人は得た教訓の章まで読み飛ばしてください。

    プロダクトについて

    今回リリースしたAlexa Skillは、その日に発表される経済指標を教えてくれるとサービスです。 普段、FXをやっているのですが、米国雇用統計などの大きなイベントをついつい見逃してしまったり、 イレギュラーな日程での発表に翻弄されたりといった経験から、着想を得ました。

    まずはMVPとしてリリースしているので機能は至ってシンプルです。

    • 当日発表される経済指標を列挙するのみ
    • 対象の国は米国、日本、英国、欧州、インド、中国、豪州などメジャーな国に絞っています
    • 5つずつ指標を発話するようになっていて、続きの発話は「はい」「いいえ」でコントロールできます

    開発の過程

    サービスを支えるシステム全体は以下のようなシンプルな構成です。 構成はシンプルですが、リリースまでの過程で意思決定や試行錯誤に多くの時間をかけてしまいました。

    アーキテクチャ

    アイディア出し

    個人開発をやってみたいとは前々から考えていて、アイディアは複数ストックしてありました。 しかし問題だったのは、自分が作りたいものに開発難易度が高い要素を含めてしまうところ。

    作るからにはオリジナリティを求めてしまうものです。 そうなると、まだ世界に無いものということになるので、自分の技術レベルを超えていたり、開発に時間がかかるものだったりして、結果的に先に進めなくなってしまっていました。

    Alexa Skill にしようと思い至ったきっかけは、会社の後輩が簡単なアプリをリリースして、AWSから無料のクーポンをもらったという話を聞いたことでした。 そんなキャンペーンはとっくに終わっていた訳ですが(笑)。

    UIを作らなくていいところにも惹かれました。 普段の仕事でフロントエンドの開発を多くしていたので、UIを作るとなると職業柄のこだわりが出て、時間がかかってしまうイメージをしていました。

    技術選定

    最も苦労した点が技術選定や実現性の検討でした。

    機能はまだ少ないので、サービス自体の実装量は多くないです。 そのため、技術選定や実現性検討にほとんどの時間をかけていたと思います。

    ざっと挙げると以下のような検討項目がありました。

    • 経済指標の情報の取得方法
    • 経済指標の和訳方法
    • AWS Lambdaで経済指標を取得する方法
    • Alexa SkillからDynamoDBへのアクセス方法
    • DBスキーマの検討
    • Alexa Skillの実装方法
    • サービスのホスティング方法
    • サービスのデプロイ方法
    • etc

    経済指標の和訳

    例えば、経済指標の和訳が課題の一つでした。

    機械翻訳サービスはいくつもあるのですが、経済指標という特殊なワードを上手く和訳してくれませんでした。 Google翻訳Amazon Translate、DeepLを試してみて、最も上手く和訳してくれた Google 翻訳を選定。 しかし、Google 翻訳も常に完璧ではなく、特定の指標は上手く訳せませんでした。

    経済指標名 機械翻訳結果 正しい和訳
    Fed Chair Powell Speaks パウウェルFRB議長が語る パウウェルFRB議長発言
    6-Month Bill Auction 6カ月請求書オークション 6カ月債入札

    データベースに辞書テーブルを用意しているのはそのためです。

    経済指標の種類は有限だと想定して、一度翻訳した単語は辞書テーブルに保存して、間違った和訳は後で修正できるようにしました。 上手く訳せない指標はだいたい決まっています。 上記の例でいうと、"Speaks"や"Auction"といった単語を含む指標です。 手作業ではありますが、データベースに登録することで、これらの指標を検索して一括で修正して、下手な和訳が発話されないようにしました。

    サービスのホスティング/デプロイ

    Alexa Skillのホスティングやデプロイ方法も検討に時間を要した項目の一つです。

    AWS ではよくあるのですが、デプロイ方法やホスティング方法が複数用意されていて、全部試してどれが最適か検討しました。

    • Hosted your skill code by Alexa
    • AWS with Cloudformation
    • AWS Lambda
    • AWS Codestar

    Amazonとしては Alexa Skillはお手軽アプリと想定しているためか、そこまで取り回しが効くものも無いように感じました。 デプロイ先の環境情報がコンフィグファイルとして含まれてしまうので、複数環境を用意しづらいことや、 これらをGithubで管理することにセキュリティリスクが懸念されることなどから、納得いく形を模索しました。

    また、ソフトウェアエンジニアという職業柄、CI/CDパイプラインを作れる余地を作っておきたいとか、Github Actionsを使ってみたいとか考えてしまい悩みましたが、 結果的に Cloudformationを使ってデプロイし、自分の AWS アカウントでホスティングする方針に決めました。

    要件定義

    要件定義で課題になったのは、VUIの設計とリリースまでにどこまでの機能を含めるかです。

    元々は経済指標の予測値と結果も発話することや、当日だけでなく次の日に発表される指標も発話できるようにするなども考えていました。 また、重要度を考慮しなければ、一日に発表される経済指標は雇用統計やCPIといった有名どころ以外にもたくさんあり、どの指標をどのように発話させるかも決めなくてはいけませんでした。

    結果的には、初回リリースは最低限の機能に絞ることにして、現在の形に落ち着きました。 このままだといつまでもリリースできないことを悟ったんですね。 ここは、普段の仕事と同じ感覚でできました。

    リリース準備

    Alexa Skillの開発だけで済めば楽なのですが、プロダクトとしてリリースするには見栄えも必要です。

    • アイコンの作成
    • 利用規約、プライバシーポリシーの作成と公開

    デザインの知識などないので、アイコン作成となると身構えてしまうのですが、 今回は話題の生成 AI を利用して簡単に作ることができました! 方法は Qiitaの記事にまとめてあります。

    qiita.com

    他のAlexa Skillを見ると、利用規約やプライバシーポリシーが無いものもあるのですが、 何せ金融や経済に関わるサービスではあるので用意することにしました。

    利用規約などの公開はGithub Pagesを使おうと前々から決めていました。

    smallriver0316.github.io

    仕様にクセがあり、ここでもトライアンドエラーは必要でしたが、 web デザインの知識がなくてもマークダウンで手軽にページを作れることやデザインテンプレートを利用できることから、 それらしいページを作成することができました。

    今は利用規約とプライバシーポリシーを載せるためだけのページになってますが、 もう少しサービスをアピールできるページにするつもりです。

    今回の経験で使い方はマスターしたので、 別のサービスの公開時や自分のポートフォリオサイトの作成などに活用していきたいです。

    リリース結果

    満を持してスキルの公開申請をしたところ、なんと一発OKでした!

    ロケールの自動公開は失敗とありましたが、元々日本でしか公開していないので無問題です。

    リリース後の集客

    あまりブログを頻繁に書けていなかったのですが、 個人開発のプロダクトリリースを経て、技術系の記事を3本も書くことができました。

    qiita.com

    qiita.com

    qiita.com

    実を言うと、この記事自体も宣伝活動の一環です。

    会社ではそれなりに頑張ってきたつもりでしたが、個人としてのブランド力はまだまだです。 サービスの利用者を増やすためにも、これを皮切りに頑張っていきたいです。

    得た教訓

    アウトプット活動が苦手な手前、今回の開発経験では多くを学びました。

    時間管理

    結局、一番大事なのは時間を確保することです。そして、それは"朝"です!

    転じて健康の話になりますが、人間の身体は睡眠中に体力や人体の回復を行っています。 そしてその効果が最も発揮される時間帯も決まっています。夜の22時から2時と言われています。

    sports.yahoo.co.jp

    22時から2時の説は現在は否定する研究もあるようですが、 だいたいこのぐらいの時間帯に寝ておくことが重要なのでしょう。

    また、必要な睡眠時間もきっかり決まっています。7時間です。

    www.otsuka.co.jp

    そうなると、何をするにしても早寝早起きするしかないのです!

    私自身は、元々学生時代から夜の2時に寝て、朝の8時ぐらいに起きるメチャクチャな生活をしていました。 大学が家から遠かったこともあり、その生活スタイルが習慣化して社会人になっても続きました。 その結果、30代で健康面でいろいろ問題に直面するようになりました。

    Twitterなどで3時から朝活をしていることをアピールしている人を見て、 逆に健康に悪いのでは?と以前は思っていました。 でも、本業以外で何かをやるにはこれがベストだと分かりました。

    Trelloとnotionでタスク管理

    仕事でもこれらのプロジェクト管理、タスク管理ツールは使いますが、 個人開発でも役立ちました。

    普段の仕事と比べて、個人開発で使える時間は限られてきます。 そのため、日々の進捗もわずか。 ときには、仕事や雑務に時間を取られて、間が空いてしまうこともあります。

    そうなると、前回どこまで進んだのか、次に何をやるのかをメモしておかないと続けられなくなってしまいます。

    技術の知見を貯めるのには、マークダウンで管理できるnotionが有効。

    coosy.co.jp

    タスク管理はTrelloを使っていましたが、チケットをたくさん切るのではなく、 最新の状況や次にやることをメモしておくために使っていました。

    trello.com

    ほんのわずかでも前に進める

    上記に加えて、適切にタスクを細分化することが大事です。 あまり大きいタスクだと時間がかかりすぎて、やる気が続きません。

    これについても仕事と比べて、かけられる時間が少ないことから、 普段の仕事よりも細かく分割することが必要です。

    これもTrelloのチェックリストの機能を使って管理していました。 チームで開発しているのではないので、いくつもチケットを作る必要はありません。 ひたすら一つのチケット上でチェックリストをつぶしていく感じです。

    そして、これをできる限り毎日、少しでも進めることが重要です。 仕事や副業、生活上の雑務、または壁にぶつかったりして進捗が止まると、しばらく停滞してしまうこともありました。

    今回、簡単なAlexa Skillでもリリースまで長い期間がかかってしまったので、"少しでも進める"ことの重要さを痛感しました。

    普段から作りたいサービスをイメージして技術を試すことが大事

    「作りたいものをもっとスピーディーに作るためにどうすればいいか?」 これが今回の個人開発における一番の課題です。

    初めての個人開発とはいえ、Alexa Skill開発にけっこうな時間をかけてしまいました。 (長すぎのため開発期間は伏せておきます。。。)

    そのためには、普段から作りたいサービスを念頭に、APIやライブラリを試しておくことが必要だと思いました。

    私は仕事で経験した内容をブログ記事などには載せていません。 そのため、ベンチャーで活動しているエンジニアの方よりアウトプットは少なくなってしまっていると感じてます。

    zenn.dev

    今回、プロダクトをリリースしてからQiitaで記事をまとめて書いたのですが、 これを試した時、その都度やっておけば、個人のブランディングにもつながるのではと期待しています。

    今後やりたいこと

    経済指標カレンダースキルのアップデート

    本業でもプロダクト開発をしているので、作りたい機能のアイディアには困りません。

    • 国別で指標を発話できるようにする
    • ユーザーのステータスを保持できるようにする
    • 経済指標の予測値と結果の発話
    • 課金機能の実装
    • etc

    経済指標カレンダースキルはまだMVPの状態です。 もっと機能を増やしてプロダクトとしての体を成したら、ちゃんとアピールしたいです。

    新しいプロダクトのリリース

    最初の個人開発がAlexa Skillだったからこそですが、 手軽にブラウザやスマホからアクセスできるWebサービスをリリースして運用したいと思うようになりました。

    OpenAIのAPIを使ったサービスのアイディアも考えています。

    個人開発者でも自身が開発したプロダクトをリリースして、さらにOSSとして公開している方や、 個人開発で生活できるぐらいの収益を得ている人もいます。 立派なサービスを作り上げれば、サービスが自分の名刺代わりになりますよね。

    github.com

    levtech.jp

    www.inkdrop.app

    Mini Tokyo 3Dのnagixさんや、Inkdropを作っているTAKUYAさんは憧れですね。 彼らを目標にして自分も精進したいです。

    時間管理

    既に述べましたが、重要なのでもう一度。 最も重要なのは時間管理です。

    今の生活スタイルでは、毎朝コンスタントに確保できる時間は1時間強というところです。

    これを2時間に増やしたいです。

    理想的には3時間欲しいですが、元々夜型だった自分はいきなりそれをやって何度も挫折してきたので、 まずは2時間確保を目標にしたいです。

    写真で振り返る木更津

    はじめに

    富津岬より撮影

    もう去年のことになってしまうが、 9月に木更津に行ってきました。

    年末年始で時間が取れたので、ブログに書き起こしているところです。

    目的は、写真と国内旅行のスタイルを探ることです。

    元々、自分は圧倒的に海外旅行派。 国内旅行はあまり興味が無かったのですが、 コロナ禍や円安もあって、どこにも行けないと滅入ってしまうので、 国内旅行の楽しみ方を模索してみようと思った次第です。

    木更津への行き方

    木更津に思い入れがあったわけではないですが、 東京から近くて、写真スポットがある場所をいろいろ探して、 たまたま木更津に行くことにしました。

    バスタ新宿からアクアラインバスに乗れば1時間程度で到着できます。

    www.jorudan.co.jp

    写真で振り返る木更津

    木更津に滞在したのは、9/22~23で、 2日続けての曇り空。夕方には雨も降ってくる始末。

    木更津港

    写真撮影としては、天気に恵まれずチャレンジングでした。

    失礼かもしれないですが、 地方に行って目につくのが、 寂れた商店街や観光施設。

    木更津駅から続く商店街のアーケード屋根

    観光客が押し寄せて人混みが多いのも難儀ですが、 こうも寂れていると観光すること自体への難しさを感じてしまいます。

    写真スポットとして有名な江川海岸。 しかし、まさか自衛隊基地の隣だとは思わなかった!

    snaplace.jp

    おまけにシンボルだった海中電柱が撤去されてしまっていて、 魅力が激減してしまっているのは残念でした。

    江川海岸、干潮時は海藻が丸見えになる

    江川海岸を綺麗に撮れたのは、中の島大橋でした。

    中の島大橋

    単純ですが、橋を渡ること自体が一つのアクティビティとしても楽しめるのと、 何より、木更津港からすぐ行けるので、個人的にはこれが今回一番の観光スポットでした。

    中の島大橋から見た江川海岸

    ちなみに、中の島大橋を渡ると『恋人の聖地』なる中の島に渡れるのですが、 見渡す限りの原っぱでした。。。

    これが恋人の聖地?

    行くのが大変だったのは富津岬

    富津岬の展望台

    車で行ければ簡単だったのでしょうが、バスで行ったらかなり歩かされました。

    富津岬展望台から見た海岸線

    まとめ

    ちょっとディスリ気味の内容になってしまいましたが、 一ついい点もありました。それはホテル。

    kukulu-hotel.jp

    オフシーズンに行ったのも功を奏してか、 7000円程度で、感覚的には10000~20000円ぐらいの部屋に泊まることができました。

    ホテルのレストランも開いていたら尚良かったのですが、 自分が宿泊中は閉店してました。

    そう考えると、近場の観光地を楽しむ方法は個人的には主に二つかなと思います。

    • ホテル
    • サイクリング

    東京に来てからは、道路が狭い上に、あまりに人が多くて自転車に乗るのを諦めていました。 ですが、地方なら都内と比べて歩行者は圧倒的に少ないので、 自転車はスムーズに走らせられます。

    木更津駅の駅前でも旅行客向けにレンタサイクルを貸し出していました。 自転車に乗るぐらいに動きやすい服装なら荷物にもならなそうです。

    撮影機材

    今回の旅は、ほとんど以下の機材で撮ってます。