テープが擦り切れるまで聞いた Rebuild.fm 厳選オススメ回 4選
私はソフトウェアエンジニア、宮川達彦さんが運営するポッドキャスト Rebuild.fmの大ファンです。当時の同僚に勧められて初めて聞いた2014年から今まで聞いていない回はおそらくなく、何度も繰り返し聞いた回がいくつもあります。 自身で書いたブログなどでもRebuild.fmを参照させてもらったことも多く、2021年に翔泳社さん運営のWebメディア BizZineにプロダクトマネジメントに関する記事を投稿した際にも、記事内でRebuild.fmの回に触れ、放送回のタイトルを記事タイトルに引用させていただきました。 ビジネス寄りの媒体であるBizZineにRebuild.fmへのリンクが貼られているのは私の記事だけではないかと自負しています。
現行のインボイス制度に関するSkebの対応につきまして
いつもSkebをご利用いただきありがとうございます。 2023年10月1日よりインボイス制度(適格請求書等保存方式)が開始されます。現行のインボイス制度に関するSkebの対応をお知らせいたします。 このお知らせはインボイス制度の解説を含み、非常に長い説明となっているため、先に要点を記載させていただきます。 要点Skebは現行のインボイス制度に強く反対します。インボイス制度は「クリエイターの本名がファンにバレる問題」「消費税の納税義務を負うか、取引が不利になるか二択を迫られる問題」「事務負担が増える問題」などクリエイターのみなさんにとって問題点が多く、十分な議論がなされないまま開始されようとしています。Skebでは特例制度を活用し、上記の問題を解決します。 Skebを利用する取引に限っては、クリエイターのみなさんの本名が登録番号経由でクライアントのみなさんにバレたり、インボイスに対応していな
「Infrastructure as Codeに疲れたので、僕たちが本来やりたかったことを整理する」を１年掛けて整理した
こんにちわ。rwle1212です。 本記事は JAWS Days 2020 で話す予定でしたが、昨今の事情によりオンライン開催となったため、登壇予定の内容を記事にしたものになります。 登壇していれば諸般の事情により左手首を骨折したネタが使えたのですが、ブログでは伝わらないので非常に残念な思いをしております。という話はどうでも良いので本題に入ります。 50分の登壇内容なので少々長くなりますが、お付き合いください。 JAWS Days 2019で登壇した内容の振り返り昨年の JAWS Days 2019 で「Infrastructure as Codeに疲れたので、僕たちが本来やりたかったことを整理する」という内容で登壇しました。 まずは上のリンクに添付されているスライドを5分位で読めると思うので一読頂いて、下の文に進んで頂ければと思います。 そもそもInfrastructure as Cod
Google Apps Script は何が強くてどんなときに使うべきかプラクティスをまとめてみた
はじめにGoogle Apps Script は無料で色んなことが実現できるため、ついつい「全て GAS でやっちゃおう」みたいな話になりがちです。Google Apps Script も万能ではないので、強み・弱みを理解した上で他の選択肢と比較して使うのをお勧めします。 Google Apps Script のプロジェクトを 2–30 個作ってきた中で、自分なりのプラクティスをまとめてみます。 この内容は Cloud Next ’18 in Tokyo で登壇したときの内容を含んでいます。この登壇から半年以上経ったのでアップデート部分も以下にまとめています。 Google Apps Script の強み・弱みまず、強みと弱みについてまとめてみます。 強み 1. Google Apps の API を簡単に呼び出すことができる一番の強みはこれだと思います。Google Apps Scrip
「良いエンジニア」を言語化してみました
「VOYAGE GROUP エンジニアの公開ガチ評価会」に参加して、最近考えていた「良いエンジニア」像がかなり良い感じだと思うようになりました。 「ガチ評価会」自体の内容は他の方のブログに譲るとして、「ガチ評価会」で聞けなかった部分、つまり「普段だったら『ビジネス的側面からの技術投資判断』とかも聞くんだけど」と言っていたところが、まさに聞きたいところだったのでニヤッとしました。聞けなくて残念♪ 妥協ない挑戦元々ピクシブの技術力評価においては、「最近やった妥協ない挑戦は何ですか？」というのをキーワードにやってました。 解決すべき課題に対して、どういう背景があって、どういう事前調査をして、どういう実装をして、どう考察するか、というところまでをきちんと考えて仕事することに成長があるんだよ、というメッセージ性です。 そんなこと言っても普段は妥協ばっかりですって？いえいえ、相反する選択肢の中で、何を
海外と日本でのソフトウェア開発職の文化を振り返ってみた – reyabe – Medium
こんにちは。阿部と申します。とある渋谷のIT企業でエンジニアのお仕事をしています。普段はブログを書いていないのですが、お勤め先の社内ブログ用に以前執筆した記事をlean-agile podcastで紹介していただく事になり、当時の記事を今回こちらのプラットフォームでも公開する事にしました。長文になりますが、ご興味を持たれた方は是非ご覧ください。 「海外と日本でのソフトウェア開発職の文化を振り返ってみた」という記事のタイトルにしているのですが、この話のモチベーション・裏付けとしてまず自分のバックグラウンドを簡単に説明しておきます。私は名前によらず外国籍・海外育ちで、今までヨーロッパと日本それぞれでベンチャー・中小企業・大手の仕事環境を６社ほど転々とし、色々な国のエンジニアと仕事をしてきました。 （＊ちなみに、日本語で記事を書くのはあまり得意でないので、言葉遣いがおかしいところは大目に見ていた
メルカリの小泉さんと組織の課題について話したら恐ろしい程勉強になった話 – tsukuruba – Medium
僕の中で仕事人生に影響を与え続けてくれている三大COO（と勝手に呼んでる人たち）がいる。 一人目がアカツキ共同創業者COOの香田哲朗くん、二人目がフリークアウト(元)COOで現hey代表の佐藤裕介さん、そしてメルカリ社長兼COOの小泉文明さんだ。 それぞれ社長もできる人だが、COOとして事業及び組織の構築も構造的分析もハイレベルにできる。恐ろしく広域のアビリティを持ち、バイタリティとバランス感覚に優れ、超人的な仕事量をこなす人たちである。 そのうちのお一人であるメルカリ小泉さんと1on1させてもらう機会があり、その話が組織の課題に悩む他の人にもとても有用だと思ったのでメモを公開させていただくことにした。（ほんとにメモなんで乱文ご容赦ください） ツクルバでは組織・文化づくりに社をあげて徹底的に投資していく方針なので、非常に参考になった。 ＊＊＊以下メモ＊＊＊ [お題] メルカリで急激に組織を
エンジニア採用面接の難しさ
エンジニアを採用していく中で「採用面接」は非常に難しい問題と言える。 経験上、今までかなり多くの面接をこなしてきたが、未だに「完璧な面接」というものにはほど遠い。 60分といった短い時間でお互いを知るには時間が足りない。 また面接は「お見合い」であり、極々短い時間の間にお互いに「相手と結婚するか」を決めなければならない。 失敗するとお互い不幸なことになることが解っているのにもかかわらず。 ……とはいえ、数百回と繰り返してきた面接の中で見えたこともあり、それを書いていくようにする。 主にゲーム関連のエンジニアを対象にしてきたケースが多いが、領域としては、クライアント、サーバ、インフラと一通りの人を見ている。 担当したプロダクトに使われている技術をどれくらい理解しているかを尋ねる
プログラミングを教えるときの10のポイント (という論文の紹介)
1. ギークの遺伝子なんてないことを心に留めようよく、「プログラミングには得意不得意がある(some kids get it, and some kids don’t)」とか、さらには「プログラミングには向いていない子がいる」とか聞きますね。 大学のコンピュータサイエンスの授業の成績分布が、とても良く理解できる生徒と何もわかっていない生徒にくっきりわかれる、という話も聞きます。本当でしょうか？Patitsasらの最新の研究によると、実際にはそんなことはなく、くっきりと成績の分布が分れてしまったコンピュータサイエンス入門のクラスは、5.8％に過ぎなかったそうです。 この論文では、「プログラミングには得意不得意がある」という迷信は、プログラミングを学びだしたときに躓きがちな生徒でなく（意識的か無意識的かにかかわらず）、スムーズに学ぶ生徒の方へ教える時間や熱意を費やすことにつながり、ひいてはコン
テックリードという役割
なぜこの文章を書くか?自身が数ヶ月テックリードの役割で経験した内容を基に、テックリードがどういう役割で、毎日の仕事の中でどのような仕事をするのかについて書いていく。 テックリードはサンフランシスコのWeb系企業では一般的なようだが、日本ではまだそれほど広まっているとはいいづらいと思う。 テックリードに求められるのは一言で言えば”技術でエンジニアチームをリードすること”である。Webエンジニアのキャリアパスでたびたび二元論的に語られる、”技術一本で生きていく”職人的なトラックとも”人やプロジェクトのマネジメントをする”マネジメント系のトラックともニュアンスが異なる。 自身の技術力、そしてリーダーシップをもってエンジニアチームのアウトプットを最大化させていくのがテックリードの役割である。 多くの人にその役割を知ってもらい、エンジニアとしてのキャリア形成の助けになればと思っている。 なお、このポ
ソフトウェア開発で学んだが使わなかったもの
開発手法など、一通り学んだが実際に使っていないものは多少なりあると思う。それらについて掘り起こしてみたい。 スクラム開発認定スクラムマスター研修には研修会場ホストという立場で数回立ち会った。認定外の研修も幾つか受講した記憶がある。書籍もそれなりに読み、Scrum Gathering Tokyoなどのコミュニティにも顔を出し、まあそれなりに色々考えて捉えてきた。でも、自分のチームでは使っていない。スクラム開発というアイデアに矛盾があるからだ。 そもそもスクラム開発ではチームの自律的な行動を良しとしており、それに対する”フレームワーク”を提供しているということになっている。イテレーション、バックログ、ふりかえり、デイリーミーティング（いまだに「朝会」って言ってる人いないよね？）、そしてそれらのお作法。誰が言ったかわからないが、それぞれの作者の意図を察するためには「守」が大事らしい。守破離の「守
うわっ、私のサイトBootstrapくさすぎ!? たった数文字変えるだけでBootstrapのくさみが抜ける7つのCSSテクニック。
なんか、このサイトBootstrapくさい。そう感じることはありませんか? その理由はズバリ、欧文ベースでつくられたフレームワークを文字構造の違う日本語で適用した際に不都合が出てしまっているからです。 それらが醸し出す違和感を放っておくと、Bootstrapくささを生み出す大きな原因になってしまいます。 そもそもの問題として、欧文と比較して和文は文字の要素が多く、文字自体のリズムも少ないため、どうしても複雑で単調に見えてしまいます。 しかし、和文だからといってあきらめることはありません。BootstrapのCSSを少しだけ変えるだけでグッと見た目がよくなる隠し味をご紹介します。 1. line-heightで行間にゆとりを。明朝やゴシックなど、フォントの種類が言葉の印象を表すように、文字の行間は読みやすさ、文章全体の雰囲気を左右します。 欧文をベースに設計されたBootstrapをそのまま
Kaizen Platform, Inc. エンジニア行動指針
Engineering Teamの Akira MAEDA です。 今回はKaizen Platform, Inc.社内にあるエンジニア行動指針を紹介したいと思います。 このエンジニア行動指針は創業間もない頃に技術顧問のNaoya Itoが中心になって作成し、今から2年半ほど前にオフィスに遊びに行った私に、CTOのToshimasa Ishibashi、Naoya Itoの二人がKaizen Platformの実現しようとしている未来とともに熱心に説明してくれ、私のKaizen Platformへの転職のきっかけになったことを今でも思い出します。 以下内容 — - Kaizen Platform, Inc. エンジニア行動指針Message from CEO (Kenji Sudo)・ 我々はクラウドソーシングで新しい働き方を作り出していく集団なんだから、我々自身も新しい組織のあり方に挑戦
ボトムアップ組織のマネジメントとは何なのか
いま所属している会社は、ボトムアップな会社ということになっている。正確にはボトムアップとトップダウンが混在していてたまにミスリーディングなのだが、だいたいはボトムアップな会社といえるだろう。 それで、たまに、学生と会ってくれといわれて、うちの会社がボトムアップの会社なんですよ〜、と話すことがある。だがこのボトムアップというやつ、採用活動では『いかに若いうちから活躍できるか』をぐいぐいアピールするための文句ではあるのだが、実際、現場でどういうコミュニケーションになっているのか、あまり説明されない。どういう会社が「良い」ボトムアップの会社なのか、わりとみんな意識していない。 とりあえず適当に若いのに丸投げてみたら、いつの間にかイケてる提案を持ってきた、なんてことは、ありえない。それを実現するためには、上司側の見えない努力がたくさん必要なのだ。 こんなマニアックな話をしている人は多くないと思うの
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Flutterの効率良い学び方
真面目な人を本気にさせる方法