開発生産性の現在地点～エンジニアリングが及ぼす多角的視点 / Current status of development productivity2024/2/15 Developers Summit 2024 登壇資料 https://event.shoeisha.jp/devsumi/20240215
2023年・新しく入ったメンバーの提案で開発チームが良くなったこと5選
このブログは、 IVRy 紅白Advent Calendar 2023の白組・17日目の記事です。 白組16日目は PdM佐瀬さん「IVRyなら上流からUX/UIデザイン業務が実践できます！」でした。明日はIVRyのVPoE近藤さんの「IVRyにおける開発生産性へのアプローチ～SPACEフレームワークの視点から～」についての記事が出ます。乞うご期待。 この記事について タイトル通り、2023年に提案されて改善した事を発表するのですが、裏返すと「そんなこともできてなかったのか」と見える内容もあるかもしれません。ネガティブに受け取られる可能性もあるかもしれませんが、IVRyのオープンな社風や、常に改善と変革に前向きな姿勢をアピールするためにも、この記事を執筆することにしました。 なお、課題を発見・解決しながら会社を大きくしていきたいエンジニアの皆さんは、ぜひブログ一番下のIVRyの採用情報から
会議全部ふっとばして社員の集中力を10xした話(ビッグバン) - 10X Product Blog
こんにちは！経営企画の仕事をしているudonです。1年半前の見習いQA以来、2度目の文章です。今回は10X社内の会議のルールを整理し、そして全社員の未来のカレンダー予定を一旦全部消す、通称「ビッグバン」の第一回を実施したのでその背景や内容について書きます。 (イメージ) 10Xでは社内におけるコミュニケーションを大きく「同期」「非同期」に分けています。同期は会議や突発的な電話など同じ場にいることが前提であるコミュニケーションを指し、Slackなど非同期は必ずしも同じ時間での往復を前提としない文章やドキュメントによるコミュニケーションを指します。入った当初は「ドウキ・・？ヒドウキ？？」とドキドキしてた私ですが、2年も経つと慣れてしまいました。慣れって怖いですね。 話が長いという皆様の期待を裏切ることなく、タイトルにもなっているビッグバン(会議の全削除)の話にいくまで5,000文字嵩んでしまっ
エムスリーで活躍する人の型を観察してみた その１ - エムスリーテックブログ
こんにちは、プロダクトマネージャーの髙田です。辛いものが好きです。 最近は、昼ごはんに台湾ラーメンを食べて、夜に二郎インスパイアで台湾まぜそば（辛口）を食べました。 麺半分コール忘れて胃が爆発 入社からいつのまにか1年経過し、振り返りも込めてエムスリーで働く人を「観察」して学んだことを書こうと思います。 私は入社後半年ほど、インプット8：アウトプット2の時間の使い方をしていて、特に最初の3ヶ月は「エムスリーの型・勝ちパターン」のインプットを重点的に行っていました。 具体的には、 コミュニケーション・行動・思考法などをMTGやSlack等から観察し 学んだことを週1で取締役CTOの山崎さんに報告 会話を通してさらに学びを深める＆誤学習してないか確認 という手順で進めていきました。 この一連の経験が今でも役に立っていると感じる & 入社初期に「見習うべき型・勝ちパターン」のインプット期間があっ
余計な「念のため」でプロジェクトが死に至る「オーバーエンジニアリング」の問題とは？
日本に「過ぎたるは及ばざるがごとし」ということわざがあるように、海外のソフトウェア開発現場でも製品が必要以上に複雑化してしまう「オーバーエンジニアリング」という現象がしばしば問題になります。そんなオーバーエンジニアリングの原因や影響、防止方法について、ボイスチェンジャーアプリの開発会社・Voicemodで主任プロダクトマネージャーを務めるシモン・ムニョス氏が解説しました。 Overengineering can kill your product - Mind the Product https://www.mindtheproduct.com/overengineering-can-kill-your-product/ ソフトウェアエンジニアとしての経験を持つプロダクトマネージャーのムニョス氏によると、「ありもしない問題を解決するためのコードやデザイン」と形容されることもあるオーバーエン
プロジェクトが大変になってきたときは大変とちゃんと言うのが重要 - hitode909の日記
このままのペースには締め切りに間に合わない、とか、作ろうとしていたものが思っていたより難しかった、みたいなときに、普段よりペースを上げたり、時間をのばしたり、一部の仕事を他の人にお願いしたりして、がんばって進めることがある。 そういうときに、チームメンバーの中で一人だけ突然ギアを上げていると、周りの人からは、なんで突然に急いでるのか？と奇異の目で見られるかもしれない。 プロジェクトの進捗が悪いです、とか、このままでは危うい、危機的状況です、みたいなことを言うのは、なかなか言いづらい、言うのに躊躇するようなことかもしれない。未来のことだからわかりませんし、楽観的に見ると後半の伸びで追いつけるでしょう、みたいに、大丈夫、と言ってしまうこともできなくはないだろうと思う。 でも、プロジェクトの現状は悪い状況です、ということはちゃんと言って、共通認識として持ってしまったほうが、いまは非常時なのでちょ
既存の機能から設計を学び、調査力を向上させて、知見を共有しよう - Hatena Developer Blog
はてなブックマークチームの id:itchyny です。 チームのメンバー間で知見を共有することは、とても大事なことです。 特に開発エンジニア同士のコミュニケーションを増やし、お互いに足りていない知見を共有し合うことでチームの生産性を向上することは、プロダクトの成長につながります。 プロダクトの実装や設計の知見を共有するためによく取られる方法として、詳しい人が講義形式で教えるというスタイルがあります。 特に、チームに新しいメンバーが入ったときには、プロダクトの概要やコードのアーキテクチャについて説明することは一般的に行われています。 講義形式で教えるというスタイルはよく行われる方法でありながら、いくつかの課題があると感じています。 まずは説明会に参加するメンバーが、どうしても受け身になってしまいます。 説明された瞬間は分かったような気になっていても、次の週には忘れてしまうことはよくあること
他チームにも知っておいてもらいたいAndroid/iOSのリリース知識 - Kyash Product Blog
Kyashの@konifarです。 Kyash社内で共有していた『他チームにも知っておいてもらいたいAndroid/iOSのリリース知識』というドキュメントを公開したので、簡単に背景を書いておきます。 内容は公開先のGitHubリポジトリを見てください。 recruitment/mobile_basic_knowledge.md at master · Kyash/recruitment · GitHub 社内で共有していた背景 チームでAndroid/iOSアプリを運用しリリースしていく場合、前提の知識が揃っていないとコミュニケーションを取りにくいことがあります。 実際にKyashでも次のようなリリース直前にバタつく問題が何度か発生していました。 アプリの申請までに本番環境サーバーにデプロイしておく必要があるのをサーバーサイドのメンバーが認識していなかった 段階的にアップデートする方針を
自走するエンジニアが育つ組織の作り方
ピナクルズの CTO をしている渋谷です。「現場向け動画 DX」を実現するための SaaS『tebiki』を開発しています。 今回は、マネージャー向けに「もしメンバーに自走してほしいなら、個人のメンタリティに期待するのではなく、組織で相互にアドバイスし合うプロセスを構築したほうがいい」という話をしたいと思います。 エンジニアの求人サイトを検索してみると、求める人物像や歓迎するスキルに「自走力のある人」と書いている企業がたくさんヒットします。 これだけ書いてあるということは、自走する能力を備えていることがもはやエンジニアの必須条件のように思えてきます。 ですが、自走するかどうかはその人個人のメンタリティよりも外部要因のほうが遥かに大きいと私は考えています。どんなに自走できる人でも、ほとんどの場合で権限移譲された範囲までしか自走はできないからです。上司の知らないうちに「新サービスリリースしてお
チーム内にもあった“ヤバい”空気感 メルペイチームが技術的負債をゼロにするためにやったこと
merpay Tech Talk は、エンジニアたちが集まり、技術的な知見を共有しあうことを目的とした勉強会です。今回は、「全員品質」を目指すメルペイのQAエンジニアたちが日々の取り組みについて話しました。櫻井氏は、Credit Designチームにおける技術解消のための取り組みと、それにより生まれた新しい文化・習慣について発表しました。 「メルペイスマート払い」の開発を担うCredit Design 櫻井みづき氏（以下、櫻井）：メルペイでQAエンジニアをしている櫻井みづきです。今日は「より良いサービスを継続的に届けるための新しい習慣ができるまで」というテーマでお話していきたいと思います。 まず本日のアジェンダです。今日は3つのことを中心にお話しします。今日のテーマを話すのにあたって、Credit Designというチームでの取り組みについて紹介していきたいと考えています。なのでCredi
リーンコーヒー（Lean Coffee）のすすめ - SMARTCAMP Engineer Blog
スマートキャンプのプロダクトマネージャーの郷田です。 皆さんは普段の業務で、以下のように感じる場面はありませんか？ - 「同じチームで働くあの人と、いつもなんだか認識がずれてるかもと感じる」 - 「一通り会議はやったものの、なんだかいまいち話しきれてないようなモヤモヤがある」 - 「あの人にはもっと注力してもらいたいことがあるのに、なかなかそこまでやってもらえない」 こういった場面に遭遇したときには、リーンコーヒーを実施されることをおすすめします！ この記事では、チームのMTGで活用してみていただきたい「リーンコーヒー」を紹介します。 リーンコーヒー（Lean Coffee）とは？ リーンコーヒーの進め方 準備するもの その１：トピック出しと優先順位の決定（5分~15分） その２：トピックのディスカッション（10分〜45分） 初めてのリーンコーヒーでのハマりどころ 継続するかの判断をせずに
3年間のオンボーディングで培われた、リモートでも効果的な7+3のプラクティス
現場主導で始まったHRMOSの開発組織のオンボーディングは、ほぼ毎月、地道に運用と改善を続けてきました。2018年に開始してから3年近くになりますが、エンジニアを対象に始まり他職種のメンバーを巻き込みながら、効率と効果の両面を少しずつ洗練させてきました。この記事では、私たちのオンボーディングを定義や効果を俯瞰しながら紹介し、その中で徐々に確立されてきたプラクティスをご紹介します。 変化の時代に不可欠なオンボーディング オンボーディングとは採用や異動によって組織に加わった人材の早期戦力化のための施策であり、 組織に新しく加わった人材を1日も早く戦力化し、組織全体との調和を図ることを目的とした育成プログラムのことを指します。『機内』や『乗船』という意味を持つon-boardから派生して生まれた造語であり、直訳すると『飛行機や船に乗り込んでいる』という意味です。 〜 BizHint などと定義さ
リモートワーク時のアジャイルソフトウェア開発チームに役立つ6つのベストプラクティス
ガートナーの米国本社発のオフィシャルサイト「Smarter with Gartner」と、ガートナー アナリストらのブログサイト「Gartner Blog Network」から、＠IT編集部が独自の視点で“読むべき記事”をピックアップして翻訳。グローバルのITトレンドを先取りし「今、何が起きているのか、起きようとしているのか」を展望する。 2020年、リモートワークへの移行が一気に進み、ソフトウェアエンジニアリングやアプリケーションのリーダーからは「開発スピードが低下するのではないか」と懸念する声が上がった。 もともと、アジャイル開発チームは自律性や変化への適応性が高い。だが、アプリケーション技術者の集団として力を発揮し続けるには、緊密なコラボレーションやフィードバックループ、ダイナミックな交流といった強力なチーム文化を維持しなければならない。 Gartnerのアナリストでシニアディレクタ
TechCrunch
Pour one out for CodeWhisperer, Amazon’s AI-powered assistive coding tool. As of today, it’s kaput — sort of. CodeWhisperer is now Q Developer, a part of Amazon’s Q family of b The European Commission has again been urged to more fully disclose its dealings with private technology companies and other stakeholders, in relation to a controversial piece of tech policy that coul
道の真ん中をきれいにするプロジェクトマネジメント～イケてるチームになるための10原則～ - Qiita
はじめに 私が好きな江戸の小話的なものに、こういったものがあります。 江戸下町では、道向かいのそれぞれが軒先を掃くときに、道の真ん中よりもちょっと向こうまで掃くのがならわしだったそうです。両側の人がそれぞれ真ん中よりも向こうまで掃くので、道の真ん中が一番きれいになる、というお話です。 近年こうした「江戸しぐさ」のようなお話は、真偽のほどが定かではないとして、流布することに批判もあるようです。実際この話も正直事実かどうかは全くわかりません。 ただお互い完璧ではない他人同士が肩寄せ合って共に生きる知恵といいますか、プロジェクトへの参画姿勢について良い示唆を与えてくれる話だと思い、その前提で使っています。 実際私が関わる案件のキックオフでもお客様や関係者によくこの話をするのですが、「キックオフでの『道の真ん中の話』、他の現場でも最近してるんですよ」とお客様やパートナー様から言っていただけたことが
エンジニアが事業に寄り添うことで、結果的に技術的負債が減る話 - エス・エム・エス エンジニア テックブログ
高齢社会に適した情報インフラを構築・提供する株式会社エス・エム・エスで、エンジニアをしている三田淳一です。2020年1月に入社し、介護事業者向け経営支援サービス『カイポケ』の開発を担当しています。 今回、エス・エム・エスの開発体制がどうなっているのか。開発体制が変わることによって、どのような変化が生まれているのかについて紹介していきたいと思います。 エンジニアと事業がフラットではない環境で生じる課題 ソフトウェアシステムの開発組織は、事業やサービスの企画・運営などを担う事業側からリクエストがエンジニアに下りてきて、エンジニアはそれに沿って開発するという、トップダウンのような構造になっていることがほとんどです。事業側とエンジニア側で、優劣がある状態ですね。 こうした環境では、自分のチームのメリット効率を優先して行動し、他のチームに対して非協力的になることも起こりやすくなります。例えば、事業側
チームや個人レベルで進捗を出すために最近やっていること - Lambdaカクテル
最近とあるサイトの新規リリースにかかわることができて，そこで得られた学びをフィードバックするという活動をやっている．具体的には運用で使えるIssue Templateを整備したりしているのだけれど，自分やチームの進捗管理みたいな分野でもフィードバックすることができたのでメモしておく． 毎日エンジニアMTGを開く 毎日Scrapboxに残タスク・進捗を書きチームで共有する 毎日の適当な時間を割いてMTGを開く MTGでやること 結果どうだったか 個人レベルの話 ページの内容 1日の流れ 終わり 毎日エンジニアMTGを開く スクラムっぽい話題?かもしれないけれど，自分のチーム(エンジニアは2人)の規模ではこれでうまくいった． 毎日Scrapboxに残タスク・進捗を書きチームで共有する 昨日からコピーしていく 毎日の適当な時間を割いてMTGを開く 話すことそんなになくても予定は作るしMTGは開く
組織の"わからない"に対する不快感 - Konifar's ZATSU
組織の中で何らかの歪みを感じる時、その根っこにはある人が関係する物事について「わからない」「知らない」という感覚があることが多い。 例えば「なんでこんな非論理的な意思決定するのか。アホじゃないのか」と感じた時、本当にアホなこともあるかもしれないが、判断材料となる情報が正しく伝わっていなくてそう感じるだけということも多い。1対1で色々聞いていくと「なるほど、たしかにそれならそうなりますね」と納得できるのに、情報が欠落しているだけで不和を生むのだ。 情報だけではなく、人格も同じである。仲のいい人から言われる冗談は笑ってやりとりできても、よく知らない人から同じことを言われると嫌な気持ちになることもある。 組織において、こういった「わからない」が積み重なると雰囲気が悪くなっていく。「あのチームは」「あの人は」といった形でわからないものを自分とは違うものとして表現して、一体感がなくなるのだ。なんだか
KyashでEngineering Managerとしてやってきたこと / やっていくこと - Konifar's WIP
2020年1月から1年ほどKyashでEMをやっています。 今までチームをリードしてきたことは何度かありましたが、いわゆるマネジメントという役割は初めてでした。EMについて抽象化した話ができるほど自分の中で咀嚼できているわけではありませんが、思考整理を兼ねてやってきたこととやっていくことをまとめておこうと思います。 ここに書く内容は当然自分だけでやってきたわけではありません。他のメンバーによって支えられてきたことの方が多いです。文章量の都合で端折ることもありますが、自分だけで色々やってきたみたいに捉えられるとなんだかむず痒い気持ちになるので一応前提として書いておきます。 1~6月 : Android/iOSチームのEM 1月にiOSエンジニアが1名入社したタイミングで、Android/iOSチームのEMをやることになりました。 それまではTechチーム全体を@ymzkmctが見ていましたが
フィードバック入門 耳の痛いことを伝えて部下と職場を立て直す技術 - hitode909の日記
自分はマネージャではないのだけど、おすすめされたので読んでみた。 これまで、1on1でのフィードバックというと、まずは良いニュース、そして悪いニュース、そしてさらに良いニュース、みたいなサンドイッチ技しか知らなかったけど、この本では体系化されていて、こういう考え方でやりましょう、というフレームワークを教えてくれたり、後半では具体的に、こういうときはこうするべし、みたいなテクニックを教えてくれる。ちなみに、この本では、サンドイッチ技は都合の良いところだけ記憶に残るのでよろしくないとされている。 前半の、枠組みを教えてくれるところはおもしろかった。客観的なデータを集めに行こう、とか。あとは、学生のときにバイトで入ってすぐくらいのときに、社長がぷらぷら歩いていて、元気?楽しい?って聞いてきて、この人はなんでプラプラ歩いてやってくるんだろう?と思ってただけど、こういう本を読むと、声を書けて回って情
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
