夫婦でワンチーム。予想外のトラブルも転職も密な「対話的コミュニケーション」で乗り切る
夫婦でワンチーム。予想外のトラブルも転職も密な「対話的コミュニケーション」で乗り切る 2024年2月28日 西谷圭介 国内SIerで金融系基幹システムの開発等に従事した後、クラウドサービスの開発ならびに新規事業立ち上げを経て2014年にアマゾンウェブサービスジャパン株式会社（現アマゾンウェブサービスジャパン合同会社）へ。国内企業のクラウドシステム設計支援を実施しつつ、日本におけるサーバーレス市場の創出と普及に尽力。プロトタイプ開発を行う部門の立ち上げに従事した後、2021年6月より現職。CTOとしてプロダクトを国内外に提供すべくすべてのレイヤで開発に従事している。フロントエンドが好きでインフラもそこそこわかるバックエンドエンジニア。 X（@Keisuke69）・ブログ これまでは、家庭を持つ、特に子どもがいる状況での生活の変化や仕事への影響、それに対してソフトウェアエンジニアの端くれとして
もう初回コードレビューはAIに任せる時代になった - CodeRabbit -
どんな人向けの記事？ レビューによって心理的なダメージを受けやすい方 非エンジニアだが、エンジニアチームがどんな機能を作っているか知りたい方 業務が溜まっていて、レビューに割く時間を捻出するのに苦労している方 コピペできるコードも公開します 初回レビューをAIに任せると、いろんなロールの人の役に立つ レビューは得意ですか？ 優秀なエンジニアしかいないチームであれば、PRは1トピックに絞って小さく明確なコミットによって作成され、適切な要約とともに提供されることでしょう。 しかし、実際にはいろいろな制約から、PRが想定よりずっと大きくなってしまったり、関連トピックと異なるコードが混じってしまうこともあります。 実際のところ、大きなPRを適切にレビューするのは難しいことです。また、自分が詳しくない領域のレビューを行わなければいけない機会もあります。 今回の記事は、レビューを作成してくれるAI C
ビッグバンリリース対策でFeature Toggleを導入したら、開発チームが「デプロイできる状態」をより深く考えるようになった - はてなニュース
ソフトウェア開発において注目されるパフォーマンス指標には、デプロイに関係するものがあります。GoogleがDevOpsの取り組みから発表したFour Keysも、デプロイ頻度のほか、コミットからデプロイできるまでのリードタイム、デプロイにともなう障害発生率とその回復時間と説明されています。 そのためデプロイできるブランチへのマージは小さく、回数を重ねることが推奨されるようになっています。一方で、ビジネス用途のSaaSなどでは顧客との関係から、新機能は適したタイミングで完成度を上げてからリリースしたいという要求もあります。 タレントマネジメントシステム「カオナビ」の開発チームでも同様の課題感を抱えており、その解決のためFeature Toggle（機能トグル）を導入してデプロイとリリースの分離を図りました。その経緯や成果について、導入を主導したCTO室の富所亮さん、サービス開発部で実際にFe
1年目研修で出会った2人がTwilioハッカソンに参加して優勝した話とそこから得た学び - NTT Communications Engineers' Blog
この記事はSDPFクラウド/サーバー 仮想サーバーチームの宮岸(@daiking1756)とCOTOHA Call Center開発チームの立木の共同執筆です。 二人共エンジニアではあるのですが、普段は全く違うチームで開発をしています。 この記事では、普通に働いていたら交わることのない私たちが、一緒にハッカソンに参加したことで得た学びと知見を共有します。 はじめに 私たちが今回参加したのはTwilioハッカソン2022です。 その名の通り、Twilioを使った作品を作るハッカソンです。 今回のテーマは - Twilioを使って、ちょっと仕事を楽にしよう -でした。 当日はエンジニアを中心に30名ほどが参加しておりました。 宮岸は学生時代からハッカソンが好きで、 このTwilioハッカソンも以前から参加してみたかったものの1つでした。 今回2人でTwilioハッカソンに参加したきっかけは後述
████を退職します - uhyo/blog
この記事はuhy.oooでも読むことができます。 ████を退職します皆さんこんにちは。この度、████を退職することになりましたのでご報告します。 筆者は2019年に新卒で████に入社して、今年が4年目でした。今回が初めての転職となります。転職先は███という会社です。 ████はどうだったか一言で言えば、良いところでした。特に、チームメンバーと上司に恵まれ、快適かつとても自由な環境で働くことができました。 快適というのはいくつかの側面があります。自分としては、大きい会社ならではの整った社内制度・社内システムは魅力的でした。これにより、事務的な作業はなるべく事務的かつ簡潔に済ませられるようになっていて業務に集中できます。他には、プロジェクトメンバーとのコミュニケーションにおいてストレスを感じることもあまり無く（██████████████████████）、これだけ良い人ばかり集まって
「オンコール対応するエンジニアの睡眠時間を確保せよ」 GMOペパボSREチームの6つの取り組み
サービスの信頼性を守るため、オンコール対応は重要な仕事だ。だが、夜中に何度も呼び出されるような状況ではエンジニアの肉体的、精神的な疲労は計り知れない。Cloud Operator Days Tokyo 2022のセッション「信頼性を落とさず効果的にオンコールを減らす取り組みを目指して エンジニアの睡眠時間を守ろう」では、こうしたオンコール対応におけるエンジニアへの負担を軽減させる取り組みを紹介した。 「常に何らかのアラート情報が流れている」 GMOペパボの渡部龍一氏（技術部プラットフォームグループ）の役割は、GMOペパボの各種サービスの可用性を確保しビジネスの成長に合わせて適切な環境を提供することだ。そのためのさまざまな業務をこなす中で、オンコール対応は悩みの種になっていた。 「私のチームで対応するサービスだけでも100を超えており、平均すると2、3日に1回のペースで何らかのアラートが発生
エンジニア全員の話を聞くところから始まるVPoEの仕事。求められる「課題発見力」や「オンボーディングの仕組みづくり」
新卒でヤフーに入社。2、3度の転職を経た後、VOYAGE GROUPやサイバーエージェントにも所属。エンジニアとしての方向性をB向け領域に定める。曽祖父や姉、義理の兄が建築関係の職に就いていたこともあり、アンドパッドにジョイン。VPoEに就任し、現在に至る。 北野 勝久さん/(株式会社スタディスト)[@katsuhisa__] 日本タタ・コンサルタンシー・サービシズ株式会社にて、ERPシステムの開発・導入等のプロジェクトに携わった後、2016年8月に株式会社スタディストに入社。Teachme Bizの新規機能開発等を担当した後、2018年9月よりSREグループマネージャーとしてプロダクトの信頼性に関わる業務を担当。開発部副部長として開発組織の採用や組織づくりに携わり、2021年3月に執行役員VPoEに就任。 エンジニア組織づくりにおける「埋もれた課題発見力」の重要性 イベント前半では、二人
チームにいると頼りになるソフトウェアエンジニア
チームにいると頼りになるソフトウェアエンジニアのメモです。自分のロールモデルでもあります。私のキャリアはほぼウェブブラウザ開発一筋なので、その辺に生息している人たちを思い浮かべながら書いてます。思いついたら随時更新します。 コードマニア コードやドキュメントを読むのが好きで、暇があれば適当なレビューに飛び入り参加したり、自分のプロジェクトとは関係ないコンポーネントもひたすら探検している。不穏なコードを見つけるとなんとリファクタリングもしてくれる。コードサーチがお友達。 やたらコードに詳しいので、何か分からないときはとりあえず聞きに行く。チームに一人いるとレビューが捗るし、コードベースも綺麗になる。コードマニアはコードベースを広く熟知している上に未知のコードに対する耐性も高いので、プロジェクトを移動してもすぐに活躍できる。 コードマニアの亜種にスペックマニアもいる。こちらはウェブやネットワー
内製にこだわるチームを作るために必要な業務委託契約 - BASEプロダクトチームブログ
BASE株式会社取締役 EVP of Developmentの藤川です。 世界中が新型コロナの影響で雇用の先行きが不透明な中、当社は引き続き成長を模索している状況で、マネージャ陣を中心に採用活動にも注力する毎日を送っています。 当社は正社員採用はもちろんのことですが、業務委託契約の方々にもお手伝いいただいておりますが、今回は業務委託契約にフォーカスした記事を書いてみたいと思います。 内製にこだわるチームを維持するための採用活動 私達はサービスを維持、成長させるために毎日ソースコードのメンテナンスをしています。我々はAWSやGCPなどのクラウドの環境とオープンソースのソフトウエアに恩恵を受けながら、独自のロジックは内製で開発しています。 他社の開発体制の事例として、スタートアップとして最初は内製で立ち上げたとしても、組織が大きくなりビジネスの成長が問われる中で、SIerさんに社内にがっつり入
SREはインフラ担当だけでなくチーム全体で取り組んでいくもの | はてなで働く cohalz にアンケート [#9] - Hatena Developer Blog
こんにちは、Hatena Developer Blog編集部です。「はてなで働くエンジニアにアンケート」シリーズ、今回ははてなブログチームのSRE、id:cohalzに話を聞きました。 id:cohalzにアンケート はてなidとその由来を教えてください いつどんなきっかけで入社しましたか？ 現在の仕事を教えてください チーム内の立ち位置を教えてください 1日の仕事の流れを教えてください 最近うまくいったことは何ですか？ 最近うまくいってないことは何ですか？ 普段大切にしていることは何ですか？ はてなはどんな会社ですか? id:cohalzにアンケート はてなidとその由来を教えてください 読みは「こはる」と呼ばれることを想定しています。 読みとしては日本語としてありふれた名前にしつつも、idとしては被らないものにしたいという意図を持っています。 idはco + hal + zの3つの要素
![SREはインフラ担当だけでなくチーム全体で取り組んでいくもの | はてなで働く cohalz にアンケート [#9] - Hatena Developer Blog](https://cdn-ak-scissors.b.st-hatena.com/image/square/b1540f83138e6a085307ec37757319aa491a2baf/height=288;version=1;width=512/https%3A%2F%2Fcdn-ak.f.st-hatena.com%2Fimages%2Ffotolife%2Fh%2Fhatenatech%2F20201027%2F20201027191102.jpg)
非エンジニアの創業者が、1人目のエンジニアの実力を見抜く方法 | Coral Capital
特に日本ではそうですが、多くのスタートアップでは、CEOが非技術系の共同創業者である傾向にあります。このポストでは「なぜそうなのか」や「この傾向が良いのか悪いのか」については論じません。これから書くことの背景として、そうした傾向があることを、まず共有しておきたいと思います。 技術系でないCEOは資金調達を担当することが多く、そのため、私たちが最初に会う共同創業メンバーも、そうしたCEOのことが多いです。そうした方とやり取りする中で、よく驚くのは、創業者CEOが、技術担当の共同創業者（または1人目のエンジニア）が過去にどのような仕事をしてきたのかについて、実はほとんど知らないことがあるということです。 そういったCEOはエンジニアリング担当のチームメイトの経歴を大まかには説明するでしょう。例えば「彼女はSIerのエンジニアだった」という具合です。でも、そのエンジニアが実際に何を作ったのか具体
5年半勤めたエンジニアチームを辞めて、UXチームにジョインしました - freee Developers Hub
こんにちは、お久しぶりです、 id:ymrl です。 2019年も年末調整とAdvent Calendarの季節がやってきました。いつものごとく、今日から25日まで毎日、freeeの開発に関わるメンバーが日替わりでブログを書いていきます。ということで、この記事はfreee Developers Advent Calendar 2019の1日目です。よろしくお願いします！ エンジニアチームを辞めました freeeに入社したのは2014年の1月で、エンジニアチームには5年半いたことになります。入社したときにはエンジニアが10人くらい、全部でも20人もいないような小さな会社だったのが、5年半で25倍以上の規模の会社になりました。デカくなった。 5年半のあいだ、ほぼエンジニア一筋でやってきたんですが、思うところがあって今年の6月末まででエンジニアのチームを離れ、7月からUXチームで働いています。今
エンジニアアルバイトの僕が、社内で食パンを配るようになって学んだこと｜クックパッドマート
はじめまして、クックパッドマートの開発チームでアルバイトをしている劉です。現在東京大学理学部で計算機科学を専攻しており、この春から学部3年生になります。 このチームには2018年の11月にJoinし、もう半年近くが経ちました。日々移り変わる新規サービス開発の最前線で働くことは本当に刺激が多く、毎日たくさんのことを学ばせていただいています。 今日はそんな僕がクックパッドマートでやったこと、そこから学んだことを書きたいと思います。 クックパッドマートにJoinしたきっかけ僕は大学入学以降、サーバーサイドのエンジニアとしてアルバイトや個人開発を行ってきました。世界中の人に使ってもらえるようなサービスを自分の手で作りたい、というのがその主な動機でした。 アルバイトなどで関わってくださった方々の指導もあって、一年半が経つ頃には自分で思い描いた処理をある程度実装できるようになりました。しかし肝心のサー
「良いエンジニア」を言語化してみました
「VOYAGE GROUP エンジニアの公開ガチ評価会」に参加して、最近考えていた「良いエンジニア」像がかなり良い感じだと思うようになりました。 「ガチ評価会」自体の内容は他の方のブログに譲るとして、「ガチ評価会」で聞けなかった部分、つまり「普段だったら『ビジネス的側面からの技術投資判断』とかも聞くんだけど」と言っていたところが、まさに聞きたいところだったのでニヤッとしました。聞けなくて残念♪ 妥協ない挑戦元々ピクシブの技術力評価においては、「最近やった妥協ない挑戦は何ですか？」というのをキーワードにやってました。 解決すべき課題に対して、どういう背景があって、どういう事前調査をして、どういう実装をして、どう考察するか、というところまでをきちんと考えて仕事することに成長があるんだよ、というメッセージ性です。 そんなこと言っても普段は妥協ばっかりですって？いえいえ、相反する選択肢の中で、何を
新サービスを立ち上げる際、エンジニアとしてやって良かった 9個の事 - Money Forward Developers Blog
エンジニアの渋谷です。 マネーフォワードは3月30日に【給与計算ソフト - MFクラウド給与】という新サービスをローンチさせていただきました。 マネーフォワード、クラウド型給与計算ソフト『MFクラウド給与』(β版)を無料提供開始～法改正や税制改正にも自動対応。企業の給与計算・労務をもっとスマートに～ クラウド給与計算ソフト マネーフォワード クラウド上で完結する本格的な給与計算サービスとして、リアルタイム給与計算機能や料率自動反映などを備えております。 本サービスの企画自体は、昨年年末に３人でスタートし、年明けから様々な方にお手伝いいただきながら、約３ヶ月の開発期間でローンチしました。 今回は、新サービスをゼロから作り上げるにあたり、エンジニアとしてやって良かった、と思えた事を９つばかり紹介させていただきます。 １：リリース前確認シート 企画がスタートした時に、【ビジョン】【ミッション】と
エンジニアにとって良い組織とは何かを知りたい? - naoyaのはてなダイアリー
「エンジニアにとって良い組織体制ってどんなものですか? お話を伺いたいのですが･･･」と依頼をいただくことがあるが、都合上全部を受けてはいられない。ので、そういう疑問を持たれた方は以下の本を読むと良いかと思います。 How Google Works (ハウ・グーグル・ワークス) ―私たちの働き方とマネジメントposted with amazlet at 14.10.18エリック・シュミット ジョナサン・ローゼンバーグ アラン・イーグル 日本経済新聞出版社 売り上げランキング: 19 Amazon.co.jpで詳細を見る 小さなチーム、大きな仕事〔完全版〕: 37シグナルズ成功の法則posted with amazlet at 14.10.18ジェイソン・フリード デイヴィッド・ハイネマイヤー・ハンソン 早川書房 売り上げランキング: 7,579 Amazon.co.jpで詳細を見る Tea
エンジニアでも出来るサービスのアイデアの出し方 - ainameの日記
以前にも書いたのだけど、今年頭ぐらいからコード書く以外のことが出来るようになりたいと思い始めて、休日とか平日夜にコード書くのやめたり、休みの日に積極的に家の外に出るようにしてみたりしていた。 最初、自分が食べるのが好きなので食に関するサービスを考えようと思って、TokyoWallkerとかおとなの週末などの雑誌の情報や、友人らの情報を元にいろいろ外食してみたり、会社の近くの上手いパスタ屋さんが出版してるパスタのレシピ本を買って実際に自分で作ってみたり、肉フェスとか唐揚げフェスとかタイフェスなどの食イベントに参加してみたりしてみて、それ自体はまぁ楽しかったのだけど、サービスを思いつくまでに至らず。食に関して何かやろうと思うのは一旦諦めて違う分野で考えだした。 新しいサービスを考えるために、自分以外に2名（どちらも会社の同期で、1人はエンジニア、もう1人は総合職）とチームを組んで一緒に案出しを
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
