DXを妨げる要因と実現へのアプローチ by @yuzutas0 / 20211022
株式会社商船三井様の社内セミナーで用いた資料です。 関係者の許諾を得て公開しています。 関連記事「DXに関する私的な殴り書き」 https://yuzutas0.hatenablog.com/entry/2020/06/02/110000 関連スライド「民間企業におけるDXの事例と課題」…
株式会社商船三井様の社内セミナーで用いた資料です。 関係者の許諾を得て公開しています。 関連記事「DXに関する私的な殴り書き」 https://yuzutas0.hatenablog.com/entry/2020/06/02/110000 関連スライド「民間企業におけるDXの事例と課題」…
品質を犠牲にすることでソフトウェア開発のスピードは上がるのか？ 和田卓人氏による 「質とスピード」（前編）。デブサミ2020
品質を犠牲にすることでソフトウェア開発のスピードは上がるのか？ 和田卓人氏による 「質とスピード」（前編）。デブサミ2020 ソフトウェア開発のプロジェクトにおいて、リリースに間に合わせるために開発スピードを優先させ、ひとまず質には目をつぶろう、という判断がしばしば行われることがあります。 はたしてその判断は正しいのでしょうか。2020年2月13日と14日の2日間、都内で行われたイベント「Developers Summit 2020」（デブサミ2020）」の和田卓人氏のセッション「質とスピード」は、これを深く考察したものでした。 この記事では、会場に立ち見がでるほど大人気だった本セッションの内容をダイジェストで紹介します。本記事は前編と後編に分かれています。いまお読みの記事は前編です。
ベイジは2010年の創業以来、ウェブ制作事業を中心に事業を展開してきました。この事業では、サービスの質を統一するために2014年頃からワークフローの整備に取り組んできました。 一方ウェブアプリデザイン事業については、事業拡大したのがここ数年で、まだワークフローが整備されておらず、各人の裁量に委ねた進め方になっていました。そこで今後の事業拡大とメンバー増員を想定し作成したのが、業務システムやSaaSのUIデザインに特化した「ベイジの業務システムUIデザインワークフロー」です。 基本的な進め方は国際規格（ISO 9241-210※）の人間中心設計プロセスに基づいて組み立てていますが、細かいタスクの順序や内容は、今までベイジで培ってきたノウハウをふんだんに盛り込み、組み換えています。 そして、様々なプロジェクトでこのワークフローを実用しながら、今もアップデートを続けています。 また今回のワークフ
プログラミング上達したいんだったら、四の五の言わずに、 ・クリーンアーキテクチャ ・レガシーコード改善ガイド ・アジャイル・サムライ ・リファクタリング 系のどれか を、全部最低5回読み返して欲しい。それでプログラマとしては圧倒的に成長できるんだから、マジで読んで — Next.js + Hasura 最速プロトタイピング本 @技術書典9 出す予定 (@erukiti) July 27, 2020 先日、こういうツイートをしたらバズってしまいまして。これらの本を理解できるまで読みこめばプログラマとして成長できますよーというもので、 ・ クリーンアーキテクチャ ・ レガシーコード改善ガイド ・ アジャイルサムライ ・ リファクタリング 系のどれか（例えばリファクタリング第二版） の4冊を挙げました。いろいろな人の感想を読んで、補足が必要そうだなと思ったので記事として書きなおしています。 この
IPA から アジャイル開発版「情報システム・モデル取引・契約書」が公開された。 【プレス発表】 DX推進に向け、アジャイル開発版の「情報システム・モデル取引・契約書」を公開 https://www.ipa.go.jp/about/press/20200331.html 【成果物公開ページ】 https://www.ipa.go.jp/ikc/reports/20200331_1.html 私はこの1年間、IPA の「社会実装推進委員会 モデル取引・契約書見直し検討部会 DX対応モデル契約見直し検討WG」の委員としてこのモデル契約書の策定に関わってきた。 モデル契約策定にあたって、私が特に実現できてよかったと思うことを書いていきたい。 準委任契約を前提とすることができた2012年にIPAから出された「非ウォーターフォール型開発に適したモデル契約書」（当時、IPAではアジャイルと言わずに非ウ
プリウス開発に見るアジャイル開発要素と今時の進め方：続編 / The Agile Development Elements and Current Approach as Seen in Prius Development: Sequel
弊社の伝説の開発のひとつ、スクラムの源流でもある、初代プリウスについて、当時の開発者たちが語る熱く、時には洩れる本音のトークを紹介します。また日本を代表するアジャイルコーチの皆さんと、温故知新の心構えでこれらを分析しました。開発者たちのトークに、いくつかの共通ワードが存在し、それがスクラムの源流と繋がっ…
超巨大クラウドのシステム開発現場を行動観察。ガチ三流プログラマが米国システム開発の現状をリークする話（1） Regional Scrum Gathering Tokyo 2022
超巨大クラウドのシステム開発現場を行動観察。ガチ三流プログラマが米国システム開発の現状をリークする話（1） Regional Scrum Gathering Tokyo 2022 代表的なアジャイル開発手法であるスクラムをテーマにしたイベント「Regional Scrum Gathering Tokyo 2022」が、1月5日から7日までの3日間、都内およびオンラインのハイブリッドで開催されました。 そのクロージングセッションとして行われたのが、現在シアトル在住でMicrosoft Azureの開発を担当している牛尾剛氏による「アメリカの超巨大クラウドの中の人に転生したガチ三流プログラマが米国システム開発の現実をリークする話」です。 本記事ではほぼ90分におよぶセッションの内容を、前編、後編（1）、後編（2）の3本に分けて紹介します（この記事は後編（1）です）。 前編では、子供の頃からプロ
道の真ん中をきれいにするプロジェクトマネジメント～イケてるチームになるための10原則～ - Qiita
はじめに 私が好きな江戸の小話的なものに、こういったものがあります。 江戸下町では、道向かいのそれぞれが軒先を掃くときに、道の真ん中よりもちょっと向こうまで掃くのがならわしだったそうです。両側の人がそれぞれ真ん中よりも向こうまで掃くので、道の真ん中が一番きれいになる、というお話です。 近年こうした「江戸しぐさ」のようなお話は、真偽のほどが定かではないとして、流布することに批判もあるようです。実際この話も正直事実かどうかは全くわかりません。 ただお互い完璧ではない他人同士が肩寄せ合って共に生きる知恵といいますか、プロジェクトへの参画姿勢について良い示唆を与えてくれる話だと思い、その前提で使っています。 実際私が関わる案件のキックオフでもお客様や関係者によくこの話をするのですが、「キックオフでの『道の真ん中の話』、他の現場でも最近してるんですよ」とお客様やパートナー様から言っていただけたことが
Agile Manifestoには以下のように書いてあります。 動作するソフトウエアは包括的なドキュメントにまさる ともするとドキュメント軽視と取られかねない宣言です。この宣言を誤って解釈してドキュメントはいらないとなる場合もあるかもしれませんが筆者はそれは間違いだと思っています。この宣言では包括的なドキュメントよ
クックパッドを退職することになりました。 created at: 2023-06-05 00:00:00 +0000 概要 クックパッドという会社で2018年から仕事をしていましたが、会社で「人員削減の合理化を実施することになり」僕はその対象となりました。 https://pdf.irpocket.com/C2193/CaoZ/qmSw/IQUI.pdf 時系列としては、16時からの全社ミーティングにて発表されて、17時頃にメールが届きました。その後どうするのか？みたいなことを考えつつも仕事にならないので18時前ぐらい退勤をしたときのツイートがこれ 一度しかない人生で会社をクビ（会社都合）になることってあるんだなぁ。宝くじみたい。仕事探してます。 — あそなす (@asonas) June 5, 2023 自分の人生でまさかこうなるとは思ってなくてかなり動揺しつつの帰路でした。最近の通勤時
自走できるエンジニアとは
ソフトウェアエンジニアリング界隈の言葉はとても曖昧な言葉に満ち溢れています。「自走」という言葉もそうです。でも、そういう曖昧な言葉の方が使い勝手が良いため、たとえば、ツイッターランドにはそういう曖昧な言葉がバズりまくったり、日々流れてきたりします。そうじゃなくても、「うちの職場のエンジニアには自走力が求められるんだよね」とか「転職するためには自走できる力が大切だ」みたいな言い方、度々聞いたり、むしろ話したりしていませんか？ この記事では「自走できるエンジニア」について自分なりの考えをまとめてみたいと思います。もちろんこれはあまたある解釈の中でも、僕が解釈したものに過ぎません。そういう意味ではさらに「自走」という単語を持ち出して世に混乱を投げつけるだけかもしれません。僕のただのポジショントークかもしれません。 それでよければ、「自分は自走できているのだろうか？」「自分は、うまく部下や同僚を自
【図解】コレ１枚でわかるゼロ・トラスト・ネットワーク・セキュリティ：ITソリューション塾：オルタナティブ・ブログ
「いつでも、どこでも働ける」環境を整えることは、いまや働き方改革の要件となっています。そうなると、社外に持ち出したデバイスで、社内システムやクラウドを活用して仕事をするのは当たり前となり、ネットワークにおける社内と社外の境界は意味を持たなくなります。また、ウイルスに感染したパソコンから社内ネットワークを介して感染を広げ被害をもたらす事故や、内部の悪意あるユーザーが機密情報を漏洩してしまうといった事件も後を絶ちません。 「社内は"善"、社外は"悪"」という前提に立ち、ファイヤーウォールで「社内外の境界を守る」従来の「境界防衛セキュリティ」は、もはや役に立たなくなってしまいました。 また、クラウドの利用拡大により、インターネットを介した外部へのアクセスは益々増大します。これらアクセスの全てを、ファイヤーウォールで守ろうとすれば、処理能力が追いつかずスループットの低下は避けられません。高速・大容
VTeacher所属のSatomiです。 ※ 本家Miroさんからコメントをいただいたので掲載します！ ミロジャパン高山です。本記事ではMiroについてご紹介頂き誠にありがとうございます。大変参考になります。もし本記事の趣旨にあっていればですが、以下の２つのテンプレートを日本語対応をしましたので、よろしければ、リンクを付与頂けますと嬉しいです。 スクラムボード：https://miro.com/ja/online-scrum-agile-tool/ マインドマップ：https://miro.com/ja/mind-map/ 或る日突然、「100万円のプロモーション予算がついたから急いで作って」と頼まれました。 ※ちなみにプロモーション予算（100万円）に人件費は含まれないそうです。 そして、偉い人から下の画像が送られてきました。 （「4月1日に夢を語る」という PR TIMES の企画だそ
SIベンダーを中抜きすればDXできるのか？そんなに甘い話は転がっていない｜楠 正憲（Japan Digital Design CTO）
日本はユーザー組織よりもベンダーにIT人材が集中していることが、DXを阻害しているといわれる。すぐにオンプレのサーバーを売ろうとする、クラウドで頼むといってもIaaSで持ってくる、ちょっと目新しい技術を指定したら見積もりが跳ね上がる。そういったSIベンダーに対するフラストレーションが、ひょっとして内製に切り替えれば、もっと迅速かつ低コストに新技術を導入できるのではないか？という期待に繋がっているように見える。 もしも夢が叶うならば、決められた予算、決められた要員で、生産性が高い最新の技術を習得しながら、環境変化を受け入れつつ、予定通りプロジェクトを完遂できるに越したことはない。しかしながら世の中にはトレードオフがあって、決められた予算、決められた要員、決められた期日通りにプロジェクトを仕上げたいのであれば、実績あるチームが、枯れた技術を使って、余裕あるスケジュールで、要件を固める必要がある
ドメイン駆動設計の正体
はじめに "ドメイン駆動設計は当たり前のことを言っているだけ" "ドメイン駆動設計はただのオブジェクト指向プログラミング" "ドメイン駆動設計はより良いアーキテクチャだ" "軽量DDDはアンチパターンだ" このようなドメイン駆動設計に関する言及を聞いたことがあるでしょうか？ ドメイン駆動設計に言及する記事や書籍は多くありますが、それぞれ着目する側面が異なったり色々なコンテキストから言及されています。 おそらくそれが原因でドメイン駆動設計が何であるかをぼやけさせ、正体のわかりにくい概念になっているように思えます。 そこで今回は色々な観点から整理し、ドメイン駆動設計とは何であるのか、その正体を考えていきます。 ドメイン駆動設計の基本的概念について ドメイン駆動設計はEric Evansが出版した「Domain-Driven Design」という書籍がルーツになっています。 ドメイン駆動設計を一
若手から見たリモートワーク時代のチームビルディング | BLOG - DeNA Engineering
2020 年 4 月にコロナの影響による緊急事態宣言が発令されて久しい今日この頃ですが、多くの会社でリモートワークが余儀なくされ働き方が大きく変わりました。 DeNA がリモートワーク可能な体制へと迅速に切り替えていく中で、私自身リモートワークによる業務が9割以上を占めました。私や私の所属するチームだけでなく日本中でも働くことに対する考え方が大きく変わるタイミングだったのではないでしょうか。（DeNAでは緊急事態宣言が発令される前には全社的にリモートワークがすでに可能なレベルにまで整備され、とてもスピーディーにリモートワークへと移行できました。制度や勤務体制など様々な整備をしてくださったことにとても感謝しています。） その中で、私たちがチームのコミュニケーションや課題を改善するためにどう工夫したのかをお伝えすることで読んでくださる方のチームのチームビルディングの一助にして欲しいと願っていま
2023年1月11日より開催された「Regional Scrum Gathering Tokyo 2023」の登壇資料です。 https://2023.scrumgatheringtokyo.org/index.html ----- Visionalのエンジニアリングに関する最新情報はTwitte…
この記事に関連する話題: プロダクト開発者に求められる、これからの「倫理」の話をしよう。 プロダクトマネージャー (PM) としてのこれまでの私的な経験を踏まえて、『プロダクトマネジメントのすべて 事業戦略・IT開発・UXデザイン・マーケティングからチーム・組織運営まで』を読んで思ったことをつらつらと。 （8/12 追記）冒頭で示しているように、本記事ではPM＝プロダクトマネージャーとして表記しています。後述の通りPMとプロジェクトマネージャーは異なるものであり、後者に対して略記は用いていません。 プロダクトマネージャーは本当に“魅力的な職業”か “完璧な世界”など存在しない 良かった点 「PMはミニCEOである」という言説や「PMとプロジェクトマネージャーの違いは？」というよくある質問に対する補足 「プロダクトの成功」を定義するところから始めることの重要性 PMの武器は信頼、情熱、共感、
エンジニアとして30代までにやってて良かった・やれば良かった事を自分のキャリアから振り返ってみた. - Lean Baseball
最初に言っておきます. このエントリーは「いい本を読んだついでに自分のキャリアを振り返ってオススメを残す」という長文ブログです. 適当に読み流してもいいですし, 心の琴線に触れる事があれば最後までお付き合い頂けると幸いです. さて, 4月の末と言えば, GWが近づいてくると共に色々考えることがあります. 例えば社会人23年目の私は今年, GWの予定（決まっていない場合に限る） 「こどもの日」にしてあげられること キャリアの振り返りと数年先のキャリアプラン検討 この3つについて真剣に考えています. 今年でいうとGW予定（1.）は90%程度計画済み, こどもの日（2.）は甥っ子に渡すお小遣いを検討...までは決まってるのですが, 最後の（3.）はというと, GW明けって転職とか将来キャリアを考える機会になりがちじゃん?そういえば自分のキャリア(ry ...という感じで, GWは（本人が意識する
私は世界規模のクラウドプラットフォームの開発者で、現在はシアトル付近に住んでいる。 先日書いた自分のポストに対する反応で面白い意見があってそれを読んでそらそう思うやろなぁと思った。ただ、私も別に嘘を言っているわけではないですし、これでビジネスも回っている。面白そうなので、その辺も調べてシェアすることにしてみました。 ウォーターフォールからアジャイルって開発側の話はいいのだが、それだと管理とか経営とか非エンジニアの理解を得られないので、納得できるところをちゃんと言語化してほしいんだよな。アジャイルの人の「見積もりがない」って言葉を使われるのが一番苦手、ストーリーポイントの設計は「計画と見積もり… — えふしん (@fshin2000) August 1, 2024 自分のチームの開発プロセス的なものこちらの方に自分のチームが現在やっている開発プロセスは書いてある。アジャイルとか、DevOps
UMLとかAWS構成図とかを描くツール
UMLとか構成図とかの図を描くの何のツールを使えばいいか迷いませんか？私は迷います。 ですので、最近使っているツールを紹介します。 世の中にツールがイロイロあるのは理解した上で、大量に紹介するとやっぱり迷うので、似たようなツールや個人的に使わないツールはバッサリ省いています。 パワポで描く まずはPowerPointです。 エンジニアや技術系の方は「パワポで図を描くのはちょっと、、、」と思われるかも知れませんが、状況によってありだと思っています。 パワポのメリット パワポは、ビジネスユーザーならほぼ誰でも使える システムを作る時に、お客さん側も含めた関わるメンバー全員がITに詳しいとは限りません。しかしそういう人にもシステムに対する理解は最低限していただく必要があります。システム構成図とか特に興味がない人に説明するときに「新しいツールをいれてください」というのはハードルが高いです。 パワポ
この記事は？ それぞれが専門にしている領域に関わらず、Webエンジニアリングの基礎知識として知っておきたいと思う事を対話形式でまとめていく。知識はインプットだけではなく、技術面接や現場では、専門用語の正しい理解をもとにした使用が必要なので、専門がなんであれ理解できるようなシンプルな回答を目指したものになっています。解答の正しさはこれまでの実務と各分野の専門書をベースに確認してはいますが、著者は各技術の全領域の専門家ではなく100%の正しさを保証して提供しているものではないので、そこはご認識いただき、出てきたキーワードの理解が怪しい場合各自でも調べ直すくらいの温度感を期待しています。なお、本記事で書いている私の回答が間違っている箇所があったりした場合、気軽にコメント欄などで指摘いただけるとありがたいです。 Webエンジニアリングの基礎 この記事でカバーしている領域は、以下のような領域です。W
前振り タイトルは煽りの激しい釣りです。ごめんなさい。 Web業界で今流行っている自称スクラムと、RSGTで語られるような本来のスクラムとの間のギャップが大きすぎて説明が面倒臭くなったのでこの記事を書きました。 いい加減「私たちは自称スクラム開発を完璧に回しているから、スクラムの恩恵を将来得られるだろう」「私たちは本来のスクラムとはかけ離れた別物のスタイルで開発をしている。だからスクラムの恩恵は永遠に得られない」という二重思考を他人にするようお願いするのにも飽きましたしね。 さて本題といきましょう 本題 世間で、特に渋谷や五反田や六本木のWeb企業ではスクラムというものはとても流行っています。 しかしどう考えても、Web企業でよくお目にかかるスクラムと国内トップカンファレンスであるRSGTで語られるスクラムとの間には大きな隔たりがあります。 「うちはスクラムやってます」 カジュアル面談で耳
2022/08/04 開発PM勉強会vol.13の登壇資料です。
Cloud Festa 2021 Winter 「デザイナー、データサイエンティスト、 クラウドエンジニア、で実現する共創の世界」 Tsuyoshi Hirayama
自分の生涯年収を考えたことはあるだろうか？ 「一般的なサラリーマンの場合、一生働き続けてもせいぜい1億円」などと言われる。だがじつは、働き方について少し考えを変えるだけで生涯稼げる額はガラッと変わる。 プログラマーの酒井潤氏は文系でありながら独学でプログラミングを学び、現在は、全米給与ランキング4位の米国Splunk,Incでソフトウェアエンジニアとして勤務。また、副業でUdemyのプログラミング講師も務め、年収1億円を実現した。 本稿は、酒井氏の著書『シリコンバレー発スキルの掛け算で年収が増える複業の思考法』（PHP研究所）より、シリコンバレーの事案に見る「稼ぐ人の条件」を紹介する。 ※本稿は、『シリコンバレー発スキルの掛け算で年収が増える複業の思考法』 (PHP研究所)の内容を抜粋・編集したものです。 年収4000万円では足りない 「シリコンバレーでは年収4000万円でも中流階級」とよ
ソフトウェアエンジニアとしての働き方を探求してきた経験と、駐在員として文化の狭間でうろちょろしてきた経験、OSSエンジニアとして多数の多様な人材と交流してきた経験をもとに、果敢にも内製化に挑戦する知人へのアドバイスを気持ちまとめます。 前提 主な利用技術にはJava（Spring Framework）やTypeScriptを想定 FaaSを始めとしたManaged Serviceは（いまのところ）積極採用しない構え Digital Transformationを推し進める一環としての内製化に、エンジニアリングの観点から挑む方を読み手として想定 内製化のターゲットは決まっているか心当たりがある状態 既存の開発チームはほぼ無い想定 1. チームビルディング 1.1. スーツとギークの対立を避ける 我々が若かった頃は"スーツ"と"ギーク"の対立を煽る風潮にありました。Rockstar Engin
2019年10月10日に発売した、及川卓也の著書『ソフトウェア・ファースト あらゆるビジネスを一変させる最強戦略』。このnoteでは、出版の経緯や書籍づくりの裏話、発刊時に削った原稿の公開など、制作にまつわるさまざまな情報を発信していきます。 こんにちは、及川卓也のマネージャーの酒井と申します。今でこそ多くの方にご愛読いただいている『ソフトウェア・ファースト』ですが、制作中はプロダクト開発におけるアンチパターンをいろいろやってしまいました。この経験は、その後の私たちの仕事で「これ、進研ゼミでやったやつだ！」的な効力を発揮し、立ち止まって考える機会を与えてくれています。どれもあるあるで、皆さまのお仕事を振り返る際にもお役に立てるのではないかと思い、整理してみました。 ここからは、酒井真弓著『ルポ 日本のDX最前線』（集英社インターナショナル）を再構成してお届けます。 筆者（酒井）は独立を機に
すべての社会人に知ってほしい仕事の基礎としてのアジャイル/スクラムの話 / Agile as a work foundation
アジャイルやスクラムについて学び始め、実際に取り組むと、その原則や考え方がソフトウェア開発の領域に閉じないことを日々実感します。原則を日々の仕事・生活に活かすことは重要ですが、「アジャイル」という言葉は抽象度が高く、開発のイメージも強いため、一般化してエッセンスを伝えるのに苦労している方も多いのではない…
弊社は未だにメインフレームの相手をしてCOBOLを書いているような、低技術力・プロマネ力偏重のSIer。 20代の若手SE(笑)である僕自身もウォーターフォールの経験しかなく、社内の99%も同じ。 最近興味があって近くにいる人とアジャイル開発の勉強をしていており、ジェフ・サザーランドの著書ほか何冊か本を読んだ、というだけのただのエンジニアワナビー。 最近近所で絵に描いたようなアジャイル失敗例があって、ちょっと誰かに聞いてほしくて書いてる。 この度、既存システムを刷新するプロジェクト（たぶん１億以上５億未満）をアジャイル開発でやることになり、先月くらいに最初のスプリントがスタートした。 アジャイル導入にはおそらく特に動機がなく、お客さんの偉い人たちが ・最近アジャイル？流行ってるんでしょ ・無限に要件変更できるんでしょ ・アジャイルにすると早く安くできるんでしょ などと仰せになった結果だと聞
だめなITベンダー・SIerの行動特性：ITソリューション塾：オルタナティブ・ブログ
もし、あなたが、次のようなことをしているのであれば、これは大いに反省すべきだ。 自分たちの「できること」でしか解決策を示そうとしない。 機能や性能については説明できるが経営や事業の成果にどのような貢献ができるのか説明できない。 これからのテクノロジーやその可能性について分かりやすく説明できない。 お客様が新しい方法論や見積を求めても旧来のやり方で提案しようとする。 新しい方法論やテクノロジーの適用を求めると保証できない、実績がない、時期尚早などのネガティブ・ワードで翻意を迫る。 やがて、お客様から愛想を尽かされてしまうだろう。 工数の需要がなくなるわけではない。ただ、作業工数に応じた労働力に対価を支払うというやり方は、自動化ツールやクラウド・サービスとの競合や人口の減少と相まって、そこでの収益の拡大を期待することができなくなる。 また、工数需要そのものの内容が変わる。例えば、「コードを書く
Vue.js？React？フレームワーク選びの７つの選定基準、大規模ECサイトのフロント刷新プロジェクト - MonotaRO Tech Blog
こんにちは。モノタロウでフロントエンド寄りの開発をしている、陳です。 今回はモノタロウの新フロントエンドのメインフレームワーク選定についてお話しします。 選定結果から言うと、モノタロウ独自の７つの選定基準をもとに、Reactを選ぶことになりました。 背景 新フロントエンドプロジェクトの立ち上がり Vue.jsとReactの比較検討をしてみた 俯瞰して改めて選定基準を考えた 一般的な視点 モノタロウの社内事情 ７つの選定基準 選定結果 技術選定を通して得た３つの学び 背景 まず、モノタロウの現フロントエンドについてざっくり説明します。 モノタロウは2002年から、PythonとJavaScriptでECサイトを開発してきました。 基本構成として、サーバサイドのPythonでHTMLを生成し、クライアントサイドのJavaScriptでカートインなどの動的処理を補完する形ですが、実はこの構成で違
これはなにか エンジニア、ビジネスサイドの方に向けた、「良い要件定義の作り方」について書いた記事です。 長文がつらつらと書いてある本稿ですが、要するに言いたいことは、 ● 完璧な要件定義など幻想であり、誰がどう作っても不完全である ● そのため、一番危険なのは、とびきり賢い人が出してきた要件定義で、 「あの人が作ったんだから大丈夫」と盲目的に考えること ● 完璧にはならないことを受け入れ、ベストを尽くす姿勢が大事 ●そもそも、アジャイル開発において、完璧な要件定義は求められていない ●良い要件定義には以下のスタンスが必要 ● UXから逆算する ● 削ぎ落とす ● 個ではなく、チームで作る ● レビューを徹底する ● 3つのシナリオを想定する ということです。 ※約1万字あり、また各章について深く掘り下げる項目は別記事を添付しています。そのため、モバイルで通読するにはすこし骨が折れるかもしれ
2022/9/17 Scrum Fest Mikawaのだらトラックで発表したスライドです。 https://confengine.com/conferences/scrum-fest-mikawa-2022/proposal/17149
はじめに 恥ずかしながらスクラム開発の開発チームへの導入を何度も経験しているのだけれど、どうしてもチームの成熟レベルが高い位置までもっていくことができませんでした なぜうまくいかないのか？ これを深掘りする過程で教科書どおりに実行するには組織の構造がスクラムガイドで書いてある構造と根本的に異なっているのではないか？と考えるようになりました。 よくあるエンジニア組織の構造 大きめのWebソフトウェア企業の内製型エンジニア組織の構造はだいたいどこもこのような感じになっています この組織構造の問題点 スクラムを導入する場合、リーダー自身かあるいはメンバーの一人がスクラムマスターとなります リーダー自身がスクラムマスターになる場合でもアンチパターンと言われる開発者との兼任になります。 スクラムマスターの最も重要な職務である「観察」が行えなくなります。 スクラムマスター自身が観察を行わない場合、各メ
都は本日(2月12日)、都政の構造改革の実行戦略である「シン・トセイ 都政の構造改革QOSアップグレード戦略」（以下、「シン・トセイ」戦略と記載）の（案）を公表しました！ （詳細はこちらをクリック☟） 「シン・トセイ」戦略 －自治体の公表物としては、聞き慣れないタイトルですよね。 このタイトルには、 東京の更なる「”進”化」に向け、都民ニーズに「”真”摯」に向き合い、民間等、都庁外の様々な主体と連携を"深"めながら、誰からも「”信”頼」される都政へ － といった新たな都政の実現への想いを込めています。 都庁職員1人1人がいかにこの戦略を身近に感じ、改革の浸透を図っていくことができるか。構造改革推進チームの若手職員が真剣に議論し、「職員一丸で新しい都政を創り上げる」意識を共有するためのキーワードとして、「シン・トセイ」を提案しました。 （はい、あのシン・ゴ〇ラや安宅和人氏のシン・二ホンからヒ
1. 『プロジェクトマネジメントの基本が全部わかる本』橋本将功 著、翔泳社 2. 『アート・オブ・プロジェクトマネジメント』Scott Berkun 著、村上 雅章 訳、オライリー・ジャパン 3. 『アジャイルプラクティス 達人プログラマに学ぶ現場開発者の習慣』VenkatSubramaniam,AndyHunt 著、木下史彦,角谷信太郎 監訳、オーム社 4. 『プロジェクトマネジメント知識体系ガイド（PMBOKガイド）第7版＋プロジェクトマネジメント標準』PMI 著、PMI日本支部 監訳 問題。次のうち、どちらが重要？ 1. 炎上プロジェクトを鎮火する技術 2. プロジェクトを炎上させない技術 修羅場における火消しの技術が1だ。燃え上がって墜落寸前のプロジェクトを制御して、なんとか胴体着陸まで持っていくノウハウである。 一方、プロジェクトを修羅場にさせない技術が2だ。そもそもそんな操縦不
毎年開催されているデブサミが2020/2/13(木)、14(金)で開催されましたね。 現時点で公開されている資料のリンクをまとめました。 よろしければご活用ください。 はじめに 公式サイト - Developers Summit 2020 登壇者名は敬称略させていただいています。 Twitterアカウントについては、多くの方はデブサミ公式サイトの紹介ページに記載がありましたので、そちらから引用させていただきました。記載がなかった方については、調べて分かった方のみ記載しています。 資料について、見つけられなかった or 元々資料を使用していない 方についてはレポート記事を見つけられた方のみ、そのリンクを記載しています。 なお、こういったリンクまとめをQiitaに投稿するのは初めてなので何か問題がある場合や、リンクの間違い等ありましたらコメントいただけると助かります。 2/13 13-A-1
【資料公開】レガシーコードからの脱却
アジャイル開発に取り組むチーム向けのコーチングや、技術顧問、認定スクラムマスター研修などの各種トレーニングを提供しています。ぜひお気軽にご相談ください（初回相談無料） みなさんこんにちは。@ryuzeeです。 2019年10月4日に行われたAWS DevDayの「レガシーコードからの脱却」のセッション資料を公開します。 内容は、9月に発売になった同名書籍『レガシーコードからの脱却』の全体像と一部のプラクティスの紹介という形になっています。 時間の関係で紹介できたのはごく一部の内容になっていますので、スライドを見て内容に興味をお持ち頂いた方はぜひ書籍をお読み頂ければと思います。 なお、現在Amazonの在庫が高額な値付けの転売商品？だけになってしまっているので、オライリーの直販か電子書籍(PDF、epub)をご利用ください。 45分という短い時間の中で何をお話するかは結構迷いました。本書はレ
現役EMが語るプロジェクトマネジメント・プロダクトマネジメント・ピープルマネジメントに必要なスキル ─ エンジニア組織をまとめる技術 - はてなニュース
※ Udemy「初夏のビッグセール」と、はてなによるプレゼントキャンペーンは終了しました。エンジニア組織をまとめるスキルは、引き続きUdemyの講座で学習できます。 ソフトウェアエンジニアにとって、マネジメントの職に就くかどうかは大きな選択です。現在ではプレイヤーのままでスタッフエンジニアといった高い職位に進むキャリアもありますが、マネージャーとしてチームを率いてこそ達成できるビジネス上の成功もあるでしょう。 ひとくちにマネージャーといっても、マネジメントの対象によって要求されるスキルに幅があります。これまでUdemyの大きなセールで講座を紹介してきた当ニュースですが、今回はソフトウェア開発組織のマネジメントに必要となるスキルにフォーカスしました。 マネージャーという仕事と学びたいスキルを紹介してくれるのは、10年以上前からPM（プロジェクト・マネージャー）などに就いてチームを牽引し、現在
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
【2024年6月版】ベイジの業務システムUIデザインワークフロー（100のタスクを徹底解説） | ベイジのUIラボ～業務システムとSaaSのUIを考える
プログラミング上達したい人に繰り返し読んで欲しい4冊改訂版｜erukiti
IPA の アジャイル開発版「情報システム・モデル取引・契約書」｜木下史彦
プロダクト開発でドキュメントを書かないとどうなるか
クックパッドを退職することになりました。
「急いで作って！」と言われたとき、私がまずやること→Miroだけでスクラム
「エセ自己組織化」症候群から脱却し、約束を守るプロフェッショナルなアジャイルチームになるには -アジャイル時代のマネジメント進化論- / #RSGT2023
いい加減、プロダクトマネージャーという職業に幻想を抱くのはやめよう。
見積せえへんねやったらどうやって予算取りするねんという話｜牛尾 剛
【Web】知っておきたいWebエンジニアリング各分野の基礎知見80
本に書いてあるスクラムと、お前らのいうスクラム開発は別物だということにいい加減気づいてくれ
チームで盛り上げる ファシリテーション
開発速度が速い #とは（LayerX社内資料）
シリコンバレーで働いてわかった「日本人がお金持ちになれない」納得の理由
内製化をすすめる知人へのアドバイス - Kengo's blog
及川卓也の『ソフトウェア・ファースト』というアンチパターン｜ソフトウェア・ファースト制作委員会
旧来型SIerである弊社でアジャイル（スクラム）が上手く行っていない
完璧な要件定義など幻想である。個ではなく、チームで作る要件定義 - Qiita
デイリースクラムいらなくなくなくなーい！？
日本のソフトウェア企業でよく見るエンジニア組織の構造と、近年推奨されるエンジニア組織の構造について
「シン・トセイ」、始まります。｜＃シン・トセイ 都政の構造改革推進チーム（東京都 公式）
【「スゴ本」中の人が薦める】ITエンジニアなら知ってほしい。プロジェクトを炎上させないマネジメント術を身につける4冊
Developers Summit 2020 資料リンクまとめ - Qiita