最近の若者言葉なのか、気になっていることがある。 「死ぬ気でがんばります」 この言葉をちょくちょく耳にする。 私はこの言葉、すごく矛盾した言葉だと思う。 世の中のどんなエリアでがんばるのかは人それぞれだ。ただがんばる以上は上を目指す。成長したい。成功したい。うん、それはわかる。 そうなんだけれど、その目的って何かって言うと、「生き残ること」なんだと思う。 いろいろな競争が行われ、結構な割合でその場にはいられなくなる人は多い。活躍する人は残った人。やめなくて済んだ人。こういう図式は多様性が重んじられる今でも一緒だと思う。アーティストでも会社員でも芸能人でも、やっぱり厳しい競争の中にあり、勝者と敗者は存在する。 結果として続けられて、そしてある程度以上の評価を受け、その場に立っていられることというのは「生き残った」と言う言葉がふさわしい。裏を返せば、死ななかった、ということになる。 わかるだろ

ポッドキャスト Today I Learned FMの28 回目はメンタルヘルスの話題について話しました。この記事はその収録に関する追記です。 anchor.fm 「なんとなく元気がない」 = languishing www.nytimes.com "バーンアウトでもないし、うつでもない。けどどこか希望がない。なんか楽しくないし、目的ももてない。なんだかモヤモヤする。" この症状に対し、社会学者の Corey Keyes 氏は languishing という名称をつけました。日本語だと"衰弱"という意味ですが、要はゆるやかに不調になっている状態を指します。 languishing のやっかいなところは、これまで明確に言語化されていなかったために、症状として認識されていなかった点です。認識されていないために早期の対応が遅れ、やがて本当のうつに移行していく可能性が高いです。 元記事では、パンデ

大学時代、ひたすらあえぎ声を書くバイトをしていたことがある。 先輩から紹介してもらった、エロゲメーカーのバイトだ。 その会社のエロゲはストーリーに力を入れていて、所属するライターも自分の文章にプライドを持っている人ばかりだった。 彼らからすると、Hシーンのあえぎ声を書くなどというのは苦痛でしかなく、学生バイトにでも任せておけということになったらしい。 仕事がどういう感じだったかというと、 1. まず、「チャックを開けた」とか「腰を動かすスピードが速くなっていく」といったHシーンの「ト書き」部分だけを渡される。 2. ここに私が「んっ……」とか「あんっあんっ」といったあえぎ声をてきとうな塩梅で足していく。 3. シナリオライターのチェックを受けて終了。 という流れだった。 簡単に思えるかもしれないが、これが意外に難しい。 まず、Hシーンにはある程度の長さがあるので、その範囲内で的確に盛り上げ

調べれば大抵の情報は誰でも手に入る今日このごろ。特に技術的な情報はオープンソースで一次情報へのアクセスは容易になった。 それと同時に繰り返し言われるアウトプットの重要性。 しかし、ブログやLTなどでアウトプットしても、「もっと質のいい情報があるのに自分がアウトプットする必要があるのか」「逆にノイズになるだけじゃないか」というような考えになってしまう人もいるのではないか。 そんな架空の声にお応えして、それでもなおあえて、一次情報ではない「あなたのアウトプット」の重要性を伝えてみようと思う。 実際にやる人は多くない 定量的なデータがあるわけではないが、直感的に共感してもらえるだろう。 ある技術や手法が話題になったとして、それを情報として知っている人はこの時代いくらでもいる。 だが、それを実際にその手でやったことがあるというだけでかなり群衆からは抜きん出た経験を持つことになる。 ましてやそれをや

20代の数年間SIで働いた。1年以上前に退職して今は別業界にいる。 今日、Evernoteを整理していたら「退職理由、SIの嫌な点」というメモが発掘された。退職直前のかなりストレスがたまっていた時期に書き殴った文章だった。学生の頃の私は絵を書いたりしていて、ものづくりで暮らしたいな〜などと思って始めたプログラミングが楽しかったので安易に受託開発業を選んでしまったが、その後悔が如実に表れていた。 一部自分でも覚えていない話もあったがコンテンツとしては面白かったし、今でもシステムインテグレーター業界で消耗する若者を減らしたいとは思うので公開してみる。 以下、同メモに加筆・修正したものなのでファンタジーだと思って読んでくれ。 工数至上主義受注した時点で売上がおよそ確定するので、後はその予定工数に収めて納品できれば御の字という考え方。よくある話だが、見積がおかしくても顧客と対等な関係が築けていない

ついに手に入れましたよー！ 無印良品のコオロギせんべい！(｀・ω・´) 最初は通販限定だった上にずっと品薄でなかなか買えなかったんだけど、もう普通に売ってるんですね！ 前から食べてみたかったから嬉しい( * ॑˘ ॑*  )⁾⁾ というのも、わたくし爬虫類のペットちゃんたちを飼っている身でして。うちのかわいいみんな氏が夜な夜な生きたコオロギさんを食べているのです。 愛するペットちゃんたちが食べているものを食べられる絶好の機会、これを逃す手はなかろうて！(｀・ω・´) みてみる てことで、改めてパッケージ。 「エビのような香ばしい風味」だそうです。 コオロギって生きてても割と出汁っぽい匂いがするので、なんとなく想像がつくような、そうでもないような。 実際エビとコオロギは生物学的にも近しいんですって。へーへー。 パッケージにコオロギさんが付いてる……！ 虫がダメな人からしたらこの時点でもうダメ

この記事は ドメイン駆動設計 Advent Calendarの記事です。 今年の9月にログラスというスタートアップに転職しました。 ログラスは元々DDDについて講師として勉強会をさせてもらっていた会社であり、DDD自体は社として取り組んでおりある程度進んでいました。ですが、講師ではなく中の人になったからこそできる色々な取り組みがあり、3ヶ月である程度形になりました。 本記事では、DDDを広めるための取り組みについて、極力再現性がある形を意識しつつ、ご紹介したいと思います。 入社時の状況 なにをしたか テストの話が多い理由 実施内容詳細 TDD Boot Campの@t_wadaさんの基調講演観賞会を行った Serviceクラスを1パブリックメソッドにした レイヤーごとのオブジェクトの依存関係を整理 レイヤーごとのテスト方針 クラス名の重要性 参照実装を作成した 「責務」と「テスト」の重要性

新型コロナウィルスの影響も長引いてますが、皆さま無事お過ごしでしょうか。私は幸い無事です。 日ごろチームでソフトウェア開発をしているのですが、近年社内ではペアプログラミングやモブプログラミングが流行しています。 私のいるチームでもここ二年ほどモブプログラミング（ないし類似のプラクティス）に取り組んできました。 モブプログラミングについて正確にどのようなものかは以下の記事などをご参照いただければと思います。 簡単にまとめると、要求分析やコーディング等幅広い開発作業を、同じ場所に集まったチームの共同作業でこなしていくというものです。 このご時世ですので、最近はオンラインのミーティングルームに集合する形式でしたけど。 www.agilealliance.org ここから先は、非常にパーソナルな、私に限定された体験になります。 どの人・チームにも適用できる話ではありません。ではありますが、どの人・

@tkanayama_です。「SQLアンチパターン *1」 という本を読みました。「ポケモンを題材に因果推論を実践してみる」のように、仮想的なストーリ上で実際に使ってみた感を出すことにより、自分の記憶に定着させることを狙います。 前提として、何をアンチパターンとするかは状況（ベンダーフリーである必要があるかどうか、どの程度の頻度で更新されるか・・・など）によって大きく異なるので、下記で紹介するアンチパターンは実は状況によっては問題にならないケースもあるかと思います。この投稿はあくまで「SQLアンチパターン」に忠実に従うことが目的です。 www.oreilly.co.jp 追記 登場人物 ストーリー フシギダネへの対応 ヤミカラスへの対応 ディグダへの対応 誤登録でポケモントレーナーになってしまったユーザーの削除 最後に 謝辞 追記 このブログを公開後、「外部キー制約はレコードロック周りのト

高校を一年留年しているので、進学が決まって上京してきたのが20歳になる年の春。 あの頃は何もかもが嫌だった。家も、街も、家族も、交友関係も。 何を学びたいわけでもなく、何になりたいわけでもなく。ただ「ここにいたくない」という思いだけで乗り越えた受験勉強。 下町の1Kアパートでひとり目が覚めた最初の朝、はじめて「ああ、息ができるってこういうことなんだ」と思いました。 あれからもう10年。 思えばいろいろあったような気もするし、なんにもなかったような気もします。 東京で一人暮らしをするにあたって、最初に心に誓ったことは、できるだけ人と関わらないように生きることでした。 だから友達もほとんどできなかったし、バイトもろくにしなかった。 社会人になって仕事を選ぶときも、なるべく人と接さずに済むことを第一条件にしてきました。 こうして人を避け続けてきた今しみじみ思うのは、人生はソロプレイ縛りだとできる

システム開発の世界において「技術的負債（Technical Debt）」は繰り返し話題になり、しばしば炎上しています。 技術的負債という概念の生みの親は Ward Cunningham （ウォード・カニンガム）です。彼は 1992 年にオブジェクト指向プログラミングの国際カンファレンス OOPSLA '92 の Experience Report でコードの初回リリースを負債に例えました（"Shipping first time code is like going into debt"）。 Ward Cunningham はソフトウェアの世界に多くの貢献を果たしてきました。Wiki の発明者であり、XP と TDD の父 Kent Beck の師匠のような存在であり、建築の世界の「パタン・ランゲージ」を Kent Beck と共にソフトウェアに輸入した人であり、「アジャイルソフトウェア開

主語が大きすぎるタイトルですが、今の自分の考えをまとめておきたく、記事を投稿します。 もしかしたら、将来は全然真逆のことを考えているかもしれません。 また、ここでの「エンジニア」はシステムエンジニア、とりわけアプリケーションエンジニアを指します。 主語を「エンジニア」にしているのは、僕がエンジニアリングしか知らないだけなので、もしかしたら営業職や事務職でも同じことが言えるかもしれないし、言えないかもしれません。 サマリ 結論から書くと、以下の2点があるので、長時間労働しないほうが良いです。 長時間労働をすると、成果をあげるためにより時間がかかる 長時間労働をすると、将来的なコストを抱える 長く働けば成果が出るのか 汎用的な例を挙げていきましょう。 「用紙を三つ折りにして、封筒に入れてください。」 という仕事があったとします。 誰でもできる簡単なお仕事ですね。 この仕事を1時間やった場合とさ

ゆうべ、そろそろ寝ようかなと思っていたらものすごいものが投下され、興奮して結局3時半まで起きてしまいました。 ということで、昨晩公開された「AIきりたん」こと歌声合成エンジンNEUTRINO1について（今の興奮をあとで思い返すためにも）書いておきます。 AIきりたんとは とりあえずこれを聴いてみてください。 これが合成音声か！？と思ってしまうような仕上がりですが、これがAIきりたん……歌声合成エンジンNEUTRINOによって生成されたきりたんの歌声です。 NEUTRINOはSHACHIさん(@SHACHI_KRTN)によって製作されたフリーウェアで、昨晩公開されました。その標準の同梱ライブラリの1つが東北きりたんのものなので、そちらのことが「AIきりたん」または「AIシンガーきりたん」と呼ばれているというわけです。 ニューラルネットワークを用いた歌声シンセサイザー【NEUTRINO】を公開

ある会社で、人事担当の方に「能力は高いけど、中身のない人っていますよね？」と聞かれた。 「ほら、居るでしょう。仕事はできるんですけど、中身がない。例えば「高いものは、いいもの」と無条件に思っちゃっている人とか、ビジネス書しか読まないとか、「エビデンスのないものは信じない」とか、言っている人。」 なかなか面白い視点だ。たしかにそのような人物に心あたりがないわけではない。 彼は続ける。 「最近、中途採用で応募してくる人にそういう人ちょくちょく見かけます。」 「そうなんですか。」 「そうなんです。彼らは時にMBAを持っていたり、難関資格を持っていたりもします。が、そういう人を採用するのは最近ではちょっとやめよう、という意見が社内から出ているんですよ。」 「どういうことでしょう？」 「一言で言えば、感性が乏しいというべきでしょうか。人の感情の機微を読むことや、発想力という点で、若干難がある気がする

最近、TDDのテストコードは捨てても良いかみたいな議論を見ました。 これに対する自分個人の経験上の意見ですが、TDDは雑多にテストコードを使い捨てても効果を出せると思います。 もちろん、TDDで保守性が高く価値あるテストを書いて、捨てずにCIや中長期的なリファクタリングで再利用していくと、TDDの効果を増幅できます。ただ、それをするにはスキルや事前の工夫、労力が必要ですし、できる場面に限りがあります。 そういったことをやらず、もっとゆるい姿勢で取り組んでも、費用対効果をプラスにできる手法がTDDだと考えています。 今回は、そのTDDでゆるくしてもよいポイントを、実経験からまとめたいと思います。 TDDのテストは使い捨てでいい TDDのテストはプログラマのこまごまな課題に応じて累積的に作られるため、保守コストがかかるテスト・保守する価値の低いテストが生まれがちです。そのためテストの使い捨ての

1on1.md これは私が支援先に提供した、1 on 1 に関するノウハウや、思いを述べたドキュメントを元にしています。企業の枠を超えて共有したいことが多いので、ここに貼ります。 概要 世の中には 1 on 1 の本があるようですが、とりあえずは『1 on 1 で 何を話すのか？ マネージャ/ソフトウェアエンジニアの立場から - サンフランシスコではたらくソフトウェアエンジニア』を読んでもらえればよいと思います (higepon さんに感謝!)。 1 on 1 は 1 対 1 で話すミーティングで、基本定期的にやります。上長とメンバーとの間で行うのが基本です。 グループ/チームでのミーティングを補完するためのものです。 みんなの前では話しづらい、込み入った内容を話します。 チームとして行っているタスクの進捗確認に 1 on 1 を使うのは避けましょう。それは 1 on 1 の目的に沿ってい

採用がほんとうに難しいです、という嘆きを経営者や人事の方から聞く。 「いい人を採るために何をしていますか？」 と伺うと「広告を増やしました」「イベントに参加しました」「SNSを活用しました」などと回答がある。単なるアピール不足で人が採れていないケースでは、これらの手段は有効である。 だが、ある経営者の話を聞き、私は大事なことを忘れていたと認識した。 私は、その経営者に世間話をしようと採用の話を何気なくもちかけた。 「いま、多くの会社で人が採れない、という悩みを抱えていますよね」 「そうなんですか？うちは人が採用できない、という悩みを持ったことはないですよ。」 「…本当ですか？」 「本当です。」 「…秘訣を教えて欲しいのですが…」 「真理は一つです。いい人が採れないのは、ダメな会社だからです。逆に言えば、良い会社であれば良い人が採れます。それだけの話です。」 「…もう少し具体的に教えていただ

こんにちは。皆様、夏はいかがお過ごしでしたか。 私は毎年実家に帰省し、そして毎年体調を崩すので、絶対風水的になんか合わないんだと思っています。コネクト支援チームのsakay_yです。 先日、2018年の新人研修資料を公開し、たくさんの反響をいただきました*1。ありがとうございました。 2019年もエンジニア新人研修を行いましたので、その紹介と講義資料を公開いたします。 2019年のエンジニア新人研修について 今年の研修は、組織運営チーム*2が取りまとめ、以下のような3構成となりました。 必修講義 誰に: 開発/運用本部に配属される新入社員​ 何を: どのチームに行っても必要となる基礎的な知識/技術/ツールを学び、体験できた 選択講義 誰に: 学びたい人が​（＝新入社員に限らず） 何を: 興味があることを学べた チーム体験（2週間 * 3チーム） 誰に: 開発/運用本部に配属される新入社員

好きな人を嫌いなるということがある。好きと言う感情は基本的にプラスのイメージがあるから好きな人が出来るということは良いことではある、はずなのだが、どうしたことなのか。世の中なかなかそう上手くいかないことが多いようである。 例えば誰かから好意を受け取ったとしてもそれを無にするとか、好意を伝えた後、相手から良く思われなかったことで今度は反対に嫌いになってしまうとか。これには筆者にも身に覚えることがあった。 人をバカにすることが多い子どもの恋愛 確か筆者が小学生だった頃、筆者にはクラスに好きな人がいた。しかし、相手からはそのことに対してあまり良く思われてなく、筆者の元にもそのことが伝わってきた。 こちらが近づこうとすると相手は何となくこちらを避けているのが分かるし、話しかけたとしてもなんだか素っ気ない返事ばかりが返ってくる。するとどうだろうか。好きな気持ちはどこへいったのやら、好きだった相手に対