10/14 の Tech Play での発表資料です https://techplay.jp/event/873259

初めて会社を起業する人のほとんどは、集団をマネジメントする方法を学ぶ間に、創業当初の従業員を燃え尽き症候群にさせてしまうと思います。 筆者のアドバイスがそのようなケースを減らせるなら、ここに書いておく価値があるでしょう。 筆者は小規模なチームやスタートアップ企業のマネージャーのためにこの記事を書きました。 ほとんどのアドバイスは、大規模な企業のマネジメントには当てはまらないのではないかと思います。 なお、急成長している企業に入社する人への全般的なアドバイスについてはこちらをご覧ください。 筆者について 中・小規模のエンジニアリングチームを数チーム管理した経験あり On DeckのCTO CoinListの元エンジニアリング担当VP AngelListの元リモート責任者 Product Huntの元CTO それでは始めましょう。 マネージャーはすべての失敗に責任を負う 分かります……とても前

Goodpatch Blogではこれまで多くの実践的なナレッジを発信してきました。 今回はこれまで発信したナレッジの一部をデザインプロセスに沿ってご紹介していきます。 みなさんが日々実践されているデザイン活動に少しでもお役に立てれば幸いです。 やろうと思っているけどなかなかできない、やってみたけどいまいちピンとこないという方はぜひお気軽にお問い合わせをいただければ最適な方法でみなさんのデザイン活動をサポートさせていただきます！ はじめに 〜デザインプロセスとは〜 Goodpatchでは以下の図のようなプロセスに則ってデジタルプロダクトやサービスをデザインしています。これをデザインプロセスと呼んでいます。クライアント様やプロジェクトの背景、そしてその性質に応じてプロセスは都度変化しますが、大まかな流れとしてはこれを踏襲しています。デザインプロセスでは各フェーズにて発散と収束を繰り返しながら、

2年ほど前に「SEOの学び方」という記事を公開しました。今回は改めて初級・中級・上級と3つの段階に分けて再整理しました。これからSEO関連のお仕事を始める方、SEOの勉強方法を知りたい方の参考になれば幸いです。 目次 SEOの学び方（初級） SEOは、Web経験がない新卒にはハードなお仕事 世界中の企業がSEOに取り組んでいる理由を理解する SEOはオーディエンスと事業の理解から始まる 自分でサイト運営・集客の経験をする 身近なものを題材にSEO施策を考えてみる 「この領域だけは、自信がある」というスキルの柱をつくる 自分自身もインターネットを活用する SEOの学び方（中級） SEOの全体図を学ぶ 英語 ケーススタディ（他社事例）を研究する 他人にSEOを教える Googleが公開しているドキュメントに全部目を通す 失敗してもいいので、施策を実施する 「今は学ばない」領域を決める 人が検索

NEKISUKA @SUKANEKI_STI Stable Diffusion や midjourney に参考画像を渡して生成してもらう機能が炎上しなくて、それらよりも規約で絵師に配慮した mimic が炎上（濡れ衣）した事実、「あえて英語対応Onlyにする事で一定以下の知識階級は切り捨てた方がいい」という前例になってしまわないか？私はそんな世界は嫌だけど。 2022-08-30 14:06:19 人間ジェネリック @DividedSelf_94 SteamやAppstoreで、「日本語話者はレビューですぐ低評価を付けて商品価値が下がるので、わざと日本語は実装しない」ってデベロッパーの人の話、たまに聞くなあ。そして日本人が作ったアプリやゲームは総体的に低評価になるので、売るのが難しいらしい。墓穴を掘るのが特異な国民だ。 twitter.com/SUKANEKI_VRC/s… 2022-0

はじめに 本稿は「.NET 6移行祭り！ C# Tokyo」イベントで発表した「金融の基幹システムを1年半かけて .NET 6に移行した話」の内容を文書化したものです。 [2022.08.28追記] さて、はじめにおことわりを。 おもったより大きな反響があって、想定より多く読まれており、とくに正しく伝えられていない箇所があると思い、少し補足を入れました。 ここで基幹システムといっていますが、金融の勘定系システムという意味ではありません。 基幹システムというとCore Systemという意味（これは勘定システムでしょうね）と、Mission Critical Systemの2つがあると思います。 本稿の対象は後者で、システムのお客様が、Mission Critical Systemと判断されて基幹システムとして扱われています。 金融の勘定系とは規模や複雑性、クリティカルな度合も異なりますが、

estie でソフトウェアエンジニアをしている徳永(@yTo_9)です。 estie では Ruby を書いたりTypeScriptを書いたりしています！ estie 夏のブログ祭りにかこつけて、せっかくなら普段は追わない部分だけど、気になっていたYJITなるものを深掘りしてみようと思い、「YJITがなぜRailsアプリケーションの高速化を実現できたのか」を調べてみたので紹介したいと思います。 「どうせ難しいんでしょ？」と思いながら調べてみたのですが、講演や論文の説明がわかりやすく、意外に概要を把握することは難しくありませんでした。 YJIT の核となっているのは Lazy Basic Block Versioning (LBBV) という手法で、これはRubyだけに限らず動的言語全般に適用可能な強力なアプローチであることがわかりました。 「あるタイプの条件分岐は、ほとんどの場合で片側しか

はじめに このツイートに結構反響があったので、雑になるがとにかく自分の考えをダンプする。もともと書いていた記事はうっかりやらかしてデータロストした、泣きたい。 話をわかりやすくするために、ALB+ECS（Fargate）を使ってWebAPIと対比して説明しているが現実はもっと複雑である。 引用リツイートをもらえた部分などについてもアンサーっぽいことも書いていく。 AWS利用費と人件費の話 AWS上にWebAPIを構築する際に、AWS利用費の削減をモチベーションとしてApiGW+Lambda構成が、採用されることがある。確かにAWS利用費は下がるがApiGW+Lambda構成を設計〜運用するためにはAWSに関する知識の中でもとくに専門的な知識が必要になる。こういった人材を雇用または外部へ発注し続けることは人件費に跳ね返ってくる。 ApiGW+LambdaがWebAPIのための構成として唯一無

こんにちは。システム部の大澤です。 普段は北米版あすけんのアプリを開発しています。 今回はこちらの記事にインスパイアを受けて、askenでもやってみたいと思いました。 developers.cyberagent.co.jp 今後、askenに入社するエンジニア（シニアエンジニアを想定）にオススメする1冊について、アンケートを取ってまとめました。 エンジニア全員からアンケートに答えていただいたので結果をすべて、載せました。 設計、エンジニアリング 現場で役立つシステム設計の原則 ～変更を楽で安全にするオブジェクト指向の実践技法 https://www.amazon.co.jp/dp/477419087X/ref=cm_sw_em_r_mt_dp_1VATC0ETF72J8V6V5R9E 特定の技術分野に依らない設計の基本が学べるから。 asken社内でも著者の増田さんを招いて勉強会を開催して

はじめに SQLite は世界で一番使われている　だから世界で一番凄いものに決まってるだろ SQLite は世界で最も使われている RDBMS です。名前に反して（？）おもちゃの RDBMS ではありません。元ネタと同じで 一番普及しているからと言って必ずしも一番凄いものであるとは限りませんが、普及しているのであればそこには何かしらの理由があるはずです。その理由を調べないことには、凄いか凄くないかの結論は出せないので SQLite のなにがそんなに凄いのかを調査しました。 2022/04/01 続編記事↓を書きました。 注意 この記事は「なぜシェルスクリプトで高度なデータ管理にSQLiteを使うべきなのか？ ～ UNIX/POSIXコマンドの欠点をSQLで解決する」の補足記事して書いたものです。ところどころ不自然にシェルスクリプトや Unix コマンドの話が登場するのはそのためです。基本的

こんにちは、kintone.comのバックエンドエンジニアをしている@ueokandeです。 いきなりですが、メールって難しいですよね。 普段HTTPに慣れていると、メール周りのプロトコルの理解は難しく、トラブルにも見舞われることも少なくないです。 またメールプロトコルの性質上、メールを送った後にもトラブルは起こりがちです。 グローバル向けkintone.comはAWSで運用しており、メールの機能はAmazon Simple Email Service（SES）を利用しています。 この記事ではkintone.comのメール基盤の全貌と、Amazon SESを利用する上での運用プラクティスを紹介します。 kintone.comとメール kintone.comでは、ユーザーの招待やkintone上の更新を知らせるためにメールを利用し、メール送信は重要な機能の1つです。 kintone.comは

2021/9/23プロジェクトリードにおける考察について取り入れた2021/10/11職種の人数が多い、アプリケーションエンジニアを対象として、まずは内容を詳細化してアップデート2021/12/10プロフェッショナルの年収を520~550万を520~570万に変更チーフプロフェッショナルの年収を550~600万を570~620万に変更マルチリードエンジニア、チーフテックリード、リード・アーキテクト、チーフマイスターエンジニアの年収上限を950万から1000万に変更アーキテクト、リードアーキテクトの職位ガイドラインの詳細（暫定）を追加2022/4/11リードエンジニアの年収レンジを650-700万についてを、650-720万に変更チーフリードエンジニアの年収レンジを超える700-800万から、720-800万に変更2023/3/13 プロフェッショナルのチームコラボレーション（主体性）に追加

こんにちは。テクノロジー本部のyoshikawaです。好きなW3C Recommendation は RDF 1.1 Concepts and Abstract Syntax です。 会議やチャットでのやり取りの決定事項・議事録、アプリケーションや機能の設計書・仕様書、READMEなどなど... LIFULLの開発現場においては、ソースコード以外にもこのように様々な文書の管理・蓄積(=ドキュメンテーション)を実施しています。 多くの開発者・メンバーがドキュメンテーションの重要性やその恩恵は理解はしているものの、なかなかうまく情報の蓄積・管理ができない、 その結果、本質的ではない調査に時間を取られてしまいDeveloper Experienceが下落してしまう。 このような課題を抱えているプロジェクトやチームは世の開発現場において少なからず存在すると思います。 LIFULLの開発現場にもこの

はてなのチーム横断のエンジニアメンター制度 - Hatena Developer Blog で紹介していますが、はてなにはチーム横断のエンジニアメンター制度があります。僕も最近までメンターとして5~6人ほどのメンティーを持っていました(今は事情があってメンターをやっていないのですが)。 メンターとして1on1をする時には1on1ミーティングに備えるアンケート - しるろぐを参考にし、事前にメンティーに面談シートを書いてきてもらうという工夫をしていました。その面談シートは改善を少しずつ加えながら運用していたのですが、一度知見共有も兼ねて最近使っていた面談シートテンプレートを公開してみようと思います。 面談シートテンプレート 以下のようなフォーマットで書いてもらっています。1on1の前にメンティーに1on1用Google Docsに追記していってもらっています。1on1用Google Docs

レシピ事業サービス基盤部で部長をやっています、新井(@SpicyCoffee66)です。引越しを機に MtG のカードをほとんど売ったはずなのに、そのときは存在しなかったポケモンカードのデッキが手元にあります。なぜ？ 私は 2017 卒のエンジニアとしてクックパッドに入社し、様々な業務を経験した後に 2020 年の 8 月から部長となりました*1。最近はコードを書いていないので Techlife の執筆内容に迷ったのですが、今自分の中にある「優れた組織づくりについての考え方」をまとめてみることとしました。部長になる前にも、グループ長として小規模なチームマネジメントの経験があるとはいえ、それを含めても２年弱のマネージャー経験しか持っていないので、これが絶対の正解というわけではなく一つの考えとして読んでいただけると幸いです。 組織の存在理由 優れた組織づくりについて考えるために、まずは組織の存

私が一番最初にAndroid アプリをデザインしたのが2016年の初夏頃で、その頃はまだiOS・Android とデザインが違うのが主流でしたが、2021年現在のアプリはiOS もAndroid もプラットフォームごとの細かな違いはあれどほぼ同じデザインが主流となっています。 これは2016年の10月にAndroid APIがBottomNavigationView に対応してからじわじわ浸透していった変化だと考えているのですが、その辺の歴史の話は省略します。プラットフォームは違えどスマートフォンアプリである以上デザインは同じ方が楽なので、共通化されていったのは自然な流れだと思います。実際両者が全然違うUI・デザインだと大変ですしね……。 とはいえ、プラットフォームが違うので全て同じというわけにもいきません。iOS にはHuman Interface Guidelines、Android

エンジニアの佐野です。今日はカンムの決済システムでユーザの残高管理をどうやっているかについて書きます。 カンムの製品であるバンドルカードはプリペイド方式のカードです。ユーザによる入金、店舗での利用、運営事由の操作などによりユーザの残高が増減します。このような残高の管理について単純に考えると user_id と balance と updated_at あたりをもったテーブルを用意して balance と updated_at を更新していく方法があるかもしれません。しかしながらカンムでは残高を管理するテーブルを持たず、これらイベントの履歴のみで残高を管理しています。以下、本記事ではこれらユーザの残高が増減するイベントのことをトランザクションと呼びます。ここでは DB の Transaction Processing を意味しません。 本記事のポイントは 残高を管理をするテーブルは作らず、ト

背景 近年,新型コロナウイルス感染症 (COVID-19)の蔓延によるリモートワーク利用の加速化やクラウド活用の増加により,社外から社内システムに接続する機会が増えてきています。 現状のセキュリティ対策は,境界型防御が主流であり,社内を「信用できる領域」,社外を「信用できない領域」として外部からの接続を遮断しています。しかし,昨今の社会変化により,社内のシステム環境へ社外から接続を行う機会が増えているため,境界型防御を元に検討されていたセキュリティモデルではサイバー攻撃の脅威を防ぎきれない状況になってきています。 これらに対するセキュリティ対策として,「ゼロトラスト」という概念が提唱されています。これは,社内外すべてを「信用できない領域」として,全ての通信を検査し認証を行うという考え方です。 しかし,ゼロトラストを導入しようと調査を進めると,多種多様な用語の説明からはじまり,多数の文献,製

ウェブメディア「ほぼ日刊イトイ新聞」や、圧倒的な人気を誇る紙手帳「ほぼ日手帳」などで知られるほぼ日が、6月28日に「ほぼ日の學校」をアプリで開校した。2018年に始まった、日本や世界の古典的な文献などをテーマにした学びの場を提供する「ほぼ日の学校」を、「人に会って、話を聞くこと」をテーマに大幅にリニューアルしたもので、スマートフォンアプリを使った映像・音声配信を軸に展開することが特徴だ。月額680円（初月無料）のサブスクリプション型のサービスとなる。 ほぼ日の代表を務めるのは、ご存じの通り、コピーライターとして一世を風靡し、さまざまな分野で活躍する糸井重里氏。今回のほぼ日の學校についても、企画の立ち上げはもちろんのこと、授業を担当する「先生」たちの聞き手としても関わっている。3年間のほぼ日の学校を経て、アプリで生まれ変わるほぼ日の學校では、どんな学びの場を提供しようと考えているのか。まさに