www.slideshare.net
[HTML5 Conference] ウェブのための次世代決済法 - Google スライド
Web updates 2017 from dynamis
www.slideshare.net
アジャイルのメモ
www.slideshare.net
【技術翻訳】モノリシック・プラットフォームが時代遅れな２５の理由 - Qiita
マイクロサービスの運用について考えたこと -- Think Abstract
みんなアジャイルに期待しすぎなんだよ。面倒なことは面倒なままだし、ちゃんとしないといけないことはちゃんとすべき。むしろ、エンプラなんてそうじゃないと困る。ただし、仕様を先に全て決めるという無理ゲーからは解放してくれる。
— 鈴木雄介/Yusuke SUZUKI (@yusuke_arclamp) November 24, 2017
WFからアジャイルへの転換で相談を受けることがあるけど、大抵のお悩みはプロセスの問題ではなくて、その会社の組織やルールの問題。で、そうであるならアジャイルに転換しても解決できません。むしろ、転換を機会にどうするのかを考えないと。
— 鈴木雄介/Yusuke SUZUKI (@yusuke_arclamp) November 22, 2017
「スピードを上げるべきは開発速度ではなく、提供サイクルです」と伝えている。顧客からフィードバックを得て、企画して、開発して、提供するの一連のスピードをあげる。だから、開発プロセスだけではなく意思決定プロセスや運用プロセスまで関係する。ITサービス提供を企業活動にする。
— 鈴木雄介/Yusuke SUZUKI (@yusuke_arclamp) September 8, 2017
microservicesはWF型の再構築に向かない。儲からない機能は分けなくていいし、できれば触りたくもない。いかに既存資産を活用しながら分離を進めるか。それば「microservices化」。だから、今日からでも始められる。始められない理由があるなら、それが課題。
— 鈴木雄介/Yusuke SUZUKI (@yusuke_arclamp) September 8, 2017
microservicesは「提供サイクルをあげて金が儲かる機能を、他の機能から疎結合化する」ということ。サービスの分割点の決定はビジネス部門がする。エンジニアは、いかに分けるか、なにが制約かを提示する。そして両者で合意する。そんだけ。金が儲かるから分けるのだよ。
— 鈴木雄介/Yusuke SUZUKI (@yusuke_arclamp) September 8, 2017
会社の意思決定システムと開発プロセスは紐ついている。「事業部門起案でROI見ながら決裁する」なら、どうしても開発は計画主導型に。調整主導型にしたいなら枠でエンジニアをおさえておいて、都度内容を確定してから確認決裁を取る。2つの使い分けが大事。
— 鈴木雄介/Yusuke SUZUKI (@yusuke_arclamp) September 8, 2017
「パッケージかスクラッチか」という迷い方なのかな。戦略的なところはアジャイルでスクラッチでやればいいし、標準的ならウォーターフォールでパッケージ中心にやればいいし、それらを連携させて企業全体として成果をあげていく、というのがベースなのでは。
— 鈴木雄介/Yusuke SUZUKI (@yusuke_arclamp) August 25, 2017
マイクロサービスっていう言葉よりも、そのベースになっているインフラ自動化、非同期メッセージングなどの疎結合連携、認証やログ基盤などのプラットフォーム、OS/コンテナ/サーバレスといった多様な実行環境管理を理解すべき。いきなり「サービス分割がー」とか始めるから変になる
— 鈴木雄介/Yusuke SUZUKI (@yusuke_arclamp) June 8, 2017
サービスの分割単位は機能でも画面でもデータでもなくて「ドメイン」。ドメインとは「業務や利用観点で、システムに対する変更が発生する要因単位」であり、多くの場合は組織と利用者種別によって分割される。と、思ってる。
— 鈴木雄介/Yusuke SUZUKI (@yusuke_arclamp) April 11, 2017
マイクロサービスでは「アプリ内のクラス構造」ではなく「システム全体のインスタンス構成」から考える。「機能分割による設計上の変更容易性」よりも「非機能分割による稼働サービス上の変更容易性」から考える。
— 鈴木雄介/Yusuke SUZUKI (@yusuke_arclamp) April 20, 2017
www.slideshare.net
おじさんにも分かるITトレンド説明と日本のエンプラITの限界 - arclamp
真面目に考えれば、「変わらないための改修」を積極的にやれるようにしておかないと変わらないことすら難しいよな。
— なぎせ ゆうき (@nagise) June 11, 2019
結局、動作保証のための自動テスト体制の構築みたいなのが重要になる。
スクラムのメモ
スクラムの概要を1分で理解できるイラスト【2018版】 | Ryuzee.com
スクラムチームの成熟度モデルに関する基準の例がCCライセンスで公開されていたので、日本語化したものを共有します。元ネタは、https://t.co/lFsD9KDUf1 pic.twitter.com/v1HlDK3z1k
— Ryutaro YOSHIBA (@ryuzee) August 21, 2019
[翻訳] スクラムがアジア圏でうまくいかない4つの理由 - Scrum does not work here in Asia - Qiita
www.slideshare.net
チームビルディング？
https://www.slideshare.net/ArisaOgi/ss-79825397
ゆとりを創りながら生産性を劇的に向上させる
— Nakayama san (@nakayama_san) September 2, 2017
〜全体最適のマネジメント理論TOC〜をきいてきたメモー。 #AgPA pic.twitter.com/znWylpyUM7
Googleが提唱するデザインスプリントの日本企業による実践例。日本企業と言っても、最近のイケてるスタートアップではなく、伝統的な日本企業であるところが貴重。結論「日本企業こそやってみるべき」に同意。https://t.co/SncnNpUjHu #NewsPicks
— 及川卓也 / Takuya Oikawa (@takoratta) August 24, 2017
「ちゃんと反省してんのか？」だと、シュンとしてなきゃいけない感じだけど、「ちゃんとふりかえりしてんのか？」だと「あー、やらなきゃ！」と前向きにとらえられる感
— 高玉広和 (@takatama_jp) June 13, 2019
コーチング養成講座で教えてもらった「人の可能性を潰してしまう聴き方」。これ、恥ずかしながら半分以上当てはまってた。一方で、「最短・最速思考」を手放したコミュニケーションを実践するだけで半分ぐらいは防げるな、という気付きもあった。
— Daisuke Suga / Gaiax (@suga_neo) June 18, 2019
人の話を聴くって、簡単そうで本当に難しい。 pic.twitter.com/cW04id8a7W
そだなー。僕も最初はふりかえりでみんながお互いの良いところを見つけて恥ずかしがらずに共有できる場づくりから始めるかな。慣れてきたらTry出すようにして、その中から1個か2個だけ次のスプリントのタスクに入れてしまう。
— Mitsuyuki Shiiba (@bufferings) June 13, 2019
みんなでやるふりかえりが、事前にWebツールに書き込んでおいたやつを誰かが読むだけの場になってると、お通夜みたいになるし、そもそも意見が集まらない。その場で、付箋でみんなに書いてもらって、それをきっかけにして話をする場の方が好きだなぁって思うのであった。
— Mitsuyuki Shiiba (@bufferings) June 13, 2019
