SlideShare a Scribd company logo
それはYAGNIか?
それとも思考停止か?
kawasima
ビジネス目標に応じてプロセスを適切に使い分けることがされる土壌が
整いつつあるといっても過言ではない状況といえるようになってきた
Agile or die
SoE SoR
市場に速く出して、
改善を繰り返す
十分よく計画して、
安定したシステム運用を
実現する
ここ10年での変化
「市場に速く出して、改善を繰り返す」方の
システム設計
タイム・トゥ・マーケット
正解なんて誰にも
分からないんだから
速く出して速く失敗しよう
「とにかく動かせ」
「お便利フレームワーク使って早く作れ」
「YAGNIだYAGNIっ」
YAGNI
You ain’t gonna need it.
(どうせ必要ないって!)
覚えたら、つい使いたくなる甘美な響き
もともとはFeatureについての要/不要の話が
転じてDesignについても議論されるようになった
ビジネスの成長と共にゴールは切り替わっていく
とにかくスピード 品質・生産性
時間がかかる
工数がかかる
リリースするたび本番障害発生
ますますYAGNIの判定は重要に
「YAGNI = 設計をサボって良い」では断じてない
「あとでクリーンにすればいいよ。先に市場にだ
さなければ!」
開発者たちはそうやっていつもごまかす。だが、
あとでクリーンにすることはない。市場からのプ
レッシャーはとまらないからだ。
クリーンアーキテクチャ
設計のサボりとYAGNI
ログ・例外設計
インタフェース設計
管理画面
リカバリの自動化
バリデーション
基本はリスクマネジメント
(発生確率×流出コスト)
データが貯まら
ないと意味をな
さない機能
データのパージ
SEO対策 メッセージの
変更リロード機能
2種類の非YAGNI
①それ、そもそも後回しにできないよ。
②今やっとかないと後でやるにはコストがかかり
すぎる。
後者を対象に今日は話をします
アーキテクチャ設計にどれくらい時間をかけるか
には統計に基づいた研究がある
プロジェクトの時間
= 開発時間
+ アーキテクチャとリスク削減時間
+ やり直しの時間
Making Software, How Much Architecting Is Enough?
コード規模によって
パーセンテージは変わる
技術的負債をおさえるための
非YAGNI
①インタフェースを使いDetailを分離する
②必要になるまで状態をもたない/持つ箇所を限
定する
③(誰のためにのデザインかを明らかにして、分類しまとめる)
最速インタフェース設計
~じっくりドメイン設計する時間がなくともここだけはやっておけポイント~
①区分値,ステータスを属性にもつデータの塊
②開発体制の境界
• 開発体制が分かれるところにインタフェースを定義して並
行開発する
③レイヤの境界
• 大抵はフレームワークの仕事
• 引数をインタフェースにしてテスタビリティをあげる。
④ホットスポット
• 不具合が集中的に発生する箇所を抜き出してテストしたり、作り
直して実装置換するためにインタフェースを作る。
区分値,ステータスを属性にもつ
データの塊
テーブルの中に「〜区分」や「〜ステー
タス」を見つけたら、それ扱うクラスで
は、必ずインタフェース作っておく
【例題】会員の種別によって料金や
サービスメニューが異なる
区分はまず増減しがちなので
たとえ数が少なくてもインタフェースを用意する
実装が1つしかなくても
インタフェースが必要か?
https://softwareengineering.stackexchange.com/questions/159813/do-i-need-to-use-an-interface-when-only-one-class-will-ever-implement-it/
実装の数が問題なのではない
ステータスも同様
ステータスもつデータの設計は
こちらをどうぞ
https://speakerdeck.com/kawasima/lu-li-wochi-tudetafalseshe-ji
業務ルール
ETC割引の計算ロジックを実装します。
●
平日朝夕割引
– 平日「朝:6時〜9時」、「夕:17時〜20時」
– 地方部
– 当月の利用回数が5回〜9回 30%割引、10回以上 50%割引
●
休日割引
– 普通車、軽自動車等(二輪車)限定
– 土曜・日曜・祝日
– 地方部
– 30%割引
●
深夜割引
– すべての車種
– 毎日0〜4時
– 30%割引 https://github.com/kawasima/kata
【例題】ETC割引のルール実装
上記の業務ルールにしたがい、割引率を計算するインタフェー
スDiscountServiceを実装して下さい。
public interface DisountService {
public long calc(HighwayDrive drive);
}
走行記録はHighwayDriveクラスで表現さ
れ、DiscountService#calcに渡されるものとします。 ま
た、割引率はパーセンテージの正の整数で表現されます。
割引ルールのインタフェースを以下のように定義し
各ルールをインタフェースに沿って実装する。
業務ルールは、「適用判定」と
「適用計算」のメソッドを分ける
のがポイント
そうすることで、割引の計算はルールが増減、変更になっても変わる
ことはなくなる。
※この形は業務システムにおいて頻出なので、KATAトレーニングして
身につけましょう。
開発体制の境界インタフェース
目指すところが「リソース効率」か「フロー効率」かで、
実際に並行で開発するかを決める
依存関係
開発順序
レイヤ境界のインタフェース
ログイン機能
<<Interface>>
認証
AuthRequest
+authenticate(AuthRequest)
LDAP認証
+authenticate(AuthRequest)
実際にはインタフェースと実装の
パッケージングを分ける
ログイン機能
<<Interface>>
認証
AuthRequest
+authenticate(AuthRequest)
LDAP認証
+authenticate(AuthRequest)
レイヤ間の通信がHTTPになっても
考えは変わらない
ログイン機能
<<Interface>>
認証
AuthRequest
+authenticate(AuthRequest)
LDAP認証
+authenticate(AuthRequest)
OpenAPIによる
API仕様
<<Interface>>
認証
AuthRequest
+authenticate(AuthRequest)
仕様からインタフェースを生成
ホットスポットのインタフェース
●
変更が多い箇所には、不具合の発生確率も高まる。
●
変更が多い箇所には、技術的負債も溜まっていく。
(これは最初の段階では読めないことが多いので、
考えすぎるのはYAGNIです)
とある有名な句
「不具合に/テストを書いて/立ち向かう」
1.手元で不具合を再現させる
2.コードを注意深く調べ、不具合を発生させている最小の部分を絞り込む
3.最小レベルで不具合を再現させ、不具合が修正されたら通るような自動テストコー
ドを書く
4.書いたテストコードを実行し、落ちることを確認する
5.不具合を修正する
6.書いたテストコードが通ることを確認する
7.全てのテストを実行し、不具合修正が他の部分を壊していないことを確認する
8.不具合箇所をリファクタリングしてTestabilityとDisposabilityをあげておく
https://t-wada.hatenablog.jp/entry/debugging-tests
ホットスポットの見つけ方
同時に変更されるものが、あちこちに分散しているのはSRPに反する
状態(ステート)
●
更新は最小限に。
●
状態の更新の向きは一方向に。
●
状態をもつ箇所を切り出す。
●
途中の計算結果は必要になるまでもたない。
分解して考えてみよう
状態をもつ箇所を切り出す
https://github.com/kawasima/bouncr
例)認証状態をリバースプロキシレイヤで管理して、後ろのアプリケー
ションをステートレスにするBouncr
途中の計算結果を保存すると…
●
性能限界が早くきやすい
●
性能でないときの対策が取りづらい
●
最初からオーバーエンジニアリングになりがち
【例題】価値観マッチングシステムの設計
いろんな人に価値観のアンケートを取ります。
例えば以下のような設問です。それぞれ、1 (そうは思わない) 〜 5 (とてもそう思う)を付けても
らいます。
Q1. お年寄りは運転免許を返上すべき
Q2. ラッシュ時のベビーカーはたたんだほうが良い
Q3. コンビニは深夜の営業やめた方が良い
Q4. 洗濯は晴れた日にまとめてやりたい
Q5. 電車が目の前で行ってしまったらかなりカチンとくる
この回答の値の距離で、各人の相性を測ることとします。
たとえば、
Aさんの回答 (Q1, Q2, Q3, Q4, Q5) = (1,2,3,4,5)
Bさんの回答 (Q1, Q2, Q3, Q4, Q5) = (3,3,3,3,3)
のとき、二人の相性は 1 - (abs(1-3) + abs(2-3) + abs(3-3) + abs(4-3) +
abs(5-3)) / 20 = 70% です。
(20で割っているのは5問あって距離の最大値が1問あたり4だからです)
こういうモデル
それはYAGNIか? それとも思考停止か?
【例題】階層をもつメッセージ
親子それぞれで取得件数の
Limit定めたい
それはYAGNIか? それとも思考停止か?
SQL1発で処理するようにしておいて、遅くなってきた
ら、パーティショニング/シャーディングで対処するの
が開発ボリューム抑えながらスケールさせていく近道
さいごに
ここでお話した設計は技法(テクニック)を
知っているかどうかであって、やると
工数が爆増するものではないのがミソです。
YAGNIの顔をした思考停止を
やっつけましょう

More Related Content

What's hot (20)

ドメイン駆動設計 ( DDD ) をやってみよう
ドメイン駆動設計 ( DDD ) をやってみようドメイン駆動設計 ( DDD ) をやってみよう
ドメイン駆動設計 ( DDD ) をやってみよう
増田 亨
 
オブジェクト指向の設計と実装の学び方のコツ
オブジェクト指向の設計と実装の学び方のコツオブジェクト指向の設計と実装の学び方のコツ
オブジェクト指向の設計と実装の学び方のコツ
増田 亨
 
フロー効率性とリソース効率性について #xpjug
フロー効率性とリソース効率性について #xpjugフロー効率性とリソース効率性について #xpjug
フロー効率性とリソース効率性について #xpjug
Itsuki Kuroda
 
正しいものを正しくつくる
正しいものを正しくつくる正しいものを正しくつくる
正しいものを正しくつくる
toshihiro ichitani
 
世界一わかりやすいClean Architecture
世界一わかりやすいClean Architecture世界一わかりやすいClean Architecture
世界一わかりやすいClean Architecture
Atsushi Nakamura
 
DDDのモデリングとは何なのか、 そしてどうコードに落とすのか
DDDのモデリングとは何なのか、 そしてどうコードに落とすのかDDDのモデリングとは何なのか、 そしてどうコードに落とすのか
DDDのモデリングとは何なのか、 そしてどうコードに落とすのか
Koichiro Matsuoka
 
マイクロにしすぎた結果がこれだよ!
マイクロにしすぎた結果がこれだよ!マイクロにしすぎた結果がこれだよ!
マイクロにしすぎた結果がこれだよ!
mosa siru
 
JaSST Tokyo 2022 アジャイルソフトウェア開発への統計的品質管理の応用
JaSST Tokyo 2022 アジャイルソフトウェア開発への統計的品質管理の応用JaSST Tokyo 2022 アジャイルソフトウェア開発への統計的品質管理の応用
JaSST Tokyo 2022 アジャイルソフトウェア開発への統計的品質管理の応用
Akinori SAKATA
 
世界でいちばんわかりやすいドメイン駆動設計
世界でいちばんわかりやすいドメイン駆動設計世界でいちばんわかりやすいドメイン駆動設計
世界でいちばんわかりやすいドメイン駆動設計
増田 亨
 
PlaySQLAlchemy: SQLAlchemy入門
PlaySQLAlchemy: SQLAlchemy入門PlaySQLAlchemy: SQLAlchemy入門
PlaySQLAlchemy: SQLAlchemy入門
泰 増田
 
インフラエンジニアの綺麗で優しい手順書の書き方
インフラエンジニアの綺麗で優しい手順書の書き方インフラエンジニアの綺麗で優しい手順書の書き方
インフラエンジニアの綺麗で優しい手順書の書き方
Shohei Koyama
 
フロー効率性とリソース効率性、再入門 #devlove #devkan
フロー効率性とリソース効率性、再入門 #devlove #devkanフロー効率性とリソース効率性、再入門 #devlove #devkan
フロー効率性とリソース効率性、再入門 #devlove #devkan
Itsuki Kuroda
 
本当は恐ろしい分散システムの話
本当は恐ろしい分散システムの話本当は恐ろしい分散システムの話
本当は恐ろしい分散システムの話
Kumazaki Hiroki
 
ソーシャルゲームのためのデータベース設計
ソーシャルゲームのためのデータベース設計ソーシャルゲームのためのデータベース設計
ソーシャルゲームのためのデータベース設計
Yoshinori Matsunobu
 
BuildKitによる高速でセキュアなイメージビルド
BuildKitによる高速でセキュアなイメージビルドBuildKitによる高速でセキュアなイメージビルド
BuildKitによる高速でセキュアなイメージビルド
Akihiro Suda
 
webエンジニアのためのはじめてのredis
webエンジニアのためのはじめてのrediswebエンジニアのためのはじめてのredis
webエンジニアのためのはじめてのredis
nasa9084
 
Dapr × Kubernetes ではじめるポータブルなマイクロサービス(CloudNative Days Tokyo 2020講演資料)
Dapr × Kubernetes ではじめるポータブルなマイクロサービス(CloudNative Days Tokyo 2020講演資料)Dapr × Kubernetes ではじめるポータブルなマイクロサービス(CloudNative Days Tokyo 2020講演資料)
Dapr × Kubernetes ではじめるポータブルなマイクロサービス(CloudNative Days Tokyo 2020講演資料)
NTT DATA Technology & Innovation
 
振り返り(アジャイルレトロスペクティブズ)
振り返り(アジャイルレトロスペクティブズ)振り返り(アジャイルレトロスペクティブズ)
振り返り(アジャイルレトロスペクティブズ)
Keisuke Tameyasu
 
Dockerからcontainerdへの移行
Dockerからcontainerdへの移行Dockerからcontainerdへの移行
Dockerからcontainerdへの移行
Kohei Tokunaga
 
実運用して分かったRabbit MQの良いところ・気をつけること #jjug
実運用して分かったRabbit MQの良いところ・気をつけること #jjug実運用して分かったRabbit MQの良いところ・気をつけること #jjug
実運用して分かったRabbit MQの良いところ・気をつけること #jjug
Yahoo!デベロッパーネットワーク
 
ドメイン駆動設計 ( DDD ) をやってみよう
ドメイン駆動設計 ( DDD ) をやってみようドメイン駆動設計 ( DDD ) をやってみよう
ドメイン駆動設計 ( DDD ) をやってみよう
増田 亨
 
オブジェクト指向の設計と実装の学び方のコツ
オブジェクト指向の設計と実装の学び方のコツオブジェクト指向の設計と実装の学び方のコツ
オブジェクト指向の設計と実装の学び方のコツ
増田 亨
 
フロー効率性とリソース効率性について #xpjug
フロー効率性とリソース効率性について #xpjugフロー効率性とリソース効率性について #xpjug
フロー効率性とリソース効率性について #xpjug
Itsuki Kuroda
 
正しいものを正しくつくる
正しいものを正しくつくる正しいものを正しくつくる
正しいものを正しくつくる
toshihiro ichitani
 
世界一わかりやすいClean Architecture
世界一わかりやすいClean Architecture世界一わかりやすいClean Architecture
世界一わかりやすいClean Architecture
Atsushi Nakamura
 
DDDのモデリングとは何なのか、 そしてどうコードに落とすのか
DDDのモデリングとは何なのか、 そしてどうコードに落とすのかDDDのモデリングとは何なのか、 そしてどうコードに落とすのか
DDDのモデリングとは何なのか、 そしてどうコードに落とすのか
Koichiro Matsuoka
 
マイクロにしすぎた結果がこれだよ!
マイクロにしすぎた結果がこれだよ!マイクロにしすぎた結果がこれだよ!
マイクロにしすぎた結果がこれだよ!
mosa siru
 
JaSST Tokyo 2022 アジャイルソフトウェア開発への統計的品質管理の応用
JaSST Tokyo 2022 アジャイルソフトウェア開発への統計的品質管理の応用JaSST Tokyo 2022 アジャイルソフトウェア開発への統計的品質管理の応用
JaSST Tokyo 2022 アジャイルソフトウェア開発への統計的品質管理の応用
Akinori SAKATA
 
世界でいちばんわかりやすいドメイン駆動設計
世界でいちばんわかりやすいドメイン駆動設計世界でいちばんわかりやすいドメイン駆動設計
世界でいちばんわかりやすいドメイン駆動設計
増田 亨
 
PlaySQLAlchemy: SQLAlchemy入門
PlaySQLAlchemy: SQLAlchemy入門PlaySQLAlchemy: SQLAlchemy入門
PlaySQLAlchemy: SQLAlchemy入門
泰 増田
 
インフラエンジニアの綺麗で優しい手順書の書き方
インフラエンジニアの綺麗で優しい手順書の書き方インフラエンジニアの綺麗で優しい手順書の書き方
インフラエンジニアの綺麗で優しい手順書の書き方
Shohei Koyama
 
フロー効率性とリソース効率性、再入門 #devlove #devkan
フロー効率性とリソース効率性、再入門 #devlove #devkanフロー効率性とリソース効率性、再入門 #devlove #devkan
フロー効率性とリソース効率性、再入門 #devlove #devkan
Itsuki Kuroda
 
本当は恐ろしい分散システムの話
本当は恐ろしい分散システムの話本当は恐ろしい分散システムの話
本当は恐ろしい分散システムの話
Kumazaki Hiroki
 
ソーシャルゲームのためのデータベース設計
ソーシャルゲームのためのデータベース設計ソーシャルゲームのためのデータベース設計
ソーシャルゲームのためのデータベース設計
Yoshinori Matsunobu
 
BuildKitによる高速でセキュアなイメージビルド
BuildKitによる高速でセキュアなイメージビルドBuildKitによる高速でセキュアなイメージビルド
BuildKitによる高速でセキュアなイメージビルド
Akihiro Suda
 
webエンジニアのためのはじめてのredis
webエンジニアのためのはじめてのrediswebエンジニアのためのはじめてのredis
webエンジニアのためのはじめてのredis
nasa9084
 
Dapr × Kubernetes ではじめるポータブルなマイクロサービス(CloudNative Days Tokyo 2020講演資料)
Dapr × Kubernetes ではじめるポータブルなマイクロサービス(CloudNative Days Tokyo 2020講演資料)Dapr × Kubernetes ではじめるポータブルなマイクロサービス(CloudNative Days Tokyo 2020講演資料)
Dapr × Kubernetes ではじめるポータブルなマイクロサービス(CloudNative Days Tokyo 2020講演資料)
NTT DATA Technology & Innovation
 
振り返り(アジャイルレトロスペクティブズ)
振り返り(アジャイルレトロスペクティブズ)振り返り(アジャイルレトロスペクティブズ)
振り返り(アジャイルレトロスペクティブズ)
Keisuke Tameyasu
 
Dockerからcontainerdへの移行
Dockerからcontainerdへの移行Dockerからcontainerdへの移行
Dockerからcontainerdへの移行
Kohei Tokunaga
 
実運用して分かったRabbit MQの良いところ・気をつけること #jjug
実運用して分かったRabbit MQの良いところ・気をつけること #jjug実運用して分かったRabbit MQの良いところ・気をつけること #jjug
実運用して分かったRabbit MQの良いところ・気をつけること #jjug
Yahoo!デベロッパーネットワーク
 

Similar to それはYAGNIか? それとも思考停止か? (19)

Digital Business and Agile
Digital Business and AgileDigital Business and Agile
Digital Business and Agile
Kenji Hiranabe
 
アジャイル開発の現在・過去・未来~今を知り、源流を訪ね、先を見据える~
アジャイル開発の現在・過去・未来~今を知り、源流を訪ね、先を見据える~アジャイル開発の現在・過去・未来~今を知り、源流を訪ね、先を見据える~
アジャイル開発の現在・過去・未来~今を知り、源流を訪ね、先を見据える~
Kenji Hiranabe
 
Dev love関西「エンジニア×営業」営業マン8年目の本音
Dev love関西「エンジニア×営業」営業マン8年目の本音Dev love関西「エンジニア×営業」営業マン8年目の本音
Dev love関西「エンジニア×営業」営業マン8年目の本音
Tetsuya Okubo
 
ふつうの受託開発チームのつくりかた
ふつうの受託開発チームのつくりかたふつうの受託開発チームのつくりかた
ふつうの受託開発チームのつくりかた
Yoshitaka Kawashima
 
どうすれば小さなチームでも大きな成果を出せるのか
どうすれば小さなチームでも大きな成果を出せるのかどうすれば小さなチームでも大きな成果を出せるのか
どうすれば小さなチームでも大きな成果を出せるのか
Yoshihito Kuranuki
 
AgileShimane始動!! in OSC2011Shimane
AgileShimane始動!! in OSC2011ShimaneAgileShimane始動!! in OSC2011Shimane
AgileShimane始動!! in OSC2011Shimane
Ryuichi Tsuruhara
 
SQiP2016 SIG8
SQiP2016 SIG8SQiP2016 SIG8
SQiP2016 SIG8
Masanori Kaneko
 
OutSystems Workflow Builder
OutSystems Workflow BuilderOutSystems Workflow Builder
OutSystems Workflow Builder
Tetsuo Ajima
 
今日から始めるアジャイル開発
今日から始めるアジャイル開発今日から始めるアジャイル開発
今日から始めるアジャイル開発
Takashi Takebayashi
 
re:日暮里アジャイル
re:日暮里アジャイルre:日暮里アジャイル
re:日暮里アジャイル
Shingo Sato
 
Agile Scrum at Knowledge Forum 2020
Agile Scrum at Knowledge Forum 2020Agile Scrum at Knowledge Forum 2020
Agile Scrum at Knowledge Forum 2020
Kenji Hiranabe
 
Agile Overview In Ono
Agile Overview In OnoAgile Overview In Ono
Agile Overview In Ono
Kenji Hiranabe
 
アート・オブ・アジャイル デベロップメント ~組織を成功に導くエクストリームプログラミングの道~
アート・オブ・アジャイル デベロップメント ~組織を成功に導くエクストリームプログラミングの道~アート・オブ・アジャイル デベロップメント ~組織を成功に導くエクストリームプログラミングの道~
アート・オブ・アジャイル デベロップメント ~組織を成功に導くエクストリームプログラミングの道~
Fumihiko Kinoshita
 
Agile2010とは何だったのか
Agile2010とは何だったのかAgile2010とは何だったのか
Agile2010とは何だったのか
Dai FUJIHARA
 
130216gis商談における営業プロセスの解説
130216gis商談における営業プロセスの解説130216gis商談における営業プロセスの解説
130216gis商談における営業プロセスの解説
三紀夫 玉置
 
第7回SIA研究会(例会)プレゼン資料 油野様
第7回SIA研究会(例会)プレゼン資料 油野様第7回SIA研究会(例会)プレゼン資料 油野様
第7回SIA研究会(例会)プレゼン資料 油野様
Tae Yoshida
 
Introduction to Agile - how business and engineer team up
Introduction to Agile - how business and engineer team upIntroduction to Agile - how business and engineer team up
Introduction to Agile - how business and engineer team up
Kenji Hiranabe
 
第11回SIA例会プレゼン資料
第11回SIA例会プレゼン資料第11回SIA例会プレゼン資料
第11回SIA例会プレゼン資料
Tae Yoshida
 
アジャイル入門
アジャイル入門アジャイル入門
アジャイル入門
Kenji Morita
 
Digital Business and Agile
Digital Business and AgileDigital Business and Agile
Digital Business and Agile
Kenji Hiranabe
 
アジャイル開発の現在・過去・未来~今を知り、源流を訪ね、先を見据える~
アジャイル開発の現在・過去・未来~今を知り、源流を訪ね、先を見据える~アジャイル開発の現在・過去・未来~今を知り、源流を訪ね、先を見据える~
アジャイル開発の現在・過去・未来~今を知り、源流を訪ね、先を見据える~
Kenji Hiranabe
 
Dev love関西「エンジニア×営業」営業マン8年目の本音
Dev love関西「エンジニア×営業」営業マン8年目の本音Dev love関西「エンジニア×営業」営業マン8年目の本音
Dev love関西「エンジニア×営業」営業マン8年目の本音
Tetsuya Okubo
 
ふつうの受託開発チームのつくりかた
ふつうの受託開発チームのつくりかたふつうの受託開発チームのつくりかた
ふつうの受託開発チームのつくりかた
Yoshitaka Kawashima
 
どうすれば小さなチームでも大きな成果を出せるのか
どうすれば小さなチームでも大きな成果を出せるのかどうすれば小さなチームでも大きな成果を出せるのか
どうすれば小さなチームでも大きな成果を出せるのか
Yoshihito Kuranuki
 
AgileShimane始動!! in OSC2011Shimane
AgileShimane始動!! in OSC2011ShimaneAgileShimane始動!! in OSC2011Shimane
AgileShimane始動!! in OSC2011Shimane
Ryuichi Tsuruhara
 
OutSystems Workflow Builder
OutSystems Workflow BuilderOutSystems Workflow Builder
OutSystems Workflow Builder
Tetsuo Ajima
 
今日から始めるアジャイル開発
今日から始めるアジャイル開発今日から始めるアジャイル開発
今日から始めるアジャイル開発
Takashi Takebayashi
 
re:日暮里アジャイル
re:日暮里アジャイルre:日暮里アジャイル
re:日暮里アジャイル
Shingo Sato
 
Agile Scrum at Knowledge Forum 2020
Agile Scrum at Knowledge Forum 2020Agile Scrum at Knowledge Forum 2020
Agile Scrum at Knowledge Forum 2020
Kenji Hiranabe
 
アート・オブ・アジャイル デベロップメント ~組織を成功に導くエクストリームプログラミングの道~
アート・オブ・アジャイル デベロップメント ~組織を成功に導くエクストリームプログラミングの道~アート・オブ・アジャイル デベロップメント ~組織を成功に導くエクストリームプログラミングの道~
アート・オブ・アジャイル デベロップメント ~組織を成功に導くエクストリームプログラミングの道~
Fumihiko Kinoshita
 
Agile2010とは何だったのか
Agile2010とは何だったのかAgile2010とは何だったのか
Agile2010とは何だったのか
Dai FUJIHARA
 
130216gis商談における営業プロセスの解説
130216gis商談における営業プロセスの解説130216gis商談における営業プロセスの解説
130216gis商談における営業プロセスの解説
三紀夫 玉置
 
第7回SIA研究会(例会)プレゼン資料 油野様
第7回SIA研究会(例会)プレゼン資料 油野様第7回SIA研究会(例会)プレゼン資料 油野様
第7回SIA研究会(例会)プレゼン資料 油野様
Tae Yoshida
 
Introduction to Agile - how business and engineer team up
Introduction to Agile - how business and engineer team upIntroduction to Agile - how business and engineer team up
Introduction to Agile - how business and engineer team up
Kenji Hiranabe
 
第11回SIA例会プレゼン資料
第11回SIA例会プレゼン資料第11回SIA例会プレゼン資料
第11回SIA例会プレゼン資料
Tae Yoshida
 
アジャイル入門
アジャイル入門アジャイル入門
アジャイル入門
Kenji Morita
 

More from Yoshitaka Kawashima (20)

Grokking Simplicity探訪
Grokking Simplicity探訪Grokking Simplicity探訪
Grokking Simplicity探訪
Yoshitaka Kawashima
 
ブルックスのいう銀の弾丸とは何か?
ブルックスのいう銀の弾丸とは何か?ブルックスのいう銀の弾丸とは何か?
ブルックスのいう銀の弾丸とは何か?
Yoshitaka Kawashima
 
Are Design Patterns Dead?
Are Design Patterns Dead?Are Design Patterns Dead?
Are Design Patterns Dead?
Yoshitaka Kawashima
 
強いて言えば「集約どう実装するのかな、を考える」な話
強いて言えば「集約どう実装するのかな、を考える」な話強いて言えば「集約どう実装するのかな、を考える」な話
強いて言えば「集約どう実装するのかな、を考える」な話
Yoshitaka Kawashima
 
ソフトウェアにおける 複雑さとは何なのか?
ソフトウェアにおける 複雑さとは何なのか?ソフトウェアにおける 複雑さとは何なのか?
ソフトウェアにおける 複雑さとは何なのか?
Yoshitaka Kawashima
 
Tackling Complexity
Tackling ComplexityTackling Complexity
Tackling Complexity
Yoshitaka Kawashima
 
ソフトウェア設計における 意思決定とそのレビューの秘訣
ソフトウェア設計における 意思決定とそのレビューの秘訣ソフトウェア設計における 意思決定とそのレビューの秘訣
ソフトウェア設計における 意思決定とそのレビューの秘訣
Yoshitaka Kawashima
 
本番障害に至る病
本番障害に至る病本番障害に至る病
本番障害に至る病
Yoshitaka Kawashima
 
システムダウンのひみつ
システムダウンのひみつシステムダウンのひみつ
システムダウンのひみつ
Yoshitaka Kawashima
 
Mavenの真実とウソ
Mavenの真実とウソMavenの真実とウソ
Mavenの真実とウソ
Yoshitaka Kawashima
 
アンチフラジャイルの世界
アンチフラジャイルの世界アンチフラジャイルの世界
アンチフラジャイルの世界
Yoshitaka Kawashima
 
Atomic Architecture
Atomic ArchitectureAtomic Architecture
Atomic Architecture
Yoshitaka Kawashima
 
思考停止しないアーキテクチャ設計 ➖ JJUG CCC 2018 Fall
思考停止しないアーキテクチャ設計 ➖ JJUG CCC 2018 Fall思考停止しないアーキテクチャ設計 ➖ JJUG CCC 2018 Fall
思考停止しないアーキテクチャ設計 ➖ JJUG CCC 2018 Fall
Yoshitaka Kawashima
 
ウォーターフォールとアジャイルのフェアな比較
ウォーターフォールとアジャイルのフェアな比較ウォーターフォールとアジャイルのフェアな比較
ウォーターフォールとアジャイルのフェアな比較
Yoshitaka Kawashima
 
How to find tech books
How to find tech booksHow to find tech books
How to find tech books
Yoshitaka Kawashima
 
Antifragile Java - Java Day Tokyo 2017 D1-E1
Antifragile Java - Java Day Tokyo 2017 D1-E1Antifragile Java - Java Day Tokyo 2017 D1-E1
Antifragile Java - Java Day Tokyo 2017 D1-E1
Yoshitaka Kawashima
 
たとえ日本人同士でも必要な異文化理解力
たとえ日本人同士でも必要な異文化理解力たとえ日本人同士でも必要な異文化理解力
たとえ日本人同士でも必要な異文化理解力
Yoshitaka Kawashima
 
SIerにとっての越境 @ DevLOVE 199
SIerにとっての越境 @ DevLOVE 199SIerにとっての越境 @ DevLOVE 199
SIerにとっての越境 @ DevLOVE 199
Yoshitaka Kawashima
 
なぜデータモデリングが重要なのか?
なぜデータモデリングが重要なのか?なぜデータモデリングが重要なのか?
なぜデータモデリングが重要なのか?
Yoshitaka Kawashima
 
Antifragile Clojure
Antifragile ClojureAntifragile Clojure
Antifragile Clojure
Yoshitaka Kawashima
 
ブルックスのいう銀の弾丸とは何か?
ブルックスのいう銀の弾丸とは何か?ブルックスのいう銀の弾丸とは何か?
ブルックスのいう銀の弾丸とは何か?
Yoshitaka Kawashima
 
強いて言えば「集約どう実装するのかな、を考える」な話
強いて言えば「集約どう実装するのかな、を考える」な話強いて言えば「集約どう実装するのかな、を考える」な話
強いて言えば「集約どう実装するのかな、を考える」な話
Yoshitaka Kawashima
 
ソフトウェアにおける 複雑さとは何なのか?
ソフトウェアにおける 複雑さとは何なのか?ソフトウェアにおける 複雑さとは何なのか?
ソフトウェアにおける 複雑さとは何なのか?
Yoshitaka Kawashima
 
ソフトウェア設計における 意思決定とそのレビューの秘訣
ソフトウェア設計における 意思決定とそのレビューの秘訣ソフトウェア設計における 意思決定とそのレビューの秘訣
ソフトウェア設計における 意思決定とそのレビューの秘訣
Yoshitaka Kawashima
 
システムダウンのひみつ
システムダウンのひみつシステムダウンのひみつ
システムダウンのひみつ
Yoshitaka Kawashima
 
アンチフラジャイルの世界
アンチフラジャイルの世界アンチフラジャイルの世界
アンチフラジャイルの世界
Yoshitaka Kawashima
 
思考停止しないアーキテクチャ設計 ➖ JJUG CCC 2018 Fall
思考停止しないアーキテクチャ設計 ➖ JJUG CCC 2018 Fall思考停止しないアーキテクチャ設計 ➖ JJUG CCC 2018 Fall
思考停止しないアーキテクチャ設計 ➖ JJUG CCC 2018 Fall
Yoshitaka Kawashima
 
ウォーターフォールとアジャイルのフェアな比較
ウォーターフォールとアジャイルのフェアな比較ウォーターフォールとアジャイルのフェアな比較
ウォーターフォールとアジャイルのフェアな比較
Yoshitaka Kawashima
 
Antifragile Java - Java Day Tokyo 2017 D1-E1
Antifragile Java - Java Day Tokyo 2017 D1-E1Antifragile Java - Java Day Tokyo 2017 D1-E1
Antifragile Java - Java Day Tokyo 2017 D1-E1
Yoshitaka Kawashima
 
たとえ日本人同士でも必要な異文化理解力
たとえ日本人同士でも必要な異文化理解力たとえ日本人同士でも必要な異文化理解力
たとえ日本人同士でも必要な異文化理解力
Yoshitaka Kawashima
 
SIerにとっての越境 @ DevLOVE 199
SIerにとっての越境 @ DevLOVE 199SIerにとっての越境 @ DevLOVE 199
SIerにとっての越境 @ DevLOVE 199
Yoshitaka Kawashima
 
なぜデータモデリングが重要なのか?
なぜデータモデリングが重要なのか?なぜデータモデリングが重要なのか?
なぜデータモデリングが重要なのか?
Yoshitaka Kawashima
 

それはYAGNIか? それとも思考停止か?