@IT 開発変革セミナー 2024 春 ~Spring~ ~効率化、コスト削減にとどまらない、システム開発の在るべき姿~ 基調講演2 https://members09.live.itmedia.co.jp/library/Njc3Nzc%253D
こんにちは。Findy Freelanceの開発チームでエンジニアをしている2boです。 この記事では私が開発生産性を上げるために開発をする前に考えていることについて書きます。 ここで「開発をする前」というのは次のようなタイミングを指します。 PdMなどから新規施策の仕様について相談を受けたとき 起票された開発Issueを最初に確認するとき 自分がIssueを作成するとき なぜこのタイミングで考えるかというと、開発を進める上での方向性を間違える可能性を減らし後から軌道修正をしやすくするためです。 なおこの記事においては、開発生産性を「開発成果物の提供価値を投入リソースで割ったもの」とします。 いくら頑張って開発をしても、そもそもやるべきことの方向性を大きく間違えると提供価値が0に近づくため開発生産性が低下します。 特に開発が高速なチームで方向性を誤ると高速に間違った方向へ進んでしまうことに
はじめに 弊社マイベストでは、エンドツーエンドの機能開発チームとは別で、組織の価値提供能力を高めることを目的としたイネーブリングチームがあります。(と言ってもまだ他チームとの兼任メンバーがほとんどですが) イネーブリングチームは、バックエンドやフロントエンドなど、領域ごとに技術課題を解決すべく活動していて、自分はフロントエンド領域を担当しています。 これまで様々な活動を行ってきたので、その考え方を整理しつつ、フロントエンドイネーブリングの実践例をご紹介したいと思います。 参考:マイベストのチーム構成イメージ(記載は一部のみ・名称は仮です) 「イネーブリングチーム」とは イネーブリングは『チームトポロジー 価値あるソフトウェアをすばやく届ける適応型組織設計』、通称チートポから持ってきた名称なので、まずはチートポをベースにその役割を説明します。 https://amazon.co.jp/dp/
2月に開催した、デベロッパー向けイベント「Developers Summit 2024」にて行った講演「『グランブルーファンタジー』100万行を超える大規模なシステム再構築~10周年のその先へ~」で使用したもの。全86ページに渡る資料を掲載した他、テックブログにて解説記事も公開中だ。 グランブルーファンタジーは、Cygamesが提供するスマートフォン向けRPGで、3月で10周年を迎えた。同ゲームでは、今後もサービス提供を続けていくために、100万行を超えるシステムの再構築を実施。その判断を決めた経緯や、手段、実際に遭遇した困難などについて解説している。 資料を作成したCygamesのサーバサイドエンジニアである伊藤顕二郎さんは「グラブルは数十人規模のエンジニアが開発・運用に当たっているが、リファクタリングに関しては6人のバックエンドエンジニアを中心に専任チームで進めた」と説明。「(リファク
はじめに こんにちは。BASEのデータ分析チーム(Data Strategy Team)で不正対策を行ったり、機械学習モデルを触ったりしている竹内です。 先日チーム内の論文読み会でニューラルネットを用いた画像合成によるバーチャル試着技術というトピックに触れる機会があったので、その最近のトレンドについて改めてブログという形でまとめてみました。 バーチャル試着は画像生成モデルの実用的なユースケースの一つとして今現在データセットの拡充やアーキテクチャの検証が進んでいる分野の一つであり、個人的には非常にアツいトピックだと感じています。 バーチャル試着とは バーチャル試着(Virtual Try On)とは、ある人物がある衣服を着用した状態を画像や3Dモデルなどの情報をもとに仮想的に実現し、どのように見えるか可視化する技術のことです。 ネットショップの普及により、店頭に出向かずともPCやスマートフォ
こんにちは。エンジニアリンググループの武井です。 私は現在、デジカルチームに所属し、クラウド電子カルテ、エムスリーデジカルの開発に携わっています。 昨年夏にエムスリーに入社し、早くも半年が経過しました。 digikar.co.jp この記事では、私が入社してから4ヶ月目に取り組んだ、バッチ処理の運用改善について振り返ります。 特に、新しくチームに加わったメンバーとして意識した点に焦点を当ててみたいと思います。 これから新しいチームに参加する方の参考になれば幸いです。 改善したバッチ 現状の正確な理解 現状に馴染む技術選定 自分なりの+αを加える 改善の結果 We're hiring 改善したバッチ 今回の改善対象は、特定の医療機関に紐づく全患者の全カルテをPDFファイルとして出力する、というバッチです。 デジカルのデータを医療機関側にエクスポートする用途で使われています。 移行前のアーキテ
Most of Slack runs on a monolithic service simply called “The Webapp”. It’s big – hundreds of developers create hundreds of changes every week. Deploying at this scale is a unique challenge. When people talk about continuous deployment, they’re often thinking about deploying to systems as soon as changes are ready. They talk about microservices and 2-pizza teams (~8 people). But what does continuo
Version 1.1.0 # Changelog All notable changes to this project will be documented in this file. The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.1.0/), and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0.html). ## [Unreleased] ### Added - v1.1 Brazilian Portuguese translation. - v1.1 German Translation - v1.1 Spanish translation. - v1.1 Italian
はじめに システム開発において詳細設計という工程があります。 プログラマーはこの詳細設計を確認しながら開発を行うことになります。そのため詳細設計ではシステムの構造や仕様、動作などを細かく定義することが必要になります。 詳細設計を行うことでシステム開発の方向性が明確になり、コーディングやテストをスムーズに行うことができます。 詳細設計の成果物としてはクラス図やシーケンス図、画面設計書やデータベース設計書などがあり、システムの動きや機能を具体的に表現するものです。 今回は詳細設計を作成する機会があったので、詳細設計の書き方についてまとめたいと思います。 詳細設計の目的やメリット 詳細設計の目的は、システム開発の品質や効率を向上させることです。詳細設計では、システムの仕様や動作を細かく定義することで、以下のようなメリットがあります。 開発工程でのバグや遅延を減らすことができる テスト工程での不具
目次 目次 はじめに NeWork とは リリース頻度変更の背景 それまでの運用 課題 実現方法 解説 日次でワークフローが起動するようにする main ブランチの HEAD にタグが付与されていなければ付与する develop に差分があれば main へのマージを自動で行う 細かな工夫点 main の内容を develop に自動で取り込む 祝日はリリースしないようにする 自動リリース・自動 develop → main マージの制御 Slack にリリース結果を通知する stg 環境に変更内容を通知する その他の考慮 上司への事前説明の省略 スプリントレビュー前のリリース リリースノート 品質面 リリース頻度を変えてみて おわりに はじめに こんにちは、NeWork 開発チームの藤野です。普段はオンラインワークスペースサービス NeWork のエンジニアリングマネジメントをしています
昨今ではSNSやフォーラム上でユーザーからのフィードバックを募るゲームも多く、さまざまな意見が投じられ、開発に活かされている。一方でゲームが抱える課題の原因特定や、特定の要素に向けた“より良いアイデア”については、開発者としての経験がないと検討が難しいようだ。『Starfield』の開発者や国内のゲーム開発者らが「開発過程や内情を知らないユーザーからのアイデア提案や批判」についての問題を指摘し、注目を集めている。 『Starfield』は、『The Elder Scrolls』シリーズや『Fallout』シリーズの開発で知られるBethesda Game Studiosが手がけるRPGだ。本作の舞台は人類が太陽系外に進出した2330年の世界。プレイヤーは希少なアーティファクトを求める宇宙探検家集団コンステレーションの一員として、広大な宇宙の星々を冒険することになる。本作には100以上の星系
最近、ソフトウェアデザイン読んだり、個人開発LT会の話を聞いたりして、 個人開発の成功っていろいろあるよねーと思ったので、ちょっと整理してみたときの備忘録(*´ω`*) 収益化や売却だけが成功じゃないし、もしかしたら失敗もないかも知れない(*´ω`*)? individual-development.connpass.com 成功するとは あらためて、Wikipediaで意味を調べていみると、 こんなふうに書いてある。 成功は、計画などがうまくいき目標が達成できたことや、社会的に一定以上の地位を得たことを指す。失敗の対義。 成功 - Wikipedia 人それぞれ、サービスそれぞれで、 目標・目的は違うので、成功の意味も違う。 目的のタイプ/パターン ざっくり、この3つになるんじゃないだろうか? 収益 実現 経験 収益タイプ お小遣い程度、生きていけるほど、など度合いは違えど、 収益を目指
IT子会社が設立される主な理由はコスト削減。課題はIT戦略立案能力、待ちの姿勢、先進技術の習得など。ガートナーの調査結果 ガートナージャパンは、国内のIT子会社の実情に関する調査結果を発表しました。 調査は国内の従業員500人以上、売り上げ規模1000億円以上の企業のCIO、CTO、IT担当役員、最高デジタル責任者、デジタルビジネス推進担当役員などを回答対象者として実施されました。有効回答は300社。 回答した企業のうち、「連結対象」「連結対象外」「ITベンダーなどと共同出資」のいずれかに該当するIT子会社を持つ割合は38.0%。 調査結果では、IT子会社設立の主な理由はコスト削減で、親会社から見た喫緊の課題はIT戦略立案能力、受け身の姿勢、スピード感、先進技術の習得などと説明されています。 IT子会社を設立する理由はコスト削減 IT子会社を持つ企業に、設立している主な理由を上位3つまでの
有償ソフトウェアを売る方法分かんなすぎるから、気軽に相談できる人欲しくなってきた...。 ・寄付募集型か、有料で一部の機能を解放する型か ・価格設定 ・有料で一部の機能を解放するなら、どこまで有料にするか ・買い切り型か、月額サブスクリプション型か とかとか、考えること無限にある。。 — Cside (@Cside_) October 2, 2023 個人開発ではないが、課金については仕事で結構やってきてまぁまぁの知見を得た。かつて自分も情報を得ようとネットで探してみたが、極めて情報が少なかった。ソフトウェア開発についてのノウハウは結構ネットに転がってるが、値付けなどについての情報は少ない。エンジニアとマーケッターでは文化が違うのかもしれないが、そもそも値付けに関しては商材(ソフトウェア)によって様々なので定石がなく、結局のところ自分で試してみないと正解がわからないのではないかと思う。そう
大きなPull Requestのレビューがつらい 修正ファイル数が多いこと自体が問題なのではない 1つの内容に集中する 小さなPull Requestの作り方 リファクタリングの修正は気になっても別で出す Web API 1つに着目して実装を切り分ける 小さなPull Requestで作ったときのリリースの仕方 featureブランチを作って、そこから更にブランチを作っていく フィーチャートグルを使う 小さいPull Requestで小さくフィードバックをもらおう 大きなPull Requestのレビューがつらい 転職ドラフトでWebアプリケーションエンジニアをしている @iwtn です。 この記事ではチーム開発では当たり前になったレビューにおいて、修正されたファイルがたくさんあるとつらいよね、というお話と、その解決策を提示してみたいと思います。 昨今のWebアプリケーションなどのチーム開
読み飛ばしてください みなさまどうも。 限界派遣SESと言われて心が折れるnikawamikanです。 最近、学生さんと一緒になんやかんや開発することがあり、その中で使ってみてよかった技術の中にDev Cointanersと言われる技術があります。 VSCode限定ではありますが、開発環境の差異を可能な限り埋めてくれるスゴイやつです。 さらに言えば新たにチームに参加するメンバーに開発環境の構築を逐一説明する必要もなくなるので、入れ替わりの激しい限界派遣SESにこそ使う技術です。 本題 前提として以下の環境はインストールされているものとします。 Docker docker compose (WindowsやMacの場合DockerDesktopをインストールしているのでインストール不要のはずです) VSCode OSは上記がインストールできるのであればわりとなんでもOKだと思います(例外はど
私は普段、お客様のチームに入り込み、SEとして仕事をしております 今日はそのチームで実際に起こった出来事からなぜか勝手に敗北感を味わった話をしたいと思います まずなにがあったか 普段すでに本番運用がされているシステムに新規要件を実装してまして、定期的に新機能をリリースするようなそんな運用となっています そんな中のある日、定例(朝会)の中で、直近リリースで発生したインシデントの共有がありました えーっと実は昨日〇〇という障害が本番環境で発生してその対処をしてました 調べてみた結果、原因は〇〇さんのこのプルリクでして (私:おいおい個人名だすのか!! このファイルのこの行でNullチェックが漏れてました (私:わわわわ、公開処刑だぁぁぁ まぁたしかにこの辺はほげほげふがふがで (私:ふむふむさすがにフォロー入るかぁ でもテストやレビューでちゃんとカバーしときたかったですね (私:全員巻き込んで
こんにちは、エンジニアリングオフィスのなかむら(@rh1011_)です。 このチームは以下に責任を持ち活動を行っています。 HRチーム、現場開発チームと密に連携しながらの採用活動(DevHR) 技術・組織カルチャー広報(DevRel) 社内エンゲージメント よろしければCTOの作成記事がありますのでご覧ください。 はじめに なぜ採用するのか hacomonoの魅力と、やるべきことの洗い出し ひたすら実施 ①テックブログ ②イベント企画、登壇 ③協力いただくエージェントとの信頼感の醸成 ④熱いスカウト ⑤候補者体験の向上 今後の課題 エンジニアリングオフィスとして おわりに 参考リンク 想定読者 スタートアップで採用に取り組んでいるエンジニア、エンジニアマネージャ、HR 話さないこと 採用マーケティングチャネル別の施策詳細 はじめに hacomonoはこの1年間でエンジニア、プロダクトデザイ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く