社内勉強会：失敗談LTを開催しました！ vjsigsigです(｀･ω･´)ゞ 私が所属している技術開発WG（ワーキンググループ）にて、主に若手をターゲットに失敗に対する敷居を下げ、より挑戦的な取り組みを行ってもらいたいというエールを込めて失敗談LTを開催しました。 今回は5名の登壇者に発表をいただきました！ コードレビュー出さずにリリースして12時間の緊急メンテをやらかした話 慢心と怠慢により起こした事故を紹介。テストの大切さも併せて伝えることのできた発表です。 本番環境での作業ミスで週末にシステムが死んだ話 作業を行う前に事前に計画を立て、ダブルチェックを行う事の大切さを学びました ソシャゲで初めてカード作ったらめちゃくちゃ強いカードをリリースしてしまった話 簡単な計算式でも予期せぬ結果が生まれることがあるように、バランスが重要なものづくりでは、複数人の視点や協力が欠かせない。ゲーム開発
この記事は 一休.com Advent Calendar 2024 7 日目の記事です。 宿泊事業本部 ユーザー向け開発チームの原です。 一休.com と Yahoo!トラベルの主にフロントエンドの開発を担当しています。 今回は、普段の開発でコードを書き始める前段階で Design Doc を作ることで、円滑な開発を進められるようになったというお話をします。 チーム構成について まず、前提を共有するために私達が普段どのような体制で開発しているかを説明します。 私が所属している宿泊事業本部 ユーザー向け開発チームは、一休.com と Yahoo!トラベルの主に toC のユーザー向けの機能開発をしています。ユーザー向け開発チームのメインのミッションはユーザー体験を向上させることであり、そういった施策の機能開発を素早くリリースできることを大事にしています。 一方、プロダクト開発においては機能開
時間と労力の浪費につながる「認知負荷」とその軽減方法を、ソフトウェア開発会社・Inktechで最高技術責任者(CTO)を務めるアルテム・ザキルリン氏が解説しています。 Cognitive load is what matters https://minds.md/zakirullin/cognitive ザキルリン氏によると、認知負荷を一言で言うと「開発者がタスクを完了するためにどれだけ考える必要があるか」になるとのこと。 平均的な開発者は、コードの変数の値、制御フロー ロジック、呼び出しシーケンスなどの要素を平均して4つほど頭に入れて作業を進めることができますが、この基準を超えた認知負荷が発生すると、途端にコードを読むのが難しくなります。 そのため、プロジェクトの認知負荷を可能な限り軽減するのが肝要ですが、ソフトウェア開発のコアな部分の認知負荷は変えることができないので、必要以上に難解に
安全最優先ゆえの新技術導入に慎重な体質 関電システムズは関西電力100％出資の子会社として、関西電力向けシステム開発を専門とする機能子会社だ。2019年4月より関西電力と関電システムズの合同でDevOps推進が始まったが、当時の関電システムズと関西電力の関係は、IT部門再編に伴い役割分担が大きく見直された直後であったこともあり、西内氏が「完全なる親子関係」と振り返るほど強い上下関係だったという。 株式会社関電システムズ テクニカルラボ DevOps推進グループ テクノロジスト（プロフェッショナル）西内 慶子氏 そのため関電システムズの開発体制は決められたことを計画どおり進めていくウォーターフォール型が基本方針であり、技術面では「枯れた技術」の使用が推奨されているなど、新技術の導入にあまり積極的ではなかった。 こうした体質は以前から課題認識されており、関電システムズではDevOpsの推進前に
ふとしたときに、ぼーっと考える 会社（や評価をする人）は何をもって「このソフトウェアエンジニアはいい」って判断するのがいいんだろうなぁって。むずかしくない？入社前じゃなくて、入社した後のこと。自社ウェブサービスを開発しているソフトウェアエンジニアのこと 特に伝えたいことも答えもなくて頭の中のメモ 分かりやすいならいい その人の開発したものが、バグだらけだとか、そもそも設計ができないとか、そういうのだと分かりやすいからいい。まずは、バグを減らそうねとか、設計ができるようになっていこうね、という話 あと、やってることが周りから見えないとか、コメントとかが攻撃的で一緒に働いてる人が嫌な気持ちになるとか、まぁ、そういうのも「違うよね？」って言えるし、コンピテンシー評価で伝えていけたらよさそう ある程度のモノができている場合は、どうだろう？ もっと早く作ってほしかった！ って考えるかもしれない。確か
私の目標は、読者が午前中に本書を読み始めたら、午後には設計が上達していることだ。 本当にそのとおりだった。読んでる途中で既に自分の設計に対する考えが良い方向に変わってると感じた。とても良かった。おすすめです。 『Tidy First?』 をいただいて読んだ。昨日（2024年12月25日）発売。英語版が2023年11月28日発売だから、たった1年で日本語版が出たということだな。うれしい！はやい！ありがたい！ ソフトウェア設計に焦点を当てたシリーズの最初の1冊ということで、サブタイトルに「個人で実践する経験主義的ソフトウェア設計」とあるように、1人でできる種類のソフトウェア設計について書かれている。続刊ではチームについての話になる予定のようで、それも今から楽しみ。 2周読んだ なんとなく2周読もうと思ってそうした。 1周目は細かい部分は気にせずにざーっと1,2時間くらいで読んだ。全体的にどうい
これは Livesense Advent Calendar 2024 DAY 20 の記事です。 はじめまして、アルバイト事業部の星 id:watasihasitujidesu です。 idがwatasihasitujidesuですが、執事ではありません。エンジニアです。 今回はタイトルの通り、創業時から運用が続いていたレガシーコードから脱却に取り組んだプロジェクトについて、その背景や課題、そして具体的な対策を紹介します。 背景 状況と課題 システムの状況 エンジニアのチームメンバーの状況 当時の私の状況 レガシーコードから脱却のコツ 対象システムの解像度を上げ切る プロジェクト進捗を可視化してスケジュール管理をする 移行対象数を減らす まとめ 背景 リブセンスが運営するマッハバイトは創業時から続くサービスです。*1 このマッハバイトのシステムはもともとPHPで書かれていたシステムでしたが
事業やプロダクトの成長を目指すとき、必然的にエンジニアリングのタスクも増えてチームは拡大し、開発組織のスケーリングという新たな課題が発生します。アジャイルにおいても開発をスケールさせるフレームワークはいくつかありますが、十分な知見が得られず試行錯誤している企業も多いのではないでしょうか。 クラウド経営管理システムを開発する株式会社ログラスでも、事業の成長に伴っていくつもの課題に直面しました。同社ではスクラムを導入していましたが、チーム間やエンジニア間のコミュニケーションコストが増大したり、チームが担当する領域以外の知識に乏しくなって全体感を把握するメンバーが減少したりしていました。 こうした課題にこれまでのやり方では解決が難しいと判断した同社は、スケールする開発プロセスとしてFASTの導入に取り組んでいます。これまでもアジャイルだけでなくドメイン駆動型設計（DDD）などを積極的に取り入れて
※この記事は、2024 Speee Advent Calendar 22日目の記事です。 前日の記事はこちらになります。 tech.speee.jp はじめに 初めまして、2022年度新卒でSpeeeに入社し、現在Housii（ハウシー）という完全会員制の家探しマッチングプラットフォームの開発チームでエンジニアをしている大金と申します。 今回は、自分の実体験を元にした記事を書いてみました。 開発物を日々沢山リリースしているものの、イマイチ「事業の成果」に向き合えていないと感じるエンジニアの方々にとって、少しでも今後の動き方の参考となる記事になれば幸いです。 目次はこちら はじめに なぜか「事業成果」から遠ざかってしまう問題 「価値ある顧客体験」を軸にした成果定義へのアップデート 1. 事業の解像度の向上 2. 施策のプランニング周りの動きの改善 3. 「見るポイント」の変化 「事業成果」に
Ebisu.mobile #8 登壇資料です。 https://hey.connpass.com/event/335971/
2024年12月20日 ソフトウェアテストシンポジウム 2024 東海 #jassttokai24
TVer で Web フロントエンドエンジニアをしている永井です。 この記事は TVer アドベントカレンダー 2024 19 日目の記事です。 18 日目の記事は @k0bya4 さんによる 「Atlasを使った宣言的マイグレーションでDBスキーママイグレーションを自動化する」 でした。 19 日目の記事では、Web フロントエンドチームの内製化について紹介します。 ※ TVer の Web フロントエンドは、広告プロダクトである「TVer 広告」の配信システム・広告周辺領域の開発を行うチームと、tver.jp といったユーザー向けのプロダクトを開発するチームの 2 つあり、今回の話は後者に関するものとなります。 はじめに 現在 TVer の Web フロントエンドチームでは、tver.jp の フロントエンドを開発をしています。2024 年 12 月時点では、 3 名の正社員と 1 名
はじめに LITALICO の @katzumi です。 2020 年に LITALICO へ Join して以来、ずっとレセプト業務の開発に携わってきました。 レセプト業務は複雑なドメインゆえミスが許されず、さらに３年に一度の大きな報酬改定があり、ロジックが大幅に変わります。 その改定作業は情報公開から実装完了までの期間が約 3 ヶ月と短いです。また、年々複雑化するシステムに対応する必要があります。 その複雑な業務に立ち向かった内容を過去にも以下の内容で開発業務の記事を書いていました。 今年 2024 年は法改正の年になっており、取り組みの結果、その後どうなったのか？を振り返っていきます。 今回も壮絶だった法改正 私自身の大規模法改正の経験が今回で 2 回目となります。 チーム構成としては私ともう一名を除いて前回の 2021 年度法改正を経験したメンバーがいませんでした。前回は 3 種類
はじめに 背景：クレジットカード不正検知システムとは 3日でDesign Doc 2本、ADR 5本を執筆 3週間で開発し、本番環境にリリース LLM活用による効率化のポイント 目的・要件の整理 要件を満たす技術的オプションの洗い出し・技術調査 PoC実装 ドキュメントの執筆・技術選定 本実装 学び おわりに はじめに 新規プロダクトやプロジェクトの立ち上げにおいて、どれだけ意思決定を明確化し、設計を固めることができるかは、後々の開発効率や品質に大きな影響を与えます。一方で、最初が肝心だからといって調査や設計に何か月も費やす余裕は、多くの企業にはありません。できる限り早く設計を確立し、実装を開始して価値を生み出すことが求められます。 LayerXのバクラク事業では、法人向けのクレジットカード「バクラクビジネスカード」を提供しています。サービス開始時から不正利用を検知する仕組みを導入していま
ソフトウェア開発における「借入」との上手な付き合い方こんにちは！ニーリーアドベントカレンダー2024 18日目は ARCHチームの野呂が、借入についての記事をお届けします！ ここだけの話なのですが、我が家のリビングのドアのドアノブが失われてそろそろ1ヶ月経ちます。 リビングのドアにドアノブがないと非常に不便です。 ちゃんと閉まらないのでエアコンの暖気がだだ漏れになりますし、猫が脱走して大暴れします。 皆様におかれましても、リビングのドアノブを持ち去られそうになった場合、勇気を持ってNoを言った方が良い結果を生むことが多いのではないかと思います。 相手がプロで、自分が素人であってもです。 参考になりましたら幸いです。 さて、ここからが本題なのですが、皆様はどのくらい借金をしていますか？ 適度に借金をしてきちんと返済すると、信用スコアが上昇し、次に借りられるお金の上限が緩和されがちです。 資本
こんにちは丸山@h13i32maruです。 私は20年前の高専3年ごろに、当時ハマっていたオンラインゲームのツールをHSP（Hot Soup Processorって今も開発続いててすごい！）で作って、自分のホームページに公開していました。ユーザは自分以外だと2〜3人しかいませんでしたが、すごく楽しかった記憶があります。これが私の個人開発の原体験です。それから現在に至るまで個人開発を続けています。 ここ数年で特に気に入っているのは、Jasper（GitHub用のIssue/PRリーダー）やTrickle（自分のアクティビティを書き留めるサービス）です。今は開発していませんがOSSとしてESDoc（JSのドキュメンテーションツール）というものも作っていました。最近だとMTG Playbookというマジック・ザ・ギャザリング用のオールインワンアプリを積極的に開発しています。この20年で大小合わせ
SRE NEXT 2024での登壇資料です https://sre-next.dev/2024/schedule/#jp040 System Risk Records テンプレートはこちら: https://docs.google.com/spreadsheets/d/e/2PACX-1vT2…
2019年7月3日、Qiitaが主催するイベント「開発チームのリアルな裏側、全部話しちゃいます！」が開催されました。「自分に最適のチームで、最高の仕事をしよう」というコンセプトを掲げ、エンジニアとチームをつなぐ転職サービスを提供する「Qiita Jobs」。Qiita Jobsを実際に導入する株式会社オープンロジ・株式会社プレイド・マイケル株式会社・freee株式会社の4社が集い、モデレーターに株式会社レクターの広木大地氏を迎え、開発チームの知られざる裏側を赤裸々に語ります。 技術的負債とどう向き合う？広木：では次のテーマにいきましょう。弊社の技術的負債について。デプロイパイプラインの自慢をさせてくださいってやつですね。どうでしょう？ 横路：マイクロサービスって「最初からマイクロサービスにするな」って言われるでしょ？ うちには育ち切ったモノリスがあります！ 広木：すばらしい！ 横路：ぜんぜ
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? この文章の目的 開発者とステークホルダーが「技術的負債」という言葉で正しくコミュニケーションをとれるようになることをゴールとする。技術的負債については色々な所で語られるが、実際の現場では技術的負債が管理されてない事が多いのでは無いだろうか。この場で技術的負債という言葉についての知見をまとめ、たたき台とする事で、ゴールに到達する第一歩としたい。 対象読者 開発者 責任者/見積もりに対して決定権を持つ人 技術的負債とは何か 技術的負債とは、コード・設計の状態を表す見積もりのための言葉である。継続的に開発を行う上で理想状態から離れたものを負債
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
