流石にイラッとしたので殴り書いておこう。 xtech.nikkei.com あのね、こういうのって発注側に責任があることがほとんどですよ。「要件を満たすクソコード」を生むのは発注側ですよ。早く安く＝クソコードリスク極大なんですよ。をーたーほーるで設計をちゃんと検収するとかすればよかったんじゃないですかね？あるいは、「正しい見積を出してきたベンダーに任せる」のですよ。それを判断できない？じゃあ、高いITベンダーに「食い物にされている」と思わずに依存してください（その方が絶対品質上がるので。金はかかるけど）。 あくまで筆者の経験を基にした主観的な見解だが、「作り逃げ」は「なんちゃってアジャイル」（雑に手早く構築することがアジャイル開発だと勘違いしている）なベンダーやエンジニアに目立つ。 この話も、現象として捉えると確かにそのとおりだと思うけど、これ絶対ろくなRFPを振り出してないし、コンペにな
概要 こんにちは。 KDDIアジャイル開発センターの小板橋です。 この記事は、KDDI Engineer&Designer Advent Calendar 2021の11日目の記事です。 先日(2021/12/3)、re:Invent2021でAWS Amplify Studioが発表されました。 今回は、そのAWS Amplify Studioについてまとめ、検証していこうと思います。 AWS Amplify Studio AWS Amplify Studioの機能を要約すると、フロントエンド開発者に最小限のコーディングでフロントの開発ができる Amplifyのバックエンド構成およびそれらを管理する機能を統合した開発環境 ちなみに、amplify admin uiとの違いは？？ 昨年のアップデートでamplify admin uiというものが出ています。 実は今回のAWS Amplify
初めに この記事は、私が納期をまともに守れなかったころから、 遅延しなくなり後輩の遅延を手助けするまでに 学習したことや心がけていること及び失敗談を記述します。 暇つぶしに読んでいただければ幸いです。 前提：どれぐらいできなかったか ・イケると思った機能が1週間遅延して更にバグまみれ。 ・プロトタイプ版開発に時間をかけすぎて仕様変更によって結局遅延。 ・ユーザーが欲しいと思った機能が、完成とほぼ同時に不要になってしまった。 この記事の内容は、主観と経験に基づくものが多いです。筆者はよく言っても中堅エンジニア なので、記述内容が必ず参考になるとは限りません。 勉強した事 交渉＆見積もり編 ・正確な工数見積もりは「不可能」である事を認識する。 実際に機能を作る前には、「だいたいどれくらいでできるのか」という事を絶対に確認されます。 その時に、過去の経験からn日でできるな…と考えても、それはたい
「私のプロファイル」 にも書いているとおり、ここ数年は勤務先での中長期的なIT戦略の立案と遂行に、たずさわっている。世の中は少し前からDigital Transformation、略してDXというバズワードが席巻しており、わたしのような者のところにも、戦略コンサルやらITベンダーが入れ代わり立ち代わりやってきては、DXの話をしてくれる。何事も勉強と思い、ありがたく拝聴させてもらっているが、だんだん耳にタコができたような気がしてきた。だって、皆が同じ話をするのだ。 その最大のキーワードは、経済の『サービス化』である。サービタイゼーション（Servitization）という、あまり聞き慣れない英語もついている。これまでの世の中は、せっせとモノを作っては売る、物の経済の時代であった。しかしその時代は終わりを告げ、いまやサービスを中心としたソフトなビジネス・モデルに転換すべき時である。そう、来客の
NTTデータは法人向けシステム構築に生成AI（人工知能）を本格導入する。生成AIを利用したシステム開発手法やツール群を社内で整備し、2024年度から国内外の開発部門に展開する。 NTTデータは業務システム開発に携わるエンジニアが国内と海外を合わせて約10万人在籍する。生成AIを使う開発手法を全エンジニアに習得させ、営業など関係する職種も含めて全社員19万5000人が利用できる体制を目指す。 既に実証では開発工数を7割削減できたなど大きな成果事例が出ているという。システム構築の生産性が大幅に向上すると、受注できる案件を増やせる一方で、案件の単価や顧客単価が下がりかねない矛盾も抱える。システム構築の受注金額は、必要な工数を積算して算定根拠にする「人月型」の契約が主流だからだ。NTTデータは「課題を整理して、成果報酬型など顧客と新たな契約形態も検討を進める」（担当する技術革新統括本部システム技術
アジャイル環境で必須 ビジネス要件定義書（BRD）を作成する際のポイント：どう作るか、どう活用するか アジャイルソフトウェアチームが仕事を行う際には、厳密なプロセスや厳格な監理委員会を設けるべきではない。それでも、ビジネス要件定義書は、チームの中心に据える必要がある。本稿では、そのビジネス要件定義書について考える。 ソフトウェアチームは、顧客に提供予定の具体的な製品または価値をビジネス用語を使って要約する明確かつ包括的なドキュメントを作成して、管理しなければならない。このビジネス要件定義書（BRD：Business Requirements Document）を用意すれば、顧客のニーズを満たすことが可能になる。 アジャイルソフトウェアチームは、顧客用か社内業務関係者用かを問わず、アプリケーションを作成する前に、BRDの作成方法を理解する必要がある。本稿では、BRDが果たす役割、アジャイルプ
2019年7月6日、株式会社サイバーエージェントが主催するイベント「Battle Conference U30」が開催されました。30歳以下のエンジニアによる30歳以下のエンジニアのための技術カンファレンスである本イベントには、さまざまな領域で活躍する若手が登壇。企業の枠を超えて、自身の技術・事業・キャリアに関する知見を発表しました。「インフラだってスクラムがしたい！」に登壇したのは、株式会社マネーフォワード・栗田茉緒氏。登壇資料はこちら インフラエンジニアがスクラムに挑む 栗田茉緒 氏：株式会社マネーフォワード、サービス基盤本部の栗田と申します。「インフラだってスクラムがしたい！」というタイトルで発表をさせていただきます。後ほどスライドを公開するので、そちらも合わせてご覧ください。 まず始めに、マネーフォワードは「MoneyForwordクラウド」や「MoneyForword ME」など
Agile Japanは、日本中にアジャイルの価値を浸透させ、日本の変革を促進することを目指しています。あらゆる業界や職種の方が集まり、実践者も初学者もともに建設的な意見交換ができる場です。「Agile Japan 2022」に登壇したのは、株式会社セブン銀行・スクラムマスターの小林公洋氏。LeSSにおける1on1の取り組みの工夫と結果について発表しました。 セブン銀行・スクラムマスターの小林公洋氏 小林公洋氏：それでは「LeSSではじめる1on1」を始めたいと思います。 まず簡単に、自己紹介をさせてもらえればと思います。セブン銀行の小林と申します。主な経歴としてはシステム開発をずっとやってきています。約3年ほど前にセブン銀行に転職をしています。セブン銀行は4、5年ぐらい前から内製開発に取り組んでいるのですが、内製開発を行っているグループが「プロダクト開発グループ」というところになっており
こんにちは。エンジニアリンググループ プロダクト支援チームでプロダクトマネージャーをしている中村です。 2019年5月にエムスリーに入社してから、早4年が経ちました（うち1年半の出産・育児のための休業期間を挟んでいます）。 ちなみにエムスリー入社前の経歴としては、大手メガベンチャーの事業企画からキャリアをスタートし、企画職、プロジェクトマネージャー等を経てプロダクトマネージャーを3年ほどやっていました。 私がエムスリーに入社してから半年後の2019年11月に、以下の記事を書いていました。 www.m3tech.blog 当時の記事に書いた通り、私がエムスリーへ入社を決めた理由は下記4点でした。 エムスリーは新規事業の立ち上げサイクルが速く、プロダクトマネージャーとして「製品を見つける」フェーズにチャレンジできる環境であること 尊敬できるプロダクトマネージャーだと感じたVPoE山崎の直轄チー
ステークホルダーの多いプロジェクトでもスクラムが効果を発揮するまでヤフーが取り組んできたこと─スクラムマスターとアジャイルコーチの役割とは - Agile Journey
比較的小さなチームで小回りのきくプロジェクトを進める場合には、アジャイル開発やスクラムの利点をすぐに感じられる場面も多いでしょう。しかし、より多くのステークホルダーが関わってくる大規模な開発プロジェクトとなるとどうなるでしょうか。 いくつかのチームで2010年代前半からアジャイル開発に取り組んできたヤフー株式会社の開発組織ですが、現在では新規にスクラムを導入したいプロジェクトを支援する組織があり、たくさんのステークホルダーが関わる世界的なスポーツイベントの特設メディアサイトの構築においても効果を発揮しています。 スクラムマスターとして2021年にスポーツナビの総合メディアサイト開発を推進した田原慎也さんと、その田原さんたちをアジャイルコーチとして支援した荒瀬中人さんに、複数チームをまとめたスクラムでの工夫や課題を聞きました。 後出しの追加要望や市場変化への対応が容易なスクラム 経験者が多く
エンジニアリングマネージャーの4領域はEM以外のメンバーでも濃淡はあれど意識する必要がある - stefafafan の fa は3つです
株式会社はてなでテックリードとして仕事をしている id:stefafafan です。今回は自分が個人的に考えてきたことを記事としてまとめてみます。 エンジニアリングマネージャーの4領域とは EMでなくとも4領域を意識する必要がある テックリードの場合 スクラムマスターの場合 Individual Contributor (IC) の場合 ロールを持たないソフトウェアエンジニアの場合 結局エンジニアリングマネージャーの役割とは 終わりに エンジニアリングマネージャーの4領域とは ここで私がEMの4領域と呼んでいるのは以下の4つの領域のことです。 テクノロジーマネジメント アーキテクチャやテストなど プロジェクトマネジメント 見積もりやアジャイル開発など プロダクトマネジメント ビジョンや仮説検証など ピープルマネジメント メンバーの成長やメンタリングなど これらの4つの領域は @hiroki
自分がニッチだと思っているテーマについて発表する「Qiita Engineer Festa 2023〜私しか得しないニッチな技術でLT〜」。ここで株式会社ノーススターの古谷氏が登壇。個人開発の“つらみ”を解消するアジャイル開発・スクラム開発のエッセンスについて話します。 古谷氏の自己紹介 古谷聡希氏：「個人開発のつらみを経営計画とスクラムの手法で乗り切る技術」です。よろしくお願いします。 今日のテーマはニッチな技術ですが、私は（ニッチな技術と言いつつも）どちらかというと王道技術のニッチな活かし方なのかなと思って発表します。なので、そのように念頭に置いて聞いてもらえたらうれしいです。 あらためまして、古谷と申します。中小企業診断士で、いわゆる経営コンサルの国家資格と認定スクラムマスターを持って活動しています。 会社員としては三井物産株式会社のIT医療の領域の関連会社の株式会社ノーススターでエ
遠回りこそが僕にとって最短の道 ── 納得できるソフトウェア開発がしたいなら、まず目の前のことを楽しもう - Findy Engineer Lab
▲ 2020年1月に開催された「Regional Scrum Gathering℠ Tokyo 2020」に登壇（撮影：藤村新 @aratafuji さん） こんにちは、椎葉光行（@bufferings）です。CircleCIでIC（Individual Contributor）としてシニアソフトウェアエンジニアをやってます。20代に小さな開発会社や派遣でプログラミングを覚え、30代をまるっと楽天で過ごし、2021年に41歳で転職しました。現在は大阪の自宅からフルリモートで仕事をしています。 この20年、ずっといろいろなことを学びながら過ごしてきました。その中でも特に楽天で過ごした30代は「密度の濃い10年間だったなぁ」と思います。エンジニアとして技術的な成長はもちろん、チーム作りや組織作りにも取り組み、人と一緒に仕事をすることについて考え続けた10年でもありました。 この記事では私の30
システム構築にかかるコスト・期間は20年単位で倍々に増加している。これは「2025年の崖」で示されているレガシーシステムの問題も大きいが、ウォーターフォールモデルで専門家による分業制をとっているシステム開発生産ラインのありようも看過できない。一方、アジャイル開発によるコスト削減や開発期間短縮の効果について、大規模な金融系システムでの実例はまだ少ない。さらに、昨今のマイクロサービスを実現するための設計手法も確立できてはいないと考える。 今回、筆者らチームは「ドメイン駆動設計」を活用し、システム構築コスト・期間を大幅に削減し、かつマイクロサービスに適合するシステム開発の可能性についてのPoCを実施した。
世界で評価された製品が受けた国内での逆風世界で最も革新的な電子楽器を表彰するアワード「MIDI Innovation Award」（ミディ イノベーションアワード）で、ファイナリストの3製品に選ばれた日本生まれの電子楽器「インスタコード」は、楽器に挫折した人でも弾ける画期的なユーザーインターフェイスが評判になり、ネット通販や楽器店で人気を博しています。 インスタコードを持つ開発者ゆーいち 起業したばかりのベンチャーが、構想から３年で製品を発売し、２年後には世界規模のアワードで評価されるまでに成長したものの、この成長の逆風となったのは、日本のものづくりベンチャーが、適切な支援を受けられない、構造的な問題でした。 本稿では、インスタコードの開発者が、投資家、行政、銀行などの支援を受けられず、それでもユーザーの支持を得ながらギリギリの状況で製品化を達成したストーリーをご紹介します。 たった１人で
【資料公開】スプリントレビュー Deep Dive
みなさんこんにちは。@ryuzeeです。 2023年1月11日-13日に開催のイベント「Regional Scrum Gathering Tokyo 2023」の登壇資料を公開します。 スプリントレビューは非常に重要なイベントです。 5つのイベントのなかでいちばん重要なイベントを選べと言われたら、僕はスプリントレビューを選びます。 スクラムはプロダクトを届けるためのものであり、プロダクトを成功させるにはプロダクト自体の検査と適応が必須だと思うからです。 一方で、スプリントプランニングの精度を上げようと頑張る割にスプリントレビューが雑に扱われる例が多くて懸念していました。 ということで、本セッションでは、スプリントレビューの目的や参加者、進め方、コツなどを深掘りしてみました。 みなさんの参考になれば幸いです。 忙しい方向けのまとめ スクラムチーム全員が参加しろ スクラムチームの外側のステーク
こんにちは。BASE BANK 株式会社 Dev Division にて Manager をしている東口（@hgsgtk）です。 昨年 2020 年は本ブログにて個人の足し算ではなく掛け算で成果が出せるようなチームを目指したアジャイル開発の取り組みを継続して紹介してきました。 チーム開発の潜在的課題が見つかる振り返りワーク「Mad Glad Sad(喜、怒、哀)」 少人数でのアジャイル開発への取り組み実例 （一歩目の踏みだし方） | 詳説 | July Tech Festa 2020 登壇レポート アジャイル開発におけるユーザーストーリー分割実践 〜画面リニューアルの裏側〜 これらの考え方やプラクティスは全体の一部で、開発チームとしての組織ローカルなプラクティスを『BANK DEV 白書』として整理しています。『BANK DEV 白書』では次のような内容を整理しています。 一般的なアジャイ
SOAは優れた原則に基づいており、その大半はまだ有効です。それは契約優先開発、疎結合、構成可能、ステートレスなサービスであり、自律的で再利用可能です。 ESBフレームワークは、プロトコル変換、テクノロジーコネクタ、ルーティングおよびオーケストレーションメカニズム、エラー処理、高可用性プリミティブなどの優れた機能セットを提供しました。 分散アーキテクチャの進歩 SOAとESBの主な問題は、アーキテクチャと組織の両方の観点からの集中化でした。SOAの重要な原則は、サービスとコンポーネントの再利用でした。これにより、再利用を可能にするが、緊密なアーキテクチャ上のサービスカップリングを引き起こす階層化サービスアーキテクチャが作成されました。組織的には、ESBは単一のチームによって所有されていました。それによって、ミドルウェアは、スケーラビリティの観点で、さらに重要なことに急速な進化の観点で技術的お
プレス発表 DX推進に向け、アジャイル開発版の「情報システム・モデル取引・契約書」を公開：IPA 独立行政法人 情報処理推進機構
IPA（独立行政法人情報処理推進機構、理事長：富田 達夫）は本日、アジャイル開発を外部委託で行うケースを想定したアジャイル開発版「情報システム・モデル取引・契約書」を公開しました。 URL: https://www.ipa.go.jp/ikc/reports/20200331_1.html 経済産業省が推進するデジタルトランスフォーメーション（DX）の時代では、その中核となる情報システムの開発にも、ビジネス環境の変化への俊敏な対応が求められます。そのため、技術的な実現性やビジネス成否が不確実な状況でも迅速に開発を行い、顧客の反応に基づいて素早く改善を繰り返すという、仮説検証型のアジャイル開発が有効となります。このような観点から、同省が2018年9月に公開した「DXレポート」では、DXの進展によるユーザー企業とITベンダー（ベンダー企業）の役割変化などを踏まえたモデル契約見直しの必要性が指摘
アジャイル開発におけるユーザーストーリー分割実践 〜画面リニューアルの裏側〜 - BASEプロダクトチームブログ
こんにちは。BASE BANK 株式会社 Dev Division にて、 Software Developer をしている東口（@hgsgtk）です。 TL;DR バーティカルスライスでのデリバリーを可能な限り保つユーザーストーリーの分割はどうすればいいか ユーザーストーリーが 1 回のイテレーションで収まらないような場合に分割する ３つの分割軸「データ境界に沿って分割する」・「パフォーマンス制約をストーリーにする」・「アクターのモチベーションで分割する」をもって、ユーザーストーリーを分割する ビジネス価値の内訳要素に基づいて優先順位を考える 当記事の背景 BASE BANK Dev Division での開発プロジェクトでは、アジャイル開発の考え方・取り組みを取り入れています。その導入については、「少人数でのアジャイル開発への取り組み実例 （一歩目の踏みだし方） | 詳説 | July
「引き継ぎできない！」から始まった私のスクラム - 川口恭伸の「はじめてのアジャイル」 - Agile Journey
Agile Journeyをご覧のみなさん、はじめまして。川口恭伸（@kawaguti）と申します。 私はアジャイル開発やスクラムに関する知識を提供し、モダンなソフトウェア開発の要素の研究、プロダクト開発の進め方やチームの目標設定など、さまざまな領域でのコンサルティングを手掛けています。 また、アギレルゴコンサルティング株式会社においてシニアアジャイルコーチとして活動しており、一般社団法人スクラムギャザリング東京実行委員会と一般社団法人DevOpsDays Tokyoの代表理事も務めています。さらに、コミュニティ活動としては、毎週水曜日に品川アジャイルに参加しており、RSGT、スクラムフェス、DevOpsDaysといったカンファレンスでのスタッフワークも担当しています。 このように、ほぼ公私の境なくアジャイルやスクラムを基にした活動を長く行っていますが、本稿では、私がスクラムを始めるまでの
WEBサービス開発みたいな界隈でもう5年マネージャー業をしているので、おそらく人並みにはプロジェクトマネジメントの手法に触れてきている。実際やってきたこともあれば、やってはいないが事例やテクニックとして知っていることも含む。*1 そうやって過ごしてきたが、結局プロジェクトマネジメント手法よりも絶対にどうにかする覚悟、つまり精神論の方が重要だという個人的な結論に至っている。 どんなに精緻に工数とリスクを見積もって振り返りを繰り返しても、「まあ遅れてもいいや」という空気ではプロジェクトは遅延し続ける。逆に見積もりが雑でも「どうにかする覚悟」さえあればなんとか目標とした期日に間に合う。 もちろん覚悟と精神論でやっていると残業が常態化して炎上と言って差し支えない状態になるのだが、覚悟がなくて遅延したプロジェクトも最終的に炎上としか言いようのない状態になるので、同じ炎上なら期日に間に合っている方がマ
アジャイルをスケールさせる手法に正解はない 自社のモデルを探す事例と課題 平鍋健児さんに聞く - Agile Journey
仕様書の通りのITシステムをカッチリと時間をかけて作っても、顧客に「依頼したものと違う」と言われてしまう。ソフトウェアエンジニアの「いいものを作りたい」という気持ちがビジネスに生かされていない。そう感じていた平鍋健児さんは、ピラミッドのように大きな建築物を数十年かけて作るやり方ではなく、生鮮食品のように鮮度を大切にしたアジャイルの開発手法に出会い、この20年を実践と普及に取り組んできました。 近年はビジネスの立場からも語られる「アジャイル」ですが、このインタビューではアジャイルを導入する企業がステージや事業規模に応じてどのような課題に直面するのか？ とくに、小さなスタートアップ企業がアジャイルネイティブから大きくなったメガベンチャーだけでなく、旧来の開発手法を続けてきた既存の企業が、自分たちにフィットしたアジャイルを見つけるときに参照できるいくつかの事例とあわせて紹介します。 アジャイルが
初中級プロマネはIPAデータ白書の統計情報を見積り、生産性、品質の観点で活用せよ - プログラマの思索
初中級プロマネがIPAデータ白書の統計情報をどんな観点で活用できるか、説明した利用事例がとても良かった。 理解できた内容をラフなメモ。 【参考】 初中級プロマネのための 現場で活かせ！統計情報１ 初中級プロマネのための 現場で活かせ！統計情報２ 「ソフトウェア開発分析データ集2020」の発行：IPA 独立行政法人 情報処理推進機構 「ソフトウェア開発データ白書」のダウンロード：IPA 独立行政法人 情報処理推進機構 初中級プロマネのための現場で活かせ！統計情報 2019年4月19日| CITP Community CITPアニュアルレポート2018を公開しました | CITP Community 【0】「ソフトウェア開発分析データ集2020」をIPAデータ白書と呼ぶことにする。 【1】IPAのソフトウェア開発データ白書を使いたい動機は2つある。 1つ目は、プロマネとしてシステムの企画書や
「DevOps」とは？〜超基本から実践のポイントを解説〜|インシデント管理プラットフォーム│PagerDuty
変化の激しい市場に対応するための開発手法として、アジャイル開発を導入する企業が増えるとともに、「DevOps」への注目が高まっています。しかし一方で「DevOpsという言葉は聞いたことはあるけれど、実際にはよくわからない」という方もいらっしゃるのではないでしょうか。DevOpsは「開発担当者と運用担当者が密に連携することで、柔軟でスピーディーな開発を実現する」というソフトウェア開発手法の一つです。DevOpsは単なるトレンドではなく、現代のソフトウェア開発において非常に重要な考え方でもあります。本記事では、DevOpsを一から理解したいという方にもわかるように、DevOps誕生の歴史を簡単に紐解きながら、DevOpsの考え方をご紹介します。また、アジャイル開発との違いやDevOps導入のメリット、実践のポイントなどをDevOpsを実践する3社の事例を交えて解説します。 「DevOps」とは
デジタル庁の求人要件がTwitterで話題になっている。政府職員が使う基盤サービスの開発エンジニアを募集するもので、必須スキルとして「Webアプリの開発経験5年以上」や「C#によるWebバックエンドアプリケーション開発経験3年以上」「TypeScript、React、Vue、GitHubなどを用いた開発経験2年以上」など10項目を記載している。 業務内容は「公的機関で使用するID管理基盤の設計・開発」「連携サービスとの相互運用・相互接続、プロビジョニングを行うサービスの設計・開発」などの他、各設計の最適化や品質向上のための分析、改善業務など。必須スキルは下記10項目。 Webアプリケーション開発経験5年以上 TypeScript、React、Vue、GitHub等を用いた開発経験2年以上 DevOpsの設計・開発、アジャイル開発経験2年以上 C#によるWebバックエンドアプリケーション（M
アジャイル開発の契約は「準委任」が適切、契約前にユーザーとベンダの共通理解が大事。IPAが「モデル契約書」やチェックリストなど公開。
情報処理推進機構（IPA）は、ユーザー企業が開発ベンダにアジャイル開発手法を用いたシステム開発を発注する際の、契約書の見本などを含む「「アジャイル開発版『情報システム・モデル取引・契約書』（本版）」を公開しました。 本作はスクラムを想定したアジャイル開発を外部委託する際の、契約条項とその解説、および補足資料で構成されたもの。 IPAは本作を作成するにあたり、ユーザー企業とベンダ企業が緊密に協働しながら適切に開発を進めることができるモデル契約となるように、ユーザー企業、ベンダ企業、業界団体、法律専門家の参画を得て検討を重ねたとしています。 契約前チェックリストも 本作の作成に関わったIPAの「DX対応モデル契約見直し検討ワーキンググループは」、ユーザー企業とベンダが契約する前に、以下の2つのことを理解しておくことが必要だと説明します。 ユーザ企業及びベンダ企業が、開発に着手する前にアジャイル
はじめにこんにちは！つむです🐈 8月より社内で実施するchatGPTをフル活用したUI勉強会を実施しています📚 開催までの背景や内容決定までのプロセス、プログラムをご紹介します🚩 使用するペルソナ・ユーザーストーリー・情報アーキテクチャ図を生成するプロンプトも公開しますのでぜひご覧ください✨ 自己紹介2022年KDDIにUXデザインコースで新卒入社（KDDIアジャイル開発センターに兼務出向中） auショップ向けDX施策やワーケーション施設検索サービス「タビトシゴト」などでUIUXを担当 背景UI業務多いのにUIデザイナーが少ないKAGデザイナーは基本的に上流を主戦場に置くUXデザイナーやサービスデザイナーとして業務をしている方が多いです。 しかし私は学生の頃からUIが得意たっだため最初はUIデザイナーからスタートし、徐々に上流へ足を広げる方針にしていただきました🙌 配属直後はUIデ
【資料公開】プロダクトオーナーアンチパターン
みなさんこんにちは。@ryuzeeです。 技術顧問先からの依頼でプロダクトオーナーのアンチパターンについて話をしたので、そのときの資料を公開します。 今回紹介するのは以下の6つのアンチパターンです。アンチパターンに陥っている可能性を示す兆候もあわせて示しています。 顧客やユーザーの軽視 兆候 社内のミーティングでスケジュールが埋まっている 機能の必要性の根拠はユーザーからのフィードバックではなく仮説（というか妄想）にもとづいているものが多い ユーザーがプロダクトを触っているところを見たことがほとんどない 不十分なステークホルダーマネジメント 兆候 ステークホルダーをスプリントレビューに招待していない ステークホルダーと個別にコミュニケーションしていない ステークホルダーに何か言われるとすぐに対応している 「◯◯さんの指示なのでやらないといけない」のような口癖 不在がちなプロダクトオーナー
※この投稿は米国時間 2019 年 10 月 4 日に Google Cloud blog に投稿されたものの抄訳です。 運用チームにエンジニアを絶えず増員しても、お客様の拡大には対処しきれません。Google のサイト信頼性エンジニアリング（SRE）の原則を適用すれば、運用上の問題にソフトウェア エンジニアリングによる解決手法を取り入れることで、うまく対処できます。本稿では、従来のネットワーク エンジニアリングの通例にとらわれず、SRE に転換することで、Google がグローバル ネットワーク運用チームを変革した方法をご紹介します。Google の本番環境ネットワーキング チームがこの問題にどのように取り組んだのかをお読みいただき、ご自分の組織に SRE の原則をどのように取り入れることができるのかを検討してみてください。 スケーリングの限界2011 年、Google の本番環境ネット
最近にわかに話題のLLMツール「Dify」を僕も使ってみた。 いいところと「?」となったところがあったので纏めておく Difyとは、GUIでワークフローを組むことができるLLM-OPSツールだ。 ComfyUIのようにワークフローが組めたり、GPTsのように自分専用のアシスタントを作れたりできる。 特に、OpenAIのGPTシリーズとAnthropicのClaude-3、そしてCohereのCommand-R+なんかを組み合わせて色々できるところは良いところだと思う。また、ローカルLLMにも対応しているので、企業内でのチャットボットを作るんだったらGPTsよりこっちの方がいいだろう。 元々色々なテンプレートが用意されているが、テンプレだけ使うとGPTsっぽいものを作れる(それだってすごいことだが)。テンプレを改造するだけでも欲しいものが作れる人はいるし、ここはノーコード環境と言える テンプ
「アジャイルテストの4象限」はアジャイル開発を補完するソフトウェア開発手法である - mtx2s’s blog
従来のプロジェクトにおける「テスト」は、リリースや納品前の最終工程として行われるものだ。多くのケースでそれは、前工程までの遅れと、それでも固定されたままのリリース日に挟まれ、予定された期間を食いつぶされた中で実施される。その上、時間に追われる中で実装されたソフトウェアは、動作確認も十分にされない状態でテストフェーズをむかえることになる。こうして品質の保証は、テスターに丸投げにされるというのが実態ではないだろうか。もちろんここでテスターに丸投げされているのは外部品質、特に機能面での品質の保証のみだ。非機能面での品質の保証は手薄になり、内部品質は顧みられることはない。 これは、ウォーターフォール開発を採用するプロジェクトで私が頻繁に経験した失敗パターンであるが、アジャイル開発でも遭遇する。その理由は、そのままのテストモデルがアジャイル開発の中でも用いられるために、同様の失敗パターンに陥りやすく
追記(2019/11/2) 今回の記事で深く扱えなかったリファクタリングに関する記事を書きました。 「汚いコード、綺麗なコードって何？」リファクタリングを考えてみる 追記(2019/08/16) 今回の記事では深く扱えなかったテスト駆動開発についての記事を書きました。参考にしてください。 僕たちがテスト駆動開発をする理由 リファクタリングに関する記事も書く予定です。 背景 フルリモートエンジニアはとてもいいものです。どこでも仕事ができるので旅行をしながら、海外にいながら、温泉に入りながら、どこででも好きなタイミングで仕事をすることができます。 この素晴らしい自由を支えるのは顧客との信頼です。 フルリモートの仕事は、仕事の過程を見ることができないため完全な成果物主義であり、この仕事をこの人に任せればこんな成果物が返ってくるだろうという期待と信頼関係によって成り立っています。 顧客に価値を届け
一括請負契約はソフトウェア開発にやっぱり向いていない、と改めて感じた。 理由は2つある。 【参考】 ERPの落とし穴part4～システム移行という名のデスマーチ: プログラマの思索 システムのリプレース案件が最も危険な理由: プログラマの思索 請負契約がソフトウェア開発者を苦しめている: プログラマの思索 【1】1つは、発注者は外部ベンダーにリスク転嫁しているつもりでも、リスク転嫁できていない。 結局、発注者に全てリスクで跳ね返ってくる。 発注者は、要件定義でガチガチに仕様を固めて、その仕様通りにリリースできたとしても、もし本番障害があれば、瑕疵担保責任でベンダーに追求できる。 民法の請負契約では、受託側は成果物の完成責任があるからだ。 しかし、その契約スタイルはソフトウェア開発になじまない。 たとえば、発注者が要件定義や外部設計をまとめて、ベンダーに開発工程を一括請負で委託したら、それが
アジャイルを推進するチームの基本とは？ カイゼンアドバイザー・新井剛さんが教える始め方と続け方 - Agile Journey
現在ではさまざまな企業が変革に取り組むため「アジャイル」な手法に注目しています。しかし具体的に推進していくとなると、どこから手をつければよいか、またどう広げていけばよいか、導入して実践するだけでもハタと悩む場面が多いようです。 アジャイルコーチ、カイゼンファシリテーターとしてさまざまな企業のカイゼン・変革を支援してきた『カイゼン・ジャーニー』著者の新井剛さんに、そもそもアジャイルな手法がなぜ注目されていて、何に対して取り組んでいくのか、どのようにチームに取り入れ、組織全体に浸透させていくことができるのかを聞きました。 プロダクト・チーム・プロセスそれぞれをカイゼンする チームで「もやもや」を整理することより始めよ ノウハウや情報を横展開しやすくする取り組みを進める アジャイル実践時に陥りがちな3つの課題 受託・ウォーターフォール・日本的な計画への対応 まとめ：アジャイルを継続していくために
さくらインターネットで活躍中の id:y_uukiを訪問 | はてな卒業生訪問企画 [#9] - Hatena Developer Blog
こんにちは、エンジニアリングマネージャーの id:onk です。 Hatena Developer Blogの連載企画「卒業生訪問インタビュー」では、創業からはてなの開発に関わってきた取締役の id:onishi、CTOの id:motemen、エンジニアリングマネージャーの id:onkが、いま会いたい元はてなスタッフを訪問してお話を伺っていきます。 id:onkが担当する第9回のゲストは、さくらインターネット株式会社の組織内研究所であるさくらインターネット研究所の上級研究員で、SRE （Site Reliability Engineering）の研究者としても活躍する id:y_uuki さんこと、坪内佑樹さんです。 2013年にはてなに新卒でWebオペレーションエンジニアとして入社後、サーバー監視サービス「Mackerel」をはじめとするサービス開発やはてなのインフラ開発・運用にSR
![さくらインターネットで活躍中の id:y_uukiを訪問 | はてな卒業生訪問企画 [#9] - Hatena Developer Blog](https://cdn-ak-scissors.b.st-hatena.com/image/square/5b5961cfe7e9736ef0e88bc0290b1599481d2626/height=288;version=1;width=512/https%3A%2F%2Fcdn-ak.f.st-hatena.com%2Fimages%2Ffotolife%2Fh%2Fhatenatech%2F20240319%2F20240319125826.jpg)
アジャイル・DevOpsからDeveloper Productivityへ ~食べログのDeveloper Productivityチームが目指す姿~ - Test Automation
はじめに こちらは食べログAdvent Calendar 2021の23日目の記事です[1]。近年、IT業界では働き方改革によるリモートワークなどの浸透や、アジャイル開発やDevOpsなどのソフトウェア開発プラクティスの普及を受け、Developer Productivity(開発生産性)が鍵になってきています[2][3]。組織のDeveloper Productivity（開発生産性）が向上すると、ソフトウェアのデリバリーだけでなく、ビジネスパフォーマンスや社員のモチベーションが向上することが知られています。 私の所属する株式会社カカクコムの食べログシステム本部でも2021年10月に「Developer Productivityチーム」という「 開発サイクルのフィードバックを素早く、リッチにすることで最高の開発・テスト体験を実現する 」をミッションとして持つチームが爆誕しました[4]！
はじめに こんにちは。私はN予備校のバックエンド開発に携わっています。 N予備校バックエンドでは2021年度に1名の新卒エンジニアが配属となりました。 ドワンゴの新卒エンジニアはエンジニア研修を受けたあと、配属された部署で個別研修や実際の業務を通じてOJTを受けます。 本記事では、メンターとして2021年度新卒エンジニアが入社してから1年のあいだに行ったフォローアップについてまとめます。 メンティーの len さんが執筆した記事は こちら になります。 新卒エンジニア研修の内容については、別の方がまとめた記事を公開しています。 2021年度 エンジニア新入社員研修のご紹介 ドワンゴ21新卒がフルリモートでの入社から機能をリリースするまで メンティー入社前 メンティーが入社するまでは、パーソナリティの把握に務めました。 パーソナリティを把握しておくことで、苦手な部分をメンターが迅速にサポート
みなさんこんにちは。@ryuzeeです。今日は小ネタです。 3分くらいでスクラムをざっくり分かってもらうための説明を以前作ったのですが、意外と役に立っているのでブログで公開しておきます。 この記述については、CC BY-SA 4.0ライセンスとします。 クレジット表記（@ryuzee / Ryutaro Yoshiba）のもとで共有や派生物を作って構いません（その場合は元のライセンスを継承します）。 製品の目標や方向性、成果に責任を持つ人を1人決めます（＝プロダクトオーナー）製品の目標や実現したいことを一覧にして、常に最新の状態にしておきます（＝プロダクトバックログ）製品を作るのに必要な作業は色々な能力を持った開発者たちに任せます（デベロッパー）頻繁に動くものを見たほうが安心なので、固定の短い期間に区切って繰り返します（＝スプリント）短い期間をうまく過ごして成果を出すには計画が必要です（＝
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
システムの作り逃げはなぜ起こるのか - novtanの日常
AWS Amplify Studioが変えるフロントエンド開発の未来とは
納期守れない系エンジニアが遅延無しでちょっと頼りにされるまでに学習したこと - Qiita
サービス経済から、ふたたび実物経済の時代へ | タイム・コンサルタントの日誌から
NTTデータが生成AI使うシステム開発手法を全技術者に展開、人月型契約が見直しに
アジャイル環境で必須 ビジネス要件定義書（BRD）を作成する際のポイント
インフラエンジニアがスクラムをやって学んだこと
「目標を共有するチーム」より強いのは「悩みを共有するチーム」 スクラムマスターが実践して気づいた、1on1“7つのコツ”
超一流のプロダクトマネージャーへの道 - エムスリーテックブログ
個人開発が続かない理由は「時間」「戦略」「気力」「孤独」 4つの“つらみ”を解消するアジャイル開発・スクラム開発のエッセンス
ドメイン駆動設計によるシステム開発 | 知的資産創造 | 野村総合研究所(NRI)
世界のベスト3に選ばれた製品が、行政や銀行の支援を受けられなかった理由とは
振り返りで積み上げた開発プラクティス（2020年総まとめ） - BASEプロダクトチームブログ
サーバーレス時代のKubernetesワークロード：アーキテクチャ、プラットフォーム、トレンド
プロジェクトマネジメント手法 vs 絶対にどうにかする覚悟 - ミネムラ珈琲ブログ
デジタル庁がエンジニアに求める“必須スキル”は妥当？ 求人要件に賛否 同庁に経緯を聞いた
ChatGPTをフル活用したUI勉強会！プロンプトも大公開｜つむら
ごく普通のエンジニアリング運用チームを強力な SRE チームに変える | Google Cloud 公式ブログ
噂のノーコードAIシステム開発環境Difyを使ってツールを作ってみた。使った感想｜shi3z
信頼されるフルリモートエンジニアになるためのアジャイル開発 - Qiita
一括請負契約はソフトウェア開発にやっぱり向いていない - プログラマの思索
チームの機能不全を起こす4つの “毒”を発生させないための感情の保ち方、心理的安全性を確保したチーム作りのために考えるべきこと【CEDEC2021】 | GameBusiness.jp
新卒エンジニアのメンターとして1年間取り組んだこと - ドワンゴ教育サービス開発者ブログ
3分でざっくりわかるスクラム（スクラム用語を使わないスクラムの説明）