「エンジニアが事業を創る」ために必要な会社の構造とは イオンネクストCTOが語る“手段”と“目的”
「買い物を変える。毎日を変える。」 樽石将人氏：これを踏まえて、「エンジニアが事業を創る」というところ。（スライドを示して）イオンネクストの組織はこういうふうになっているので、これがどういうことなのかを今日は紹介したいなと思います。 結局イオンネクストのエンジニアとは何なのかは、これまでの説明でもなんとなく見えてきているのかなと思うのですが、エンジニアはデジタルの細部を熟知しています。 例えばパソコンの電源スイッチを押したらなぜログイン画面が出てくるのかとか、Googleで検索キーワードを入力したらなぜ目の前に検索結果が出てくるのかとか、そういった裏側の仕組みをみんな極めて熟知しています。 そういうデジタルにすごく精通した人たちが、オーナーシップを持って価値を創っていきます。価値というのはお客さまへの価値そのものを創り出していきます。 イオンネクストにはこういうエンジニアがたくさん揃ってい
Design Docs を活用して効果的にプロダクト改善
Design and Strategy: How to Deal with People Who Don’t "Get" Design
プレスリリース駆動開発のすゝめ - LayerX エンジニアブログ
機械学習・データ部 / データチームの @irotoris です。こんにちは。 データチームでは社内で使うデータプラットフォームやデータマートの開発をしています。今日は弊チームの開発スタイルの中から「プレスリリース駆動開発」を紹介します。 データチームの開発スタイル データチームの開発は1週間のタイムボックスで、月曜日にバックログやプロジェクトから今週取り組むタスクを計画し、金曜にスプリントレビューを行っています。デイリーでは夕会を行っています。ベロシティの計測などは今のところできていませんが、いわゆるスクラムっぽい開発です。 その月曜朝の計画会で、まずプレスリリースを書いています。 プレスリリースとはなにか？ 本来プレスリリースは新商品や新サービス、経営・人事などの企業情報を、ニュースとしてメディアに掲載する文書ですが、ここではデータチームが開発・提供する機能や改善をユーザーに伝えるため
『みんなで小さく区切ってやる』ガイド｜kawanotron
『みんなで小さく区切ってやる』とは『みんなで小さく区切ってやる』は複雑な問題を解決するためにみんな（チーム）で一緒になって改善していくためのやり方です。 『みんなで小さく区切ってやる』で大事な考え方は『経験から学ぶ』と『ちょっとずつ進める』です。小さく区切ることで、ちょっとやってみて、それから学び、またちょっとやってみる。それを繰り返しながら進みます。 『みんなで小さく区切ってやる』を上手にするには『見える化』『チェック』『改善』の3つが重要です。これにより『経験から学ぶ』効果を高めます。 機会を作る『見える化』『チェック』『改善』を取り入れるために5つの機会を設けましょう。これらの機会は毎回同じ時間に行うことでリズムが生まれいい感じになります。 『区切り』があることで立ち止まれます。立ち止まることで落ち着いて『チェック』し『改善』することができます。この『区切り』は1週間もしくは2週間に
「知識の呪い」、チームメンバーと以心伝心しているという思い込み - #あすみかんの上にあすみかん
私たちはスクラムを採用していて、プロダクトオーナーの私と、3人の開発者、そしてスクラムマスターというチームでやっている。 初期段階の頃は、頭の中のユーザーストーリーを開発者に伝えるのをめちゃくや丁寧にやっていた。 リファインメントでたくさん会話して、バイブスを伝えることに多くの時間を費やしていた。 たくさんの会話をしそれを簡潔にテキストに落とし込みバックログを完成させていた。 プランニングの時も開発者の帽子を被り、必要があったら口を挟みつつラジオ参戦していた。 数ヶ月も一緒にやっていると「今ある機能をもっと良くするならこうだよな」というのが開発者の中に思い描けるようになっていたし実際合っているので、リファインメントでたくさんの会話しなくても「あとはお任せ」の様にやれるようになっていた。 バックログを積み、リファインメントで意思疎通できてるな、ヨシ、をシュッと確認して、その後のテキストへの落
まつもとゆきひろ氏がソフトウェア開発に役立つ2冊の書籍を紹介 『失敗の科学』と『APIデザインケーススタディ』から学べること
まつもとゆきひろ氏がソフトウェア開発に役立つ2冊の書籍を紹介 『失敗の科学』と『APIデザインケーススタディ』から学べること #11 「失敗の科学」 オープニングトーク まつもとゆきひろ氏：まつもとゆきひろです。月曜日に放送して以来、ちょっと間が空いてしまいました。今日これを録音しているのは、（2022年）6月25日の土曜日なので、月曜日から土曜日まで録音できなかったということになります（笑）。 「Voicy」は、一発録りで流す仕組みで、編集をほとんどかけていないので、そういう意味で言うと、習慣化して毎日10分とか録れば、すぐに毎日できるようになると思うんですけれども、まだ習慣になっていないので、忙しいとこうやってつい後回しになって、じゃあ、次の日、とかなってしまいがちなのが現状です。 例えば、毎日「Wordle」をするとかですね（笑）、日記を書くとかですね、それから、「mruby」に1日
より良い Git コミットメッセージを書こう - Qiita
より良いコミットメッセージを残すことは Git を使った開発をする上で重要なことです。優れたコミットメッセージは、それを読んだ人がコードを理解するのに大いに役立ちます。 では、どのようなメッセージが良いもので、どのようなメッセージが悪いものなのでしょうか？ それについて掘り下げていきたいと思います。 基本的な Git Commit Message の書き方 詳しいところは、以下の3サイトを参照してください。特に「How to Write a Git Commit Message」には基本がすべて書かれています。 How to Write a Git Commit Message https://cbea.ms/git-commit/ Gitのコミットメッセージをうまく作成する7つのルール （「How to Write a Git Commit Message」の和訳記事） https://
これからのプロジェクトマネジメントに大事なのは「結果にコミットしない」こと クリエイティブな仕事に求められる“アジャイル思考”
不確実さが増す世界のプロジェクトマネジメントとはとういうものか 倉貫義人氏：そんな不確実さが増す世界のプロジェクトマネジメントはどういうものなのか。（スライドを示して）プロジェクトがうまくいかない（理由）というのは、このあたりを見てもらうと胃が痛くなりそうな言葉がいっぱい書いてあると思います。想定よりコストがかかるとか、作ったものを直せないとか。 （スライドを示して）これに対してどうすればいいかというと、「こうすればうまくいくのかな？」と考えがちですよね。「遅いからプレッシャーをかけようか」とか「少し遅れているので人を増やそうかな」とか「一気に作ったほうがいいんじゃないの？」とか「属人性を排除しましょう」とかと言いがちですよね。 これらはけっこう言いがちですが、全部失敗するやつです。これを全部やってみたら困ったことにプロジェクトが大変なことになるので、ぜひやってみたらいいと思います。 （会
開発生産性を上げるために開発をする前に考えていること - Findy Tech Blog
こんにちは。Findy Freelanceの開発チームでエンジニアをしている2boです。 この記事では私が開発生産性を上げるために開発をする前に考えていることについて書きます。 ここで「開発をする前」というのは次のようなタイミングを指します。 PdMなどから新規施策の仕様について相談を受けたとき 起票された開発Issueを最初に確認するとき 自分がIssueを作成するとき なぜこのタイミングで考えるかというと、開発を進める上での方向性を間違える可能性を減らし後から軌道修正をしやすくするためです。 なおこの記事においては、開発生産性を「開発成果物の提供価値を投入リソースで割ったもの」とします。 いくら頑張って開発をしても、そもそもやるべきことの方向性を大きく間違えると提供価値が0に近づくため開発生産性が低下します。 特に開発が高速なチームで方向性を誤ると高速に間違った方向へ進んでしまうことに
スクラム開発がエンジニアから成長機会を奪うかもしれない話 - 開発日報
おことわり 最初に断っておきますが、私はスクラム開発反対の立場をとっているわけではないです。また、スクラムマスターでもないのでスクラム開発について誤った見解を持っている可能性も大いにあります。 また、これから記載するスクラム開発のペインはあくまでも筆者の独断と偏見に基づいて記載されております。そのため、ペインの原因がスクラム開発ではなく、単にその所属組織の構成員の性質や文化的な要因であることも考えられます。おそらく、スクラム開発でなくても起こり得る問題も多く挙げていると思います。そういった側面も踏まえてご意見あれば忌憚なく反論異論いただければ幸いです。 なぜこの記事を書いたか チーム内で密なコミュニケーションをとりながら、個人ではなくあくまでもチームとしての成果を重視するスクラム開発の開発フローは、割と個人の活躍と成長機会を奪ってしまい、結果として組織としても開発成果が縮小均衡になってしま
開発生産性が上がるって分かったので GitHub Copilot Business を積極活用しています - Money Forward Developers Blog
エンジニアリング戦略室の高井といいます。 みなさん、GitHub Copilot は利用されていますか？ GitHub Copilot は GitHub と OpenAI が共同で開発した生成 AI を活用した開発支援ツールです。コードの自動補完、コード生成、ドキュメントの提案など、多岐にわたる機能を提供し、開発者の生産性を向上させることを目的としています。 マネーフォワードでは、昨年度にトライアルとして Copilot の利用を開始しました。本記事では、Copilot を利用して半年以上経過して、その利用がどのような効果をもたらしたかをレポートします。なお、ここで GitHub Copilot として言及されている Copilot のプランは GitHub Copilot Business です。 Copilot 利用状況・分析対象 なお、分析にはエンジニアリング組織のパフォーマンスを可
メンバーレイヤーから 開発生産性向上 を始めるために - Qiita
はじめに 開発生産性をテーマとした技術イベントに出まくった結果、ある程度体系化された知識のおすそわけ記事です。 この記事を読めばわかること 開発生産性のトピックでよく語られている前提の部分 開発生産性を語るうえで大事なざっくりとした体系的な知識 開発生産性を測るためによく使われるメトリクス 雑に言えば、数字とってデータ駆動でPDCA回そうという話です。 この記事を読んだ後に、「開発生産性の議論 ﾅﾝﾓﾜｶﾗﾝ ...。」という人でも「まずはこの辺調べてみよう」ができる状態になればいいなと思って書いてます。 この記事を読んでもわからないこと 開発生産性の文脈におけるビジネスサイドとのコミュニケーションらへん 開発生産性の文脈における経営層とのコミュニケーションらへん 目次 開発生産性についての前提 開発生産性と言うクソデカワードの認識をそろえる 開発生産性には３つのレベルがあることを知る な
今のチームに来てから最も生産性が上がった考え方｜牛尾 剛
多分今回のポストは多くの人には参考にならないだろう。相当ニッチなので。でもこれは自分にとってはとても大きなことだったので、忘れないように記録しておきます。 生産性の悩み あまりこの世界では生産性とはあいまいな言葉で、何をもって生産性が高いとは言いにくい。速いのが良いのではない。ただ、自分の実感として自分は生産性が良くないといつも感じていた。だからいろいろ努力したり、考え方をできる人を観察して真似してみたり、直接本人に聞いたりして工夫をしてきた。 実は自分はめっちゃコーディングが早い人になりたいわけではない。そうではなくて、「平均的」になりたいだけだ。それぐらいいければ「Strategy」でカバーできるどころかもっと上に行けると確信があったから。でもそうではなくて明らかに遅いのでそれが自分の足を引っ張っていた 努力の方向性 様々な努力をして、特に有効だったことを自分の本に書いたつもりではある
「グラブル」のリファクタリングに関する資料、Cygamesが無料公開 6人の専任チームのノウハウを紹介
2月に開催した、デベロッパー向けイベント「Developers Summit 2024」にて行った講演「『グランブルーファンタジー』100万行を超える大規模なシステム再構築～10周年のその先へ～」で使用したもの。全86ページに渡る資料を掲載した他、テックブログにて解説記事も公開中だ。 グランブルーファンタジーは、Cygamesが提供するスマートフォン向けRPGで、3月で10周年を迎えた。同ゲームでは、今後もサービス提供を続けていくために、100万行を超えるシステムの再構築を実施。その判断を決めた経緯や、手段、実際に遭遇した困難などについて解説している。 資料を作成したCygamesのサーバサイドエンジニアである伊藤顕二郎さんは「グラブルは数十人規模のエンジニアが開発・運用に当たっているが、リファクタリングに関しては6人のバックエンドエンジニアを中心に専任チームで進めた」と説明。「（リファク
失敗から学ぶシステム開発委託 - CARTA TECH BLOG
はじめに こんにちは、CARTA HOLDINGSでエンジニアをしているこんちゃん(@konchanSS)です。 この記事は筆者が新しく発足したプロジェクトのシステムを外部委託で作った経験をチームで振り返った際に得た学びを『システムを作らせる技術』によって補強したものです。 この記事を読んでくれた方は是非『システムを作らせる技術』を一読して欲しいです。 システムを知らないあなたにこそ読んでほしい この記事はビジネスサイドや、PdMだったりマネージャーといったいわゆるシステムの開発を依頼する側の人たちに向けて書いています。 意図した通りのシステムを作ってもらうための術を知ることはあなたにとって以下のメリットがあります。 意図した通りにシステムが動くことで業務の効率的になる 貴方がやろうとしているビジネスを促進させる システムを作ってもらうための術を知ることがなぜそのようなメリットを享受できる
ソフトウェア開発で「強いチーム」に何ができるのか？ ハイスキルなエンジニアたちを束ねるカケハシの挑戦 - Findy Engineer Lab
ソフトウェア開発に携わるエンジニアがキャリアを積むとマネージャーへの転身を余儀なくされた時代もありましたが、今ではIC（Individual Contributor）やスタッフエンジニアという働き方も周知となり、開発組織そのものをマネジメント対象とするEM（エンジニアリングマネージャー）を置く企業も増えてきました。 そんな状況を反映してか、株式会社カケハシの椎葉光行（@bufferings）さん、小田中育生（@dora_e_m）さん、荻野淳也（@ogijun）さんの3人は、それぞれチームをリードできるシニアなエンジニアでありながら、現在は同じチームのメンバーとしてともに開発に取り組んでいます。 新たに採用するハイキャリアなエンジニアを既存の開発組織にどうフィットさせるかに課題感を持つ企業もありますが、このように複数のシニアを集めたスーパーチームで開発にあたることにどういった意義があるのでし
フィードバックを早く受けた方か早く終わる - りまりまだんの本拠地
雑感です。実力は同程度、または仕事が終わる人の方が能力値が低い状態を想定しています。 仕事が終わらない人の特徴 1回目のレビューが遅い。〆切ギリギリに出てくる。仕事がほとんど終わった後に始めて出てくる。 やり直しの幅が広いので直すのに時間がかかる。「何でそうするの？」の質問に答えられず詰められる。考えたときのことを忘れているので思い出さないといけない。 取り繕ったりすると矛盾が出て突っ込まれる。信頼度が下がってチェックが厳しくなる…。 という感じで悪循環が永遠に続く。 仕事が終わる人の特徴 次のタイミングでレビューを受ける。 取り掛かる前 進捗が1/3程度進んだとき 詰まって質問後、教えてもらった物を直したらすぐ 不安なところが出てきたとき。15分程度で考えをまとめてから とにかくやることや意図をまとめてすぐ見せる。じっくり見てくれる相手がいなくても「見える状態には」する。 戻しや方針転換
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
(新人)エンジニアが開発しやすいREADMEの書き方
生成AIによるプロダクトと生産性向上の舞台裏@2024.04.16
【Developers Summit 2024フォローアップ】『グランブルーファンタジー』100万行を超える大規模なシステム再構築～10周年のその先へ～
