アップルのCEOや台湾のIT担当閣僚がこぞって「会いたい」と呼びかけたのが87歳の若宮正子さん。世界から注目される「世界最高齢のアプリ開発者」です。でも実はパソコンは58歳から、アプリ開発は80歳から。人生100年時代を体現する若宮さんに、生き方のヒントを聞きました。

「Day One - CTO/VPoE Conference 2022 Spring -」は、日本CTO協会が主催するイベントです。パネルディスカッションでは、政財界、テクノロジー分野の第一人者をパネリストにお迎えし、日本CTO協会理事のモデレートにより、“Day One”をテーマにご講演いただきます。ここで登壇したのは、株式会社Lighthouse Studio CTOの海老原昂輔氏。これまでの経験から導き出した、“ソフトウェアエンジニア的思考をマネジメントに活用するアプローチ”について発表しました。全2回。前半は、最初期のマネジメントとプログラマーとして犯してしまった禁忌について。 エンジニアにありがちなキャリアの変遷 海老原昂輔氏：「コードを書いていたいけど、マネジメントもやるようになっちゃった人のための生存戦略」というタイトルでトークをします。株式会社Lighthouse Stud

長井産業 今の仕事のやり方では局地的最適化が進みすぎて限界を感じていた ただ立場的に急激に生産性を下げるわけにはいけかない学生アルバイトレベルの給料で仕事をしつつ、非常に多くの新しいツールやサービスを仕事内で試せて満足しているスペック都内在住30歳独身男性。 大学は情報系だったが中退した。 Webプログラマでインフラからデザインまで分野に関わらず幅広くやっている。 今はフリーランスでそこそこの売上がある。 趣味もプログラミングでoss contributionしたりカンファレンスに登壇したりなどをしてる。 多少ぼかして書いてる部分がある 悩み今までに色々な規模や業種の会社でWeb開発をしてきた。 複数のプロジェクトに携わり、多くの人と関わってきた。 「優秀なエンジニア」というものの評価指標は様々あるが、以下のようなことが考えられる。 単位時間あたりの仕様の把握速度が速い単位時間あたりのコー

こんにちは。Micoworks代表の山田と申します。 私はこれまでに10年ほど会社を経営させていただいておりますが、多くの失敗をしてきています。 その中でも投資額として最も大きかった失敗が「採用管理システムのリニューアルプロダクトを潰してしまったこと」でした。 2,3年ほど前の話になりますが、リリースまでに1億円程度を投下しておりお金の損失はもちろんですが、BizやCSメンバーも多大なリソースを費やし、会社の成長を失速させてしまいました。 当時は「この時間を丸々MicoCloudに投下していれば、もっと成長していたのに、、、」と自分の未熟さを何度も悔いていました。 この話の真因は「非エンジニアの経営者が、プロダクト開発の工数や進め方を理解できていないままプロジェクトを進めてしまったこと」だったと感じています。 そこで備忘録を兼ねて、noteのテーマとして取り上げてみたいと思います。 ※テッ

「JSON色付け係」という自虐 フロントエンドエンジニアの間では、「私の仕事は JSON に色を付けることです」という有名な自虐ネタがある。 おそらく初出は以下のツイートなのだろう（*1）。ただ、出典はあまり詳しく調べていない。 初めてこの言葉を見た時、面白い言い回しだなと思った。確かにフロントエンドの仕事にそういう側面はある。 実際、コンテンツの表示がメインのページで作業すると上記のような気持ちになる。この場合、フロントでやることといえばせいぜい日付の表示形式を適切にフォーマットするくらいだ。結局バックエンドからデータが返ってこないとフロントだけでは何もできないと思うこともある。 もちろん、フロントだけで簡潔する手書き風グラフ作成ツール excalidraw のようなものは別だし、フロントで複雑な状態を扱う部分を書いたり、フォームを使ってユーザー入力を受け付け、入力値を検証するバリデーシ

長い間、フリーランスなどという「便利屋」をこなしていると、馴染みの顧客から、トラブったプロジェクトに急遽参画してほしいという、ヘルプ案件が入ってきたりする。 嫌かと言われるとそうでもなく、むしろ、恩を着せて（足元を見るとも言う）高単価を取るチャンスだし、案件が燃え上がっているのは他人のせいであり、途中から入る私は気楽なものなので、積極的に首をつっこむことにしている。 こう言うと颯爽と現れるスーパーマンのようでかっこいいのだが、そこはクソ雑魚フリーランスの私。トラブルの内容というのは、「安いWordpress業者に頼んだ案件で、途中で、（カスタマイズ要件）がやっぱり出来ないと言われた」とか「アプリが毎回メモリリークで5分で落ちるのだが、全く治る気配がない」とかそういう情けない話ばかりである。 共通して言えるのは、炎上させた業者が「（問題を解決することが）出来ません」とはっきり言ってしまってい

2018年6月1日に株式会社メルペイに入社して、4年が過ぎました。入社当時は、定年が60歳と聞いていたので、1年半の勤務だと思っていましたが、実際の定年は65歳であり定年まであと2年半です。 ソフトウェアエンジニアにとって重要な能力と（私は考えるが）、身に付けるのが難しいのが現実だと、この4年間で再認識したのは次の三つです。 開発の最初にAPI仕様をきちんと書けるソフトウェアエンジニアは少ない テストファースト開発を行っているソフトウェアエンジニアは少ないか、いない Tech Blogなどの執筆で、読み手を意識して、分かりやすい文章を書く、ソフトウェアエンジニアは少ない API仕様については、このブログでも何度か書いています（「API仕様を書く」）。テストファースト開発についても、「テストファースト開発」を書いています。分かりやすい文章については何も書いていないですが、「伝わる技術文書の書

※注意 ・この記事は駆け出しエンジニアさんが読むと気分を害する事があります。・この記事に登場する駆け出しエンジニアさんは誰か個人の事ではなく、自分の感じた駆け出しエンジニアさんの事です。 １．そうだ、情報発信しよう エンジニアのブログを読み漁っていたら、とある記事に出会った。 「これからのエンジニアは情報発信すべきだ」 その記事にはこのように書かれていて 確かにそうだなぁーーって思った。 じゃぁ、どうやって情報発信するの？？ 色々と調べた結果SNS（Twitter）で情報発信するのが良いらしい。 ただ、自分のTwitterに対するイメージって 若者がコンビニの冷凍庫入って 「うぇーーーぃ」 ってアホな写真投稿するアプリってイメージで、なかなか始めてみようとは思わなかった。 ※今のTwitterのイメージは全員コテハンの２ちゃんねるｗ ２．Twitterデビュー ﾄﾞｷﾄﾞｷしながらTwit

はじめに ソフトウェアエンジニアでテストマンを生業とする Kuniwak です。今回は家を買うためにやったことを紹介します。 というのも、家を買うためにやったことを知人に話してみたら面白がられたため、誰かの役に立つかもしれないと思ったからです。 なおこの記事はソフトウェアに関する技術の記事ではありません（随所に検証の基本的な考え方などが散りばめられていますが…）。また、この記事で紹介する意見・手法は多分に cocopon 氏の影響を受けています。cocopon 氏の家購入エントリもこの記事と同時に公開されているはずです。 また、この記事はとても長いので先にポイントを説明しておきます。この記事ではライフプランシミュレーションに始まり次のような3Dモデルを作って日照や照明の検証をしていきます。また、3Dモデルを作るだけでは漏れが出るのでさまざまな検証を組み合わせています： 検証のために作った3

今だから白状すると、昔、運営していたサービスの一般ユーザーのパスワードをハッシュ化（暗号化）せずに平文でDBに保存していたことがある。 言いわけは、幾つかある。 一つは、今では当たり前のようについているパスワードリマインダーの仕組みが当時は一般的ではなかったこと。 ユーザーがパスワードを忘れた、と問い合わせしてきた時に、最も自然な方法はまさに当人が設定した「パスワード」を一言一句違わず登録メールアドレスに送信することだった。あなたのパスワードは○○○です。ああそうそう、そうだったね。こういう感じだ。 当時のユーザーはそれを不審がらなかった。 またサポートコストの問題があった、パスワードの再発行を、そのためのトークンを含んだ長いURLを、大半のユーザーが嫌がっていた。 サポート部門はOutlookExpressに表示された長すぎるURLのリンクが途中で切れててクリックできない、という苦情にい

IT人材が不足してるんだって。零細Web制作会社で言えば、退職者が残したubuntu12サーバーに眠るRails5アプリをすぐにDDDでマイクロサービスに再構成して、jQuery満載のコードを全て読み下したうえで、フロントエンドをReactかなんかのSPAに全部書き換えて、E2Eを含めた自動回帰テストを整備して、ついでにCIも整備して、k8sにデプロイできるようにして、ドキュメントは小まめに残し、職場の心理的安全性を落とさず、飲み会にはかかさず参加、役員との関係も良好で、定期的な勉強会も開いてくれて、それでも残ったプライベートの時間を最新の技術動向やセキュリティ情報の収集に全量突っ込んでくれる、そんなごく当たり前のエンジニアが不足している。ついでに言うと、人類の原罪を一身に贖ってくれるスキルの持ち主も不足しているらしい。多分、我々はもっと求人サイトに金を払うべきなんだろうね。 同業者から、

新人: 「本日データサイエンス部に配属になりました森本です！」 先輩: 「お、君が新人の森本さんか。僕が上司の馬庄だ。よろしく！」 新人: 「よろしくお願いします！」 先輩: 「さっそくだけど、練習として簡単なアプリを作ってみようか」 先輩: 「森本くんは Python なら書けるかな？」 新人: 「はい！大学の研究で Python 書いてました！PyTorch でモデル作成もできます！」 先輩: 「ほう、流石だね」 新人: 😊 先輩: 「じゃ、君には今から 3 時間で機械学習 Web アプリを作ってもらうよ」 先輩: 「題材はそうだなぁ、写真に写ってる顔を絵文字で隠すアプリにしよう」 先輩: 「あ、デプロイは不要。ローカルで動けばいいからね。顔認識と画像処理でいけるよね？」 新人: 😐 新人: (えぇぇぇぇぇぇぇ。3 時間？厳しすぎる...) 新人: (まずモデルどうしよう。てかもら

この記事で書きたいことは、大筋下記のようなことです。 ・「これは問題だ」「だから改善したい」と、自分ごととして真剣に考えてくれる人というのは極めて希少です ・ただ「便利になる」というだけでは誰も動かないし、どんなにいいものを作っても使ってもらえません ・当事者意識を「持ってもらう」ということは基本的に出来ません ・当事者意識を持っている人を別に探し出すことで、なんとか状況を打開出来る場合もあります ・だから、「この人は当事者意識を持ってくれている/くれていない」を嗅ぎ分ける能力はとても重要です よろしくお願いします。 さて、書きたいことは最初に全部書いてしまったので、後はざっくばらんにいきましょう。 以前にも書いたことがありますが、私はかつて、システム開発の会社に勤めていました。 社員数は4桁に届かないくらいで、SI案件とSES案件が大体半々くらい、自社業務と客先常駐も大体半々くらいという

何が書かれているのか理解が難しく、イレギュラーな方法で裏技的に実装され、ちょっと触ればバグと化す、クソコード。 プログラマ諸氏なら誰しもが見たことのあるクソ忌々しいアイツだ。 クソコードはエンジニアを貧乏にしてしまう。 なぜ貧乏になってしまうのか、その理由について、怒りをぶつけながら以下に書き連ねる。 本記事の構成■理由①：プロダクトが利益を出せなくなる ■理由②：エンジニアが資産蓄積できなくなる　（←ココ重要） ■クソコードを滅ぼし豊かになろう ■ソフトウェア開発に携わる方々へ 理由①：プロダクトが利益を出せなくなるまずこちらの理由は簡単だ。３項目に分けて説明する。 【クソコードは読みにくい】 どんなロジックなのか理解が容易ではない。ロジックそのものは簡単であっても、tmpと名付けられた正体不明な変数、非推奨なAPIによる意図不明な実装などにより、読み解くのを難しくさせてしまう。 「クソ

READMEの重要性 READMEというのは、GitHubで公開されるソフトウェア（リポジトリ）の説明書きのことなのですが、これを軽視している人が多く凄い勿体無いなと感じることが多いです（GitHubって何？という人は下記記事参照下さい）。 個人的には、ソフトウェアにちょっとした機能を追加したり、デザインを工夫するよりも、READMEを書くことに注力した方がずっと効果が高いと思っています。当たり前の話ですが、どんな良いソフトを作っても、そもそもそのソフトが何なのかとか、使うとどんな良いことがあるのか、どうやって使うのかが分からないと、せっかく公開しても他の人に伝わりようがないですからね。実際、GitHubを見ていて、たくさんStarがついているリポジトリは、READMEが充実していることが多いと感じます。 といいつつ、自分も結構READMEを手を抜いてしまったり、毎回書く項目が変わってしま

こんにちは、CLI生活至上主義？の、 ひのしば です。 まぁ、至上主義というのは、ちょっと言い過ぎかもしれませんが、screen, vim, mutt, newsboat, pass, あとは、gitやssh 辺りを使う生活をしており、1日の作業がこれだけで完結するような事もあるような生活を送っています。 さて、そんな私が、ワークステーションサーバに、macOSや、Windows, Linuxから接続して操作するといった構成から、 作業環境をDockerfileにまとめ、手元で上がる環境をdockerコンテナへ統一し作業する構成とした話を紹介します。 この環境は、ここ数ヶ月、不自由なく使えている事もあり、自身の整理のためにも、どのような点が気になって対応したのかを挙げていきます。 詳細は下部に記載する通りですが、 例えば、dockerfile上のuidの問題に気をつける点、Linuxとma

思いついた順に書いてるからまとまりなくてすまん 給料がいい。転職前に比べて3倍超えた。GAFAと一括りにされるけど転職してきた人から聞くと割と風土は違うっぽいけど行ったことないから分かんない。エンジニアが全員頭いい。採用面接がマトモから。 コード書けてアルゴリズム分かってシステムデザインできる人しか取らない上司のことをマネージャーと呼ぶだけあって対等感は強い マネージャーはRPGのプレイヤーみたいにパーティの人数枠だけもらってるから、人が見つかるか、残ってくれるかはマネージャーの扱い次第 社内の転属は基本社内転職サイトを見て応募して他の候補者と競る。もちろんこちらも複数応募して気に入ったとこで内定して他は断る。 社内のコンパイラやコア言語チームのcoding practiceが神レベル。 社内アンケートで常に技術的負債が多いっていう不満が上がってるけど、前職の経験から言うと「お前らこの程度