アジャイル開発の外部委託が「偽装請負」だと疑われないためにすべきこと、厚労省が公表した疑義応答集を読み解く（前編）。Agile Japan 2021
アジャイル開発の外部委託が「偽装請負」だと疑われないためにすべきこと、厚労省が公表した疑義応答集を読み解く（前編）。Agile Japan 2021 アジャイル開発において開発担当者を外部のベンダに依頼した場合、必然的に発注側の企業とベンダ側の開発者が1つのチームとなり密なコミュニケーションを行います。 すると、発注側の企業がベンダの開発者の業務遂行に対して具体的な指示を行う、いわゆる「偽装請負」とみなされる可能性があるのではないか？ という疑義が以前から呈されていました。 この疑義に対して、どのように対処すれば偽装請負と見なされないか、その指針が今年9月に厚生労働省から「労働者派遣事業と請負により行われる事業との区分に関する基準（37号告示）関係疑義応答集」として公表されています。 オンラインで11月8日に開催されたイベント「Agile Japan 2021 Day 0」では、この疑義応
クラウドネイティブなアプリケーション環境向けアーキテクチャー
原文: Introduction to cloud-native application environment architecture By Christina Lin July 2, 2019 クラウドネイティブ環境のアーキテクチャーを理解するのはとても大変だったりします。アプリケーション開発者や ソフトウェア／システムアーキテクトの理解を助ける為、これからクラウドネイティブ環境のアーキテクチャーを構成する個々の要素とそれらがどのように連携するかについて説明します。 より理解しやすくするには、アーキテクチャーを4階層に分けて考えるのが有効である事に気がつきました。4階層は、「アプリケーションソフトウェア開発」、「サービスのスケール」、「アプリケーションネットワーク」、「コンテナオーケストレーションプラットフォーム」から構成されます。 この記事では、最初の階層である「アプリケーションソ
アジャイルFAQ | ワイクル株式会社
コンサルや研修しているときに聞かれた質疑応答の一覧です。ひとまず2017年にいただいたものをまとめました。 Q. 1人でスクラムを始めたいと思いますができますか？ 「スクラム」はできないですが、スクラムのなかの特定の手法は可能です。たとえば、バックログを作って上から順番にやっていくとか、定期的にふりかえるとか。 Q. 遠隔チームでのスクラムはデジタルツールを使えば可能？ 「最初のうちは同じ場所で、慣れてきたら離れて」が基本 チームの成熟度次第なので、最初からうまくできるチームもあります Q. チームの相乗効果を上げるにはどうすれば？ チームの数だけやり方がある。 チームだけの文化や言語を作っていくことが重要かも。「一緒にご飯を食べる」というのは鉄板です。 『Team Geek』オススメです！！！！！（宣伝） Q. 開発チームがステークホルダーに直接アクセスするのはNG？ あとでPOに情報共
アジャイルを無責任に広めるのはもうやめよう
（画像：wikimedia commons） こんな記事を見かけました。 記者の眼 – 「アジャイル嫌い」はもうやめよう：ITpro http://itpro.nikkeibp.co.jp/atcl/watcher/14/334361/082400357/?ST=system&P=1 開発の経験が長い人からすると、「あーはいはい」と昏い目をしてしまうような記事なのですが、実際のところアジャイルを宣伝する本やブログなどは多く、「プロジェクトを始めよう！」となったときに、候補に上がることが多い開発手法ではあります。 しかし、現場の現実から言うと、安易にアジャイルを導入して失敗するケースは非常に多いです。 私は20件以上のアジャイルプロジェクトを見てきましたが、そのうちちゃんと成功していたプロジェクトはたったの3件だけです（ウォーターフォールは100件以上見ていますが、成功率はそんなに低くはあり
Agile も DevOps も銀の弾丸なんかじゃない
This browser is no longer supported. Upgrade to Microsoft Edge to take advantage of the latest features, security updates, and technical support. ……と、のっけから噛みつかれそうなタイトルを掲げてみたのですが；、ここ最近、立て続けて数件、「いやそれはアジャイルとか無理だろ；」的な話があって、ちょっとエントリを書いてみようかと思った次第。どんな話だったのかというと、 アジャイルとか DevOps やれば必ず開発生産性上がるんでしょ？ → そんなわけないでしょ；。 これからの開発は当然アジャイルとか DevOps でしょ！ → そんなわけないでしょ；。 みたいな話；。2 年ほど前に、「続・拝啓『変わらない開発現場』を嘆く皆様へ ～ ウォータフォール
新人プログラマに正月休み中を使って読んでみてほしい技術書をセレクトしてみた。 - Qiita
エンジニア組織を強くするための本を出版しました Qiitaでエンジニアリングをめぐる様々なコミュニケーションの問題とその解決策や考え方を書いてきた。それらの背後にあるエッセンスをこの度書籍として出版するに至りました。 エンジニアリング組織論への招待 ～不確実性に向き合う思考と組織のリファクタリング この書籍は、エンジニアリングを「不確実性を削減する」という第一原理で捉え直し、様々なエンジニアリングとその間のコミュニケーションをめぐる現象を説明していくものです。 はじめに 今年、書いた幾つかの記事のタネ本であったり、新卒教育の際に参考書籍としてあげたものを中心にリストアップします。一応amazonへのリンクも貼っておきますが、先輩が持ってたりすると思うので、冬休みに借りて一気に読んでおくのもいいかと思います。 その時々、必要な技術の習得に日々追われているんじゃないかと思いますが、いつまでも使
マーチン・ファウラー氏が語る、21世紀のソフトウェアデザインとしてのアジャイル開発（前編）。Agile Conference tokyo 2011 － Publickey
アジャイル開発に関する論客の一人マーチン・ファウラー氏は、7月20日にテクノロジックアートが主催したイベント「Agile Conference tokyo 2011」で「21世紀のソフトウェアデザイン」をテーマに基調講演を行いました。 ファウラー氏の基調講演の様子を紹介しましょう。 アジャイル開発の意味が希薄化している ThoughtWorksのマーチン・ファウラー氏。 アジャイルソフトウェア開発宣言から10年がたち、そのあいだいろんな人が伝えていくうちに当初の意味の希薄化（Semantic Diffusion）が起きてしまったと思う。私の役割は、最初の意味を思い出してもらうことだ。 要件の安定性に依存するのは不健全だ まずは「予想的な計画（Predictive Plannning）」と「適応的な計画（Adaptive Plannning）」について。 土木や建築に由来するのが「計画駆動開
アジャイル型開発を推進するための活動成果を公開 - 情報処理推進機構：ソフトウェアエンジニアリング
2012年3月26日 更新 2011年4月7日 公開 独立行政法人情報処理推進機構 ソフトウェア・エンジニアリング・センター 概要 最近のソフトウェア開発では、ビジネス環境の変化への対応、これに伴う要求の変更、ソフトウェアの市場投入や投資効果の確認の迅速化が、以前にも増して厳しく求められています。このような状況において、要件を最初に決めずに開発に着手できるアジャイル型を中心とする非ウォーターフォール型の開発手法が注目されています。 IPA（独立行政法人情報処理推進機構）ソフトウェア・エンジニアリング・センター（SEC）では、ウォーターフォール型開発及び、アジャイル型開発の経験が豊富な実務者、契約に詳しい専門家など、産学官の有識者をメンバーとした「非ウォーターフォール型開発ワーキンググループ」を設置し、これらの課題について検討してきました。 この度、日本におけるアジャイル型開発に適したモデル
警子ちゃん.com
ISAダイレクトは、アイエスエイの直販ショップです。ここでしか手に入らないオリジナル商品やアウトレット品の販売、お得なキャンペーンなどを行います。警子ちゃんやメル丸くんなどのオプション品取扱もございます。
アジャイル開発手法「スクラム」の工程を、1枚のイラストで分かりやすく説明する
アジャイル開発手法としてもっともよく使われている「スクラム」の工程を1枚のイラストで説明した資料が、ブログRyuzee.comのエントリ「[Agile]Scrumの流れをイラスト1枚で説明した資料」で紹介されていました。 とても分かりやすいイラストでしたので、Publickeyでも紹介させていただきます（大きな画像はこちら）。 日本語の文字が少し小さかったので、あらためて僕の方で日本語を当てはめてみました。もしも変な訳だと感じた方がいましたらアドバイスなどいただければと思います。 このイラストのオリジナルとなったのが、ブログThe Critical Path by Derek Huetherにポストされた「Free Intro To Scrum Wallpaper」です。この記事ではもう1つ、スクラムの工程を別のイラストで紹介したものがあるので、そちらも日本語化してみました（大きな画像はこ
Clear and Present Scrum on Devlopers Summit 2011
10. chriszak - flickr Source :: Forrest Research 2010 - Agile Development:Mainstream Adoption Has Changed Agility 2011 2 18 10 11. royskeane - flickr Source :: VERSIONONE - State of Agile Development Survey Results 2010 2011 2 18 11 12. VP/Dir. of Development 22% Development Manager 15% Project Manager 13% CIO/CTO 11% Team Lead 8% Developer 7% President/CEO/COO 7% 0% 8% 17% 25% Source :: VERSIONONE
はてなチーフエンジニアが聞く、サイボウズLiveのアジャイルな開発現場 - はてなニュース
「ビジネス上のコミュニケーションを、メールの不便さから解放したい」という思いから2009年にサイボウズがスタートした無料コラボレーションツール「サイボウズLive」。その開発現場は、Webアプリケーション開発の流行をうまく取り入れたアジャイルなものでした。その様子を、はてなチーフエンジニアの大西康裕がインタビューしました。テーマは、プログラミング言語の選び方から、自動ビルドと自動テスト、リファクタリング、チーム内コミュニケーションなど。大西自身も「面白かった」と語る取材の様子をぜひお楽しみください。記事の最後ではプレゼントもご案内しています。ところでこの取材には、サイボウズ・ラボの竹迫良範氏が、なぜか大量のレッドブルを抱えて登場したのですが……。 http://live.cybozu.co.jp/ （※この記事はサイボウズ株式会社提供によるPR記事です。） 大西 はてなチーフエンジニアの大
アジャイルモデルのエッセンス: アジャイルに作れる成果物
by Scott W. Ambler, Copyright 2003 効果的にアジャイルモデリングを行うには、さまざまな種類のモデリング手法を知っておく必要があります。残念ながら、これは口で言うほど簡単なことではありません。このページはまだ作成中ですが、さまざまなモデリング成果物の概要へリンクしています。各ページには、その成果物についの解説と、1、2の例、推奨文献へのリンクが含まれています。 モデリング成果物 ビジネスルール ビジネス/本質ユースケース 変更案 CRC(Class Responsibility Collaborator)モデル 制約事項 取り決めモデル データフロー図(DFD) 本質/ビジネスユースケース 本質ユーザインターフェースプロトタイプ ユーザ機能 自由形式の図 フローチャート 用語集 Logical Data Model (LDM) ネットワーク図 オブジェクトロ
マイクロソフトにおけるアジャイル開発はこんな風に進められている － Publickey
マイクロソフトの代表的なソフトウェアは、数千人を超える開発者、数十万のソースコードファイル、数千回ものビルドを繰り返して開発される大規模なものだといわれています。 マイクロソフトのエバンジェリスト長沢智治氏は、こうした大規模な開発プロジェクトがマイクロソフト社内でどのように行われているのか、プロジェクトチームの組成から実施計画、進捗管理、バグレポートなど、その裏側を紹介するセッションをいくつかのイベントで行っています。 そこで明かされている内容は、パッケージソフトの開発だけでなく、SIerでの開発プロジェクトでも参考になる部分が多いと思われ、いつかレポート記事として紹介したいと思っていました。 今回、以前に行われたセッションビデオの存在を長沢氏ご本人から教えていただいたので、開発プロセスに関する部分にフォーカスした記事としてまとめました。 記事での内容は主に、「Microsoft Tech
問題の核心に切り込んでいく | システム設計日記
ドメインモデルのどこかに「問題の核心」がある。 問題領域の中の「核心」の問題領域が、Core Domain。 Domain の中の Domain ですね。 Core Domain を発見し、そこに切り込んでいくのは、もっとも優秀なメンバーたちにやらせる。 開発パワーを、問題領域の全体に、広く、薄く分散させるのは、失敗パターン。 ほんとうに役に立つソフトウェアを造るために、「問題の核心」を正しく捕らえ、そこに集中して、設計・実装し、リファクタリングして、洗練させていくこと。 Core Domain の特定と、設計・実装が、プロジェクト全体の成果を大きく左右する。 ・Core Domain とは何か？ ・どうやって発見するか？ ・どうやって表現するか？ ・Core 以外の扱い方は？ ．．． これが、 Domain-Driven Design(DDD) 15章 "Distillation"(抽出
ドメインモデルに関して - ひたすらプログラミング日記
ドメインモデリング能力を鍛える - じゅんいち☆かとうの技術日誌 ドメインモデルに対する日米の温度差 | Ouobpo 上記の素晴らしいエントリーを読んで個人的に思ったことをつらつら書いてみようかなと。 個人的に日本でドメインモデルが主流にならない理由の1つとしてアジャイル開発プロセス（XP、スクラム、リーン等）の普及度合が低いというのも大きな理由の1つなのではと最近よく感じています。なぜならMartin Fowler、Kent Beck、Eric EvansやDavid Tomasらは彼らが執筆した本の中でインクリメンタルであり進化的な設計を推奨し、テストケースとリファクタリングを行うことで洗練されたクラス設計が出来上がると述べています。そして、それらの工程（テスト、リファクタリング、進化的設計等）はアジャイル開発ではほぼ必須と言っていいプラクティスです。 対してウォーターフォール開発で
QCon Tokyo 2009(4/9,10) と Agile Japan 2009(4/22)：An Agile Way：オルタナティブ・ブログ
4月には私がホストする大きなイベントが２つあります。 QCon Tokyo 2009(4/9,10) と Agile Japan 2009(4/22) です。 QCon では、ぼくは 4/10の「アジャイル」トラックのホストになっていて、そこで自分自身も話をしますし、木下さんに『アート・オブ・アジャイルデベロップメント』の話をしてもらったり、Henrik Kniberg に『Scrum and XP from the trenches』の話をしてもらったりする予定です。QCon 全体では、Martin Folwer やまつもとさん、丸山先生、Rod Johnson などの著名人がいて、技術的な興味とエンジニア色が強いセミナーになっています。私も、「プロジェクトファシリテーション」すでに、9x 回目になりますが、再度やります。 Agile Japan 2009 では、違うアプローチをしていま
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
アジャイルに関する FAQ - CA Agile Central - CA Technologies Documentation
その一方で、ウォーターフォールの現場にて開発者が出来ること
アジャイルプロセス協議会