年に一度のプロジェクトマネジメントに関するイベント「Backlog World 2020 re:Union」。今回「プロジェクトリスク＆クライシスマネジメント」のテーマで登壇するのは、数多くのシステム開発の現場でプロジェクトマネージャーに従事し、現在は広島修道大学で教壇に立つ佐藤達男氏。前半はプロジェクトマネジメントに必要なことなどを、現場を知る人間の目線で語ってもらいました。 プロジェクトマネジメント論を教える現場経験豊富な大学教授 佐藤達男氏：みなさん、こんにちは。今回のテーマは「プロジェクトリスク＆クライシスマネジメント」です。とくに、プロジェクトマネジメントの中でも、リスクと危機管理にフォーカスして話をしたいと思います。 あらためまして、佐藤達男です。出身は東京で、もとはSI企業で多くのシステム開発プロジェクトでプロジェクトマネージャーを経験。そのあと、全社のプロジェクトを統括する
老舗ITサービスのモダナイズに取り組みはじめたLINEエンジニアたちの挑戦！ 出前館の改善について和田卓人さんが聞いた - はてなニュース
新型コロナウイルスの影響下で、食の宅配などO2O（Online to Offline）サービスが好調です。なかでも有名漫才師を起用したテレビCMも話題となった出前館は、2020年8月期の連結決算で利用者数が前期比で31％増、売上高も前期比で54.6％増となりました（ただし広告展開やシステム投資などの先行投資により営業利益は赤字となっています）。 この背景に、株式会社出前館とLINE株式会社が2020年3月に締結した資本業務提携があります。LINEが出前館の経営に参画し、広告だけでなくサービスの提携も進んでいます。2020年11月には「出前館」アプリがLINEアカウントと連携し、出前館のOEMだったLINEデリマは12月にサービス統合されました。 ただしLINEでは、出前館を「LINE」アプリの関連サービスではなく、独立したO2O事業として継続的に成長させたい。そのためLINEのエンジニアを
はじめに エンジニアとして成長し、「つよつよエンジニア」と呼ばれて周囲から評価されるエンジニアになりたいという若手エンジニアや学生の方は多くいると思います。 私は今までで数百人以上のエンジニアと一緒に仕事をしており、その中にはベンチャーや上場企業でCTO/VPoT/テックリードといった役職についている「つよつよエンジニア」も多くいます。 (かくいう私も組織マネジメント力よりは技術力を評価されてCTOをしていますし、今もコードを書いています)。 「つよつよエンジニアになるためにはどのようなアクションをとればいいか」という視点で述べられていることは多くても「成果物にどのような特徴があるのか」という観点で述べられていることはあまり無い印象です。 成果物の特徴さえわかれば、まだ自身がそのレベルまで到達できていなくても、成果物のレベルを引き上げることができます。 （世阿弥の「風姿花伝」でも「真似る」
はじめにこの記事の対象読者は「機能しているスクラム開発チームのメンバーないし関係者」をイメージしています。 また会社のフェーズや資本状況、フルタイムでないメンバーを雇いたいなどのコンテキストもあるので業務委託が一概に悪とは言いません。 単純に相性が悪いってだけです。 また相性が悪くてもチームが即崩壊するとかそう言う話でもないです。 僕は業務委託の人が嫌いなわけではありません。ただスクラム開発と相性悪いな（主に単価的な意味で）と思っています。 あとここで言うSES的に送り込まれる業務委託の人の単価は月100万~150万円くらいです。 実は「業務委託契約」とは限らないWeb界隈の一部の慣行として「協力会社(個人を指す)」とほぼ同義語として「業務委託」は使われています。「業務委託」と呼ばれる個人に対してリーダーが指揮命令権を持ちます。契約形態は関係ありません(パねぇな)。 実態の契約形態が業務委
こんにちは、freee会計のプロダクトマネージャー（以下PM）をしております、gokiです。 皆さん、「ドメイン知識」という言葉、聞いたことありますか？ ドメイン知識（英: Domain knowledge）または領域知識は、はっきり限定された、ある専門分野に特化した分野の知識であり、一般知識またはドメイン独立の知識と対比される。 ドメイン知識 - Wikipedia freee会計での開発現場で例示すると「確定申告のプロダクトを作るには、開発技術だけでなくそもそも確定申告業務の理解というドメイン知識が必要だよね」みたいな使われ方をします。 freeeはスモールビジネスの皆さんのバックオフィス業務を改善するプロダクトを作っているので、このドメイン知識が開発においても必要な場面が多いです。 そこで、今回はドメイン知識が必要な開発をどのように進めるか、というコツをPM目線でご紹介しようと思いま
※ 2つの意味で解釈できるようなタイトルだった*1ため、より伝えたいことが明確になるタイトルに訂正しました。ご指摘いただいた皆様ありがとうございました。お詫び申し上げます この記事はEngineering Manager Advent Calendar 2019の17日目の記事です。 手前味噌だが、所属している会社のエンジニア組織はだいぶ良い感じになってきているという自負がある。最近書いた自社のブログのエントリも多くの方に共感いただいた。 hackerslab.aktsk.jp 一つ一つの組織活動に対してこれって本当にあるべき姿なんだっけというのを問い続けながら地道な改善を続け、組織としての練度が大分高まってきた。 結果として、自社のあらゆる組織の中で、エンジニア組織は一番改善が進んでいる。*2 一方で、そこはかとなく、「このままで良いんだろうか」というモヤモヤがある。 会社はエンジニアの
先日サーバントワークスさんが公開した 計測によるスクラムチームのパフォーマンス向上 を読んで、 以前自分が書いた 開発の改善はKPIに翻訳しなければいけないのか をもうちょっと言語化することができそうだったのでメモ。 TL;DR 結論としては、開発の改善はKPIに翻訳しなければいけないのか でも書いた通り 開発組織はビジネスの実現を担っている職能であり、理想的には 「永久に持続性がある状態」で 「0秒 でしかも 並列数を無限」 でモノが実現されて、「不具合やパフォーマンスの劣化は 0」 であってほしい。もちろん現実世界ではどれも実現できないのでそこにいかに近づけるかということを目的に改善を実施すればよく、売上などのKPIに翻訳する必要性は必ずしもない から考え方は変わってないが、改めて整理して 開発組織は、Ability to Innovate と Time to Market 2つのケイ
こんにちは、エムスリーデザイングループでチームリーダーをやりながらエンジニアリングGも兼務しているプロダクトデザイナーの大月です。 私が所属しているエムスリーのデザイン組織は以下２つの強みがあります。 多様性 スピード 特に日々の業務では"スピード"をとても大切にしており、 デザインを早くすることで、検証回数を増やし、PDCAを多く回し、価値創造を加速することを意識しています。 こうしたエムスリーのスピード文化から、日々の業務を効率化できるFigma活用法もデザイナーのみんなで学びあっています。 今回は、エムスリーのデザイナー間で話題になった、意外と知らなかった、知っているだけで日々の業務が一気に楽になった！というFigma活用術を紹介します。 少しでもFigmaでのデザイン作業をスピードアップさせたい方の参考になれば幸いです！ 爆速のための3種の神器 1. 秩序をつくる ファイル構成とコ
スクラムを開発方法論に採用しているチームで開発者をしています。最近たまたま見積もりについての話題がチームであがり、私の経験や考えを整理してみる機会にしようと考えました。お断りとして、本稿の考え方が正しいと主張する意図はありません。世の中にはさまざまなチームや開発スタイルがあります。私が経験していない業務においては他のやり方もうまくいくケースがあると考えています。 スクラムガイド には見積もりの実践について明確な指針を提供していません。一方でスプリントを設定し、スプリントプランニングを行う上で通常はその期間内にスプリントゴールの達成を図ることから、必然的になんらかの見積もりを行うことを前提としています。インターネットを検索すると、プランニングポーカーとストーリーポイントを用いた見積もりの記事も多くみつかります。私の立場として、ストーリーポイントという見積もり手法をやや懐疑的にみています。この
―─外資系IT企業三社をそれぞれ九年間ずつ、二七年間経験されましたが、そんなご経験に関心を持った自動車部品最大手のデンソーから声がかかり、技術顧問をされていますね。 自動車産業は日本にとって最後の砦とも言えるものですが、デジタル化の進展にともなって、MaaS（Mobility as a service、マイカー以外の公共交通機関やカーシェアなどの移動全体を一体のサービスとしてとらえる概念）や、CASE（自動車業界の変革を象徴する造語。接続のConnected、自動運転のAutonomous、カーシェアリングのShared、電気自動車のElectricの頭文字から成る）、あるいはIoT（モノのインターネット）など、取り巻く環境が激変しています。変化の主体は産業のサービス化であり、その背景にデータをいかに有効活用するかという技術や、事業化のノウハウが求められ、そうした点で期待されたのだと思いま
1990年代にオブジェクト指向分析・設計の方法論がめちゃ流行ったことがあります。 ただ、そのブームが終わって、後続となるような方法論が流行ることはありませんでした。 で、なぜなのか考えていたのですけど、オブジェクト指向方法論のウリは分析段階で出てきたオブジェクト(といいつつクラス)がコードにそのまま引き継がれるというものでした。ようするにオブジェクト指向方法論というのはコードのスケッチを書いて詳細化していくというものだったのです。 しかしながらこれは、スケッチとして書いた分析・設計が間違っていればコードも間違うわけで、強くウォーターフォールの性質をもつものでした。 結局のところスケッチの妥当性というのはコードを書かないと検証ができません。分析・設計段階で見出されたクラスが妥当かというのは、コード書かなければわからなかったのです。逆に、コードを書けば妥当かどうかわかります。であれば、最初から
「1人アジャイル」から始める、アジャイル開発導入のススメ｜Agile Journeyローンチによせて - Agile Journey
みなさん、こんにちは。 ユーザベースという会社でSaaS事業のCTOを務める林 尚之です。 本日、新しいWebメディア『Agile Journey』がローンチされました。私はこのメディアに編集長として関わりますが、本稿では『Agile Journey』がどんなメディアで、なぜアジャイルをテーマとしたメディアを立ち上げたのかをお伝えしたいと思います。 『Agile Journey』はできるかぎり「実践」にフォーカスしていきたいと考えています。すでに世の中には、アジャイルに関する事柄を解説する本や資料がたくさんあり、「ペアプロってなに？」「TDDってなに？」という問いに対する基本的な解は容易に見つかるでしょう。しかし、「やり方を知る・理解する」と、「それをいかに実践するか」には別の難しさがあります。実際、私も「アジャイルをいかにして、実践するか」に関して日々、頭を悩ませていますし、試行錯誤を繰
リリース手法多すぎﾜﾛﾀｧ B/G、カナリア、機能フラグ、ダークローンチ、A/Bテスト、、など - Qiita
この記事でCloudWatch Evidentlyについて調べていると、「機能フラグ」や「A/Bテスト」などインフラエンジニアには若干聞き慣れないリリース用語が出てきました。 アジャイル開発やCI/CDの台頭に伴い多数出現したこれらのリリース戦略用語をまとめて整理してみることにします。 インフラエンジニアやSREと呼ばれるロールの方々も、リリース戦略を知っておくとCI/CD環境の構築やIaC、はたまたミドルウェアのバージョンアップなどで役立つと思います。 以下ウェブサイトを参考に、各用語を「デプロイ戦略」と「テスト戦略」の大きく2つに分けて紹介します。 デプロイ戦略 従来型のデプロイ（インプレースデプロイ） システム本番環境が一種類のみ存在し、新バージョンの資材デプロイによって旧バージョンの資材を上書いてしまうパターンです。 環境の設計や管理、維持コストをシンプルに抑えられるメリットがあり
AWS公式の「Infrastructure as Code 談議 2022」がすごく勉強になったのでまとめてみた - Qiita
この前AWS公式のYouTubeチャンネルにて、面白そうなライブ配信がありました AWSの動画コンテンツといえば、BlackBeltのようなサービス紹介の動画が真っ先に思い浮かぶ方も多いと思います。 自分もその一人ですが、この動画はプロダクトではなく「Infrastructure as Code（IaC）という概念」にフォーカスしたコンテンツです。 Twitterで学びメモを書きましたが、ちゃんと記事として学びをまとめておこうと思います。 また、動画の内容に関連した補足事項を記事の後半にまとめておきました。 ↓動画本編はこちら↓ ↓資料はこちら↓ IaCをなぜ使うのか 純粋にIaCは楽しい、手順書作成は楽しくない リリースのたびに手順書更新 or 新規作成するのは、果たして楽しいのか IaCのほうがリリースまでのリードタイムが短い 運用する上での教育はどうする？ そもそも「教育」はIaCじ
スクラムマスターがやること、やらないこと - アジャイルトレーニングの専門家に聞いてみた - エンジニアHub｜Webエンジニアのキャリアを考える！
スクラムマスターがやること、やらないこと - アジャイルトレーニングの専門家に聞いてみた スクラムマスターとして日々仕事に邁進していても、教科書どおりにいかないこともしばしば。イベントに人が来ない……、タスク終わらなさそう……などなど、スクラムマスターが直面しがちな、「あるある」な悩みを、アジャイルコーチの吉羽龍太郎さんに相談してみました。 イベントマネジメントの心得 スプリントレビューでは言いたい放題言わせよう！ スプリントの期間延長は絶対NG 大切なのは原因の究明 スコープと期限の両方を守るのは難しい よいチームを作るためにスクラムマスターができること アジャイル開発の定番手法ともいえる「スクラム」。開発チームにスクラムを導入し、効率的に開発を進めるには、スクラムマスターの手腕が欠かせません。しかし、いざスクラムを運用しようにも、現実には教科書どおりいかない場面もあるでしょう。 イベン
GitLab社のGitLab Handbookと徹底した文書化、組織的なオープンネス（？）を先日調べたのだが、じゃあ同じように見える化、透明性をアピールしているツールが何か？と考えた際ににSlackがあると思っている。SlackといえばDM禁止！オープンな職場が良し！風通し良し！なやつである。 しかしそれを実際会社で根付かせようとした時に、Slackの使い方を説くだけでは足りなくて、むしろ皆の意識改革みたいなものが必要だな～とひしひし感じさせられる。オープンな会社が良いかクローズドが良いか、「チームの風通しは良いほうが良いのか？」 世の中ひねた人も居るもんで風通しだけ良くてもこんなデメリットが有るなんて言われる 意見は増えても、内容が浅い 意見の浅い深いを確認する手間がかかる 浅い意見でも対応しなければならない 多数派の浅い意見に流されがちになる https://factory-learn
「テスト書いてないとかお前それ〜」が私の代名詞になるまで。テスト駆動開発とともに歩んだキャリア - Findy Engineer Lab
日本におけるテスト駆動開発の著名人といえば誰か？ この問いを投げかけられたとき、多くのエンジニアが思い浮かべる人物がいます。ITコンサルタント・ソフトウェアエンジニアの和田卓人（@t_wada）さんです。和田さんは日本のテスト駆動開発の第一人者として、長年、この分野の実践や講演・執筆などの普及活動を続けてきました。 こう書くと、読者のなかには「和田さんはもともとテストが好きだったから、テスト駆動開発の第一人者になれたのでは」と思われた方もいるかもしれません。しかし、その答えはNOです。むしろ和田さんは、テストが嫌いなエンジニアだったといいます。ある出来事をきっかけとして、嫌いだったテストを好きになれる方法を見つけたのです。 読者の方々にも「自分には○○なんて向いていない」という印象を抱いている技術領域があるかもしれません。ですが、そんな領域にこそ、あなたの新たな可能性が詰まっているかもしれ
みんなの銀行：日本初の「デジタルバンク」として Google Cloud に勘定系を構築。Cloud Spanner で銀行基幹システムで求められる可用性を実現 | Google Cloud Blog
みんなの銀行：日本初の「デジタルバンク」として Google Cloud に勘定系を構築。Cloud Spanner で銀行基幹システムで求められる可用性を実現 2021 年 5 月にサービス提供を開始した「みんなの銀行」は、デジタル ネイティブ世代をターゲットとしたスマートフォン専業銀行。金融にまつわる煩わしさを排除し、ゼロベースでこれからの銀行に求められる機能を開発・提供していくと打ち出しています。そんな同行の大きな技術的トピックの 1 つが、勘定系システムにパブリッククラウドを採用したこと。これはもちろん国内初*の試みです。ここではサービス開始後の手応えをシステム構築をリードしてきた皆さんにお伺いしました。 利用している Google Cloud ソリューション： Google Cloud Databases、Stream Analytics 利用している Google Cloud
テスト専門会社が出版した渾身の書、『【この1冊でよくわかる】ソフトウェアテストの教科書』の出版ストーリー：多くのエンジニアに愛される理由とは
テスト専門会社が出版した渾身の書、『【この1冊でよくわかる】ソフトウェアテストの教科書』の出版ストーリー：多くのエンジニアに愛される理由とは 『【この1冊でよくわかる】 ソフトウェアテストの教科書 [増補改訂 第2版]』は、初版の発行部数は22,000部、2021年8月出版の改訂版は13,000部に上り、技術書としては異例のシリーズ累計35,000部を突破しました。（2023年6月現在） ソフトウェアテスト専門企業であるバルテス株式会社の技術者が執筆した、ソフトウェア開発工程のテストについて、基礎からしっかり体系的に学習できる本格入門書です。 このストーリーでは、初心者から上級者まで幅広い層に読まれている、ソフトウェアテストのバイブルともいえる本書完成までの経緯や苦労話、著者であるバルテスの石原 一宏氏と布施 昌弘氏が伝え続けたい想いをお伝えします。 テスト設計に必要な考え方を身につけられ
アジャイルとかいうクソみたいな開発
結論から言うと受発注の関係性でアジャイル開発やるのは完全に間違えてる 受注側が優秀だと発注側の意思決定の遅さにイライラするし 受注側が未熟だと発注側のイメージが具現化されない 第三者的に両方の場合に遭遇したんだが記録しておきたい 受注側が優秀な場合スプリントのスピードが速すぎて発注側の意思決定が間に合わない 評価用のボタンを作成するときにGood/BadにするかGood/Normal/Badにするかを決めるだけで2週間かかる 本来なら意思決定者がミーティングに出て欲しいが日本企業は権限委譲しない会社ばかりなので 最終決定は上役の偉い人になるが、そういう人はなかなか捕まらないので意思決定が遅くなる 「意思決定を早くしよう」ということでミーティング時間を10分に制限するとか意味不明なことをしてる 責任を下位の役職まで委譲しないとアジャイルは成り立たない まぁなのでこういう組織にはアジャイルは向
この記事はEngineering Management Advent Calendar 2022の7日目です. 今はエンジニアリングマネージャ(EM)としてエンジニアリングマネジメントの4領域(プロダクト・プロジェクト・テクノロジ・ピープル)すべてを見ていますが, それ以前は長い間テックリードをやっていました. その経験を活かして, 最近は後進を育ててテックリードあるいは「弱いEM」*1をできる人材を増やそうとしています(これ自体がピープルマネジメントの一環ですね). テックリードを育てるためにやっていることの全容を詳細に書くと本が1冊書けるくらいになってしまうと思うので, その中でも再利用可能そうな(と言うより再利用可能にしたいと目論んでいる)「テックリード養成講座」について紹介したいと思います. Memeplex.appで生成した, テックなリードが養成されるイメージ 経緯 僕自身は,
アジャイル迷子のための「アジャイルの本質」。あとDDDとのつながり - little hands' lab
記事の構成 アジャイルソフトウェア開発とは アジャイルマニフェストとは アジャイルマニフェストの問題 そこで、アジャイルの本質 by マーティンファウラー アジャイルソフトウェア開発とは？ アジャイルソフトウェア開発とはなんでしょうか？ 「アジャイルマニフェスト(後述)の4つの価値観、12の原則に従う開発方法の総称」 これが最もオリジナルな定義です。 なぜこんなややこしい言い回しをするのは後から説明します。 重要なことは、「アジャイル」という具体的な手法があるわけではないということです。 アジャイルはマインドセット(思想、考え方)です。そのため、 ✖️ do agile 「アジャイルをやる」はありません。 ⭕️ be agile 「アジャイルになる、アジャイルの思想に則る」はあります。 アジャイルの思想に則った開発手法として ・スクラム ・エクストリームプログラミング(XP) ・リーンスタ
アジャイル・DevOps時代の テストと品質保証 （完全版） / Testing and Quality Assurance in Agile and DevOps Era
この10年は多くの変化がありました。 ソフトウェア開発プロセスにおいては、アジャイル開発の普及が進み、さまざまな現場でスクラムが活用されるようになりました。 技術面では、コンテナ技術やその管理の自動化が進み、システムはどんどん複雑になりつつあります。 一方で、テストや品質保証はどのように変わってきたでしょうか？ 私はアジャイルコーチとして10年活動してきましたが、 最近話題の「DX（デジタルトランスフォーメーション）」の影響か、 開発に速さがより求められるようになってきたように感じています。 そして、その影響もあってか「テストがボトルネックになりがち」や 「マニュアルテストのチームがコストセンターになってしまった」という相談をよく受けるようになりました。 このセッションでは、アジャイル・DevOps時代におけるテストと品質について、 - 現在 - 戦略と戦術 - 組織未来 のお話させていた
書籍「ソフトウェアテスト技法ドリル」ではテスト設計の考えとツールの使い方まで学べちゃいました | DevelopersIO
私は開発寄りのエンジニアであり、テストやQA専門の方と同じチームで頑張る機会が少なかったのですが、「なるほど、こうやって考えて、こういうツールを使っているのか」と非常に勉強になりました。 こんにちは。AWS事業本部モダンアプリケーションコンサルティング部に所属している今泉（@bun76235104）です。 最近ではアジャイル開発やスクラム開発が多く採用され、ビジネスのスピードに負けないようにプロダクト開発・リリースのスピードが求められれている中で、「いかに効率よく、かつ効果的なテストをしていけるか」というのはテスト担当だけでなく、開発メンバー全員で考える必要があると思います。 とはいえ、実際のチームには「専任のQAエンジニアやテストアナリストはいない」ということは非常に多いと思います。 基本的なテスト技法は本で学んできたけど、どういう時にどんな技法でテストを設計すればよいの？ 本職のテスト
2019.6.23 DevLOVE X (DevLOVE 10周年イベント) @ NAVITIME で話した資料です。
6月1日付けでNature Japan株式会社の取締役CTOに就任しました。最初の営業日の6/3(月)からいきなり台湾出張に行ってきました。良いスタートアップ感。ついでに本日6月5日に39歳になりました。新たなチャレンジにワクワクしています。 大塚(@maaash)さん、村瀬(@typester)さんに続く3代目のCTOとなります。2人はカヤック時代の同僚でもありますが、カヤックのラボチームのダブルエースだった彼らの後任としてCTOをやるのは恐れ多いのですが、僕は組織づくりなど含めて僕なりに組織に貢献していきます。 当社はおかげさまでスマートリモコンのNature Remoが好調で、現在はNature Remo Eというスマートエネルギーハブの開発を進めているところです。今後は電力なども見据えて事業を展開していく計画で面白いフェーズにあります。 まだ、社員全員でも10人に満たない小さな会社
スプリントの振り返り大全 〜 チームに最適な手法を見つける15のレトロスペクティブを振り返る - Agile Journey
はじめまして。株式会社イノベーター・ジャパンでフロントエンドエンジニアをしている、うじた（@besburg）です。弊社ではスクラムによる開発を取り入れており、スプリントの最後には毎回スプリントレトロスペクティブという振り返りを行っています。そこで試した振り返りの手法をこの記事ではまとめてみました。 私たちのプロジェクトではタスクの優先度に入れ替わりが多く、今やっていることを可視化するため、2021年8月からスクラムを開始しました。参加メンバーは各プロジェクトのエンジニア全員で、スプリント期間に合わせて1週間ごとに振り返りを行っています。スクラムによる開発が初めてだったこともあり、当初は自分たちに合った手法を見つけることを目標に振り返りを進めました。 週ごとにメンバーが交代でファシリテーターを担当し、試したい振り返り手法を持ち寄ってレトロスペクティブを行いました。そのため基本的には振り返り手
見積もりという概念を「見積もり」「コミットメント」「ターゲット」に分ければもっと楽しく開発できる - Link and Motivation Developers' Blog
（※本記事は去年の弊社のQiita アドベントカレンダーに投稿したものをリライトしたものになります。反響が嬉しすぎたので自社ブログにも載せて擦ります。） はじめに リンクアンドモチベーションで、エンジニアをしています、宮田と申します。 自分は外部の技術顧問の方に月に一回のペースで1on1する機会をもらっています。 今回はその中で話したことを共有します。 公開するにあたって分かりやすさを重視して少し脚色していますが、大筋はリアルなものです。 見積もりに対する課題感 ぼく「約束は開発を遅らせるという記事を最近読んだのですが、その通りだと思ったのですよね。」 さて、チームの外に対して約束するために「この機能1ヶ月で出せるよね？」とプロダクトの人やマネージャーに聞かれたら。これは返事に悩む。「ラフで構わないから」って言われて伝えたら、それがコミットメントになってしまったのを過去に何度も見たことがあ
スクラムを組織全体へスケールさせていくフレームワーク「Scrum@Scale」入門（前編）。Developers Summit 2019
スクラムを組織全体へスケールさせていくフレームワーク「Scrum@Scale」入門（前編）。Developers Summit 2019 アジャイル開発手法を実現する方法として、もっとも普及しているのが「スクラム」でしょう。 スクラムを開発チームの単位で導入している企業は増えてきましたが、これをスケールさせる、つまりスクラムの手法を使って組織全体をより早く動かし、より早く価値を届けていくにはどうすればいいのでしょうか。 そのために開発されたのが「Scrum@Scale」フレームワークです。スクラムをスケールさせる仕組みの背後にあるスケールフリーネットワークや、大きな組織でも迅速に情報を共有する手法が組み込まれた「Scrum@Scale」について、2019年2月に行われたイベント「Developers Summit 2019」で株式会社アトラクタの代表取締役 原田騎郎氏が説明しています。 本
テスト駆動開発：実はそれは設計技術です
テスト駆動開発（TDD）は、より優れたソフトウェアを持続的に早く提供するための確立された手法です。TDDは単純な考えに基づいている。製品コードを書く前に失敗するテストを書くことです。新しい行動が必要ですか？失敗するテストを書いてください。しかし、この一見単純な考えをうまく実行するには、スキルと判断が必要です。 TDDは本当に設計のためのテクニックです。TDDの基礎は、小規模なテストを使用してボトムアップを早急に設計することであり、システムへの信頼を構築しながら迅速に何らかの価値を得ることです。よりよい名前はテスト駆動設計かもしれません。 設計方法としては、集中と単純さです。目標は、開発者が価値を提供する上で不要な余分なコードを書くことを防ぐことです。問題を解決するのに必要最小限のコードを書くことです。 多くの記事がTDDを行うことのすべての利点を誇りにしています。そして多くの技術会議の講演
ECSを触っていて今まで難しいと思ったことを雑にまとめておく。 ECSを仕事で運用するときに必要な知識が多すぎる。こんなの社内に1人AWSマスターいないと無理だ...— 神速 (@sinsoku_listy) 2021年8月10日 タスクロールとタスク実行ロールの違い ECSを長く触っているのに、いつも混乱する。 タスクロール コンテナ内の権限 S3やSESなどの権限をつける タスク実行ロール コンテナ外の権限 ECRやParameter Storeの権限をつける ECSのデプロイ時に静的ファイルが404になる ECSを触った初期に遭遇した。 詳細は以下のQiitaの記事が分かりやすい。 参照: ECSのデプロイ時に一定確率で静的ファイルが404になる問題を回避する 回避する方法はいくつかある。 静的ファイルをS3に置く CodeDeployの OneAtATime を使う CodeDep
みなさんこんにちは。@ryuzeeです。 スクラムにおいて、スクラムチーム全体のパフォーマンスをどのようにして上げていくかは難しいテーマですが、プロダクトオーナーの視点でこれを捉えた「10 things you must do to build high-performing Scrum Teams as a Product Owner」という記事が良い記事だったので、翻訳したものをご紹介します。 翻訳に際しては、著者のMaarten Dalmijnさんに快諾いただきました。 なお、著者のMaartenさんはほかにもプロダクトオーナーに関する有用な記事を書いているので、参考にするとよいかと思います。 プロダクトオーナーの開発チームへの関わり方は、開発チームのパフォーマンスにおいてとても重要です。ダメなプロダクトオーナーだと、ハイパフォーマンスチームを簡単に潰してしまう可能性があります。 私
伝統的でかつ大きな組織で、アジャイル開発を広げていくためには？ 難しいテーマで、必ずといって良いほどに直面する。様々な考え方があるが、何周か回って、私は「ガイドを作る」を推奨することにしている。 ガイドと聞いただけで眉をひそめる人もいるかもしれない。私も、ガイドなんかで表現できるものではない、かえって安易な理解に留まってしまう、と考えていた方だ。 しかし、アジャイル開発に限らず、何をするにしても最初のまとまった足場的知識が無ければ、スタートを切ることさえできないのも事実。もっというと、足場的な理解とは当事者だけ得られば良いわけでもなく、同じように組織内の他者にも一定分かってもらう必要がある。そうでなければ組織として動くことができない。 だからこそ、スクラムガイドがある。いくつかモダンなアジャイル開発の入門書もある。そう、まずもって、アジャイル開発に取り組むのであれば、スクラムガイドを読むの
多くの企業がこれまで以上に注力している管理職育成。一方で管理職に求められる機能は減ることがなく、むしろ時代の流れとともに求められる役割は増え、負担そのものは増加し続けているという現状も。そこで今回は、組織強化のコンサルタントサービスなどを提供する株式会社タバネルの奥田和広氏が、マネジメントを仕組み化するための4つのステップを解説します。 組織課題の1位は“ミドルマネジメント層の過剰負担” 奥田和広氏：まずは今日の主題の「中間管理職の実態」からお話をさせていただきたいと思います。どんな企業でも、中間管理職の方はいらっしゃいます。「中間管理職は組織の要」なんて言われることが多いですね。 経営者からの要求と、現場からの要求、「経営と現場をつなぐ要」ということで、中間管理職は組織の中で非常に重要な役割を果たしていることになるかと思います。 こういう重要な役割を果たしていますので、当然、業務的にも責
技術書は気に入った一節を見つけるだけでいい
ということで、私の例をいくつか出してみようと思います。 モノリスからマイクロサービスへ マイクロサービス・アーキテクチャの著者による、モノリスからの移行をガイドするような雰囲気のするこの本ですが、この本は第6章「終わり」にから、この一節です: 他人の事例から学ぶべき教訓があるのは事実だが、自分のコンテキストでうまく機能するアプローチを見つけるには、時間をかけなければならない。 これはあらゆるプラクティスに言えることで、私は事あるごとに「スクラムをそのまま導入するのは無駄だ」とか「守破離っていうやつは苦手だ」とか言い続けているんですが、それはつまり、先人のプラクティスは様々な状況（コンテキスト）があるなかで成功した事例であり、コンテキストが異なる現場に持ち込んでもうまく機能するかは未知なのです。なので、そのプラクティスが前提としているコンテキストとソリューションを理解しつつ、自分たちのコンテ
こんにちは、NE会社で働いておりますきんじょう(@o0h_)がお送りします。 弊社ではPHPを用いてアプリケーション開発を行っています(Ruby, Go, Javaも領域によっては利用しております) さて、つい先日のことですが、社内にいるメンバーから「デザインパターンについて、勉強してみてるんだけど・・・」「ちょっとついていくのが難しくて」「どうしたらいいですかね？それとも、先にやっておくべきことが他にありますか？」なんて雑談をしました。 なるほど、コレは頻出質問になりそうだな・・・という気持ちにもなったので、今回はこの場を借りて「デザインパターン[1]、その前に〜個人的に思ったことをツラツラと〜」でお届けしていきたいと思います。 「デザインパターンを(から)勉強してみる」ことの、オススメ/オススメナイ いちおう、今回は「リーダブルコードくらいは読んでいる」「デザインパターンの勉強をしてい
【資料公開】プロダクトマネージャーのしごと
みなさんこんにちは。@ryuzeeです。 2023年10月17日に行われたオンラインイベント「プロダクトマネージャーのしごと - Forkwell Library #33」の登壇資料を公開します。 内容は、新刊書籍『プロダクトマネージャーのしごと』に関するものなのですが、30分という時間で全部を網羅的に紹介するのは無理ですし、ぜひ本書を読んでいただきたいので、僕が気に入っているところと、本書全体を通して中心にある考え方を紹介しました。 ちなみに書籍は16章から構成されていて、そのなかで特に自分が好きなのは「7章 「ベストプラクティス」のワーストなところ」です。 職業柄、日頃から「プロダクトマネジメントではどんなフレームワークを使うといいですか？」「プロダクトマネジメントの日本での成功事例を教えてください」「プロダクトマネジメントのベストプラクティスを教えてください」のような質問をたびたびい
昔、上司に言われた言葉 誰だって「できるだけいい仕事をしたい」と考えています。 その人なりに一生懸命コードを書いてプルリクエストを作っています。 あなたが放つ言葉は、周りの人間の心に影響を与えます。 相手のモチベーションを下げることも上げることもできます。 我々は互いに「環境」なんです。 誰かにとっての良い環境であってください。 フィードバックには信頼関係が大事 その上司は、コードレビューをする際に 以下のようなことを心がけているようです。 「ここを直してください」の前に「ここ、よく考えられてますね」を伝える できていない部分だけにフォーカスしない 「一緒に良いものを作っていこう」という気持ちでフィードバックする でも、急にそんなポジティブ人間になれない そこで、ChatGPTの力を借ります。 ネガティブなフィードバックを、ポジティブに言い換える 良いところを見つけて、褒める 冷たい敬語で
【続】ソフトウェア設計についてtwada技術顧問と話してみた 〜 A Philosophy of Software Design をベースに 〜 - NTT Communications Engineers' Blog
はじめに 本記事は前回の記事である「ソフトウェア設計についてtwada技術顧問と話してみた 〜 A Philosophy of Software Design をベースに 〜 - NTT Communications Engineers' Blog」の続編です。 前回の記事の内容がベースとなっていますので、「APoSD って何だっけ？」という場合はぜひ前回の記事をご覧になってから、以下にお進みください。 ということで、後編の対話パートにさっそく入っていきましょう！ Pull Complexity Downwards iwashi: APoSD では、複雑性を下に追いやる(Pull Complexity Downwards)という話が出てきます。何らかの処理が複雑になる場合、それを隠蔽してインターフェースを極力シンプルに保つ、というのがAPoSDの主張です。 こちらに関しても、社内勉強会中で
DevOpsは失敗する
lbr.より。 BY リー・ブリッグス 初めて聞いた言葉を思い出すのは、ほとんどの人にとって難しいことでしょうが、私は初めて「DevOps」という言葉を聞いた時のことを覚えています。2013年、その時点で私が知っていることのほとんどすべてを教えてくれた同僚とビールを飲んでいるときのことでした。私は幸運にも、自分が始めた新しい仕事に彼を連れてくることができました。彼は、多くの気の利いたことができ、私は彼の力に便乗することができました。私たちは、新しい会社で目にした問題のいくつかを話し合っていました。それは、おそらく今ではほとんど人にとって身近に感じられるものでしょう。アプリケーションが本番稼働しているときのサポートに苦労していたのです。 彼は、私たち全員が同じ考えを持つためには、ライフサイクルの早い段階から関与する必要があると話していました。その時、彼がオーストラリア訛りで言った「DevOp
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
プロジェクトを成功させたければ人を信用してはいけない 大学教授が考えるプロジェクトマネジメントで重要な3つのこと
つよつよエンジニアの成果物にある5つの特徴 - Qiita
スクラム開発チームと業務委託エンジニアの相性が最悪だと思っている｜s_semiya
ドメイン知識が求められる開発をどのように乗り切るか - freee Developers Hub
エンジニアだけが優遇されるのではない組織をつくりたい - Unknown Error
開発組織の貢献は売上として直接語るのはやはり無理があるのではないかという考察
明日からできる、爆速Figma活用術 - エムスリーテックブログ
見積もりをがんばらない - forest book
ソフト開発で世界と闘った及川卓也氏が見た、日本の弱点と可能性（中央公論） - Yahoo!ニュース
なぜオブジェクト指向方法論に代わる方法論が出ないのか - きしだのHatena
Slack社はSlackをどう使っているのか - Slack利用ガイドラインの話 - Qiita
テックリードを再生産可能にする - テックリード養成講座をやっている話 - 貳佰伍拾陸夜日記
アジャイルな開発組織のOKRベストプラクティス＆アンチパターン
Nature Remo作ってる会社のCTOになったのでみんな買ってくれよな！ | おそらくはそれさえも平凡な日々
ECSを運用で使っていて難しいと思った点 - アジャイルSEの憂鬱
【翻訳】ハイパフォーマンスチームを作るためにプロダクトオーナーがすべき10のこと
政府情報システム開発における「アジャイル・ガイド」｜市谷 聡啓 (papanda)
中間管理職の「過剰負担」は、なぜいつまでも解消しないのか？ 見逃しがちな“落とし穴”とマネジメント再構築の4ステップ
デザインパターン〜とかアーキテクチャ〜〜とか・・・に行く途中の話
エンジニアさん、正論ばっか吐いてないで相手を褒めてください - Qiita