Recomendados
Recomendados
Más contenido relacionado
La actualidad más candente
La actualidad más candente (20)
Similar a Aj2016 toyama feedback
Similar a Aj2016 toyama feedback (20)
Aj2016 toyama feedback
- 2. 自己紹介 • もりかわ@hikaruworld • Toyama with Fukui • Developer • Frontend-Enginner • Has two child
- 3. Presented by
- 5. 私とアジャイル
- 6. セッション
- 7. 1. アジャイルなIoTプラットフォーム開発 2. 請負で企画・開発・運用・拡張まで担当するアジャイルチーム 3. 自社プロダクト開発現場でのアジャイルなプロジェクト運営記録 4. まだテスト期間とかつくっているの？ ～アジャイルな開発におけるテストとの付き合い方～ 5. 文化の壁をぶち壊せ！日本でも出来る本物の DevOps ジャーニー！ 6. SIerから「はてな」へ／「エンジニア」から「社長」まで 役割が変わる中で大切にしたこと・考えたこと 7. アジャイルと言わないエンタープライズアジャイル導入
- 8. 1. アジャイルなIoTプラットフォーム開発 2. 請負で企画・開発・運用・拡張まで担当するアジャイルチーム 3. 自社プロダクト開発現場でのアジャイルなプロジェクト運営記録 4. まだテスト期間とかつくっているの？ ～アジャイルな開発におけるテストとの付き合い方～ 5. 文化の壁をぶち壊せ！日本でも出来る本物の DevOps ジャーニー！ 6. SIerから「はてな」へ／「エンジニア」から「社長」まで 役割が変わる中で大切にしたこと・考えたこと 7. アジャイルと言わないエンタープライズアジャイル導入
- 9. 1. アジャイルなIoTプラットフォーム開発 2. 請負で企画・開発・運用・拡張まで担当するアジャイルチーム 3. 自社プロダクト開発現場でのアジャイルなプロジェクト運営記録 4. まだテスト期間とかつくっているの？ ～アジャイルな開発におけるテストとの付き合い方～ 5. 文化の壁をぶち壊せ！日本でも出来る本物の DevOps ジャーニー！ 6. SIerから「はてな」へ／「エンジニア」から「社長」まで 役割が変わる中で大切にしたこと・考えたこと 7. アジャイルと言わないエンタープライズアジャイル導入
- 10. 請負で企画・開発・運用・拡張まで 担当するアジャイルチーム • 準委任でプロトタイプ => ウォーターフォールで請負 • 技術は変化していく、ベストを選んでも変わる • VersionUpで時間がかかるものは品質が低い • スキルマップはチームの特有のもの 役割のイメージ共有できることが大切 • メインチームとサブチームで役割分担
- 11. 1. アジャイルなIoTプラットフォーム開発 2. 請負で企画・開発・運用・拡張まで担当するアジャイルチーム 3. 自社プロダクト開発現場でのアジャイルなプロジェクト運営記録 4. まだテスト期間とかつくっているの？ ～アジャイルな開発におけるテストとの付き合い方～ 5. 文化の壁をぶち壊せ！日本でも出来る本物の DevOps ジャーニー！ 6. SIerから「はてな」へ／「エンジニア」から「社長」まで 役割が変わる中で大切にしたこと・考えたこと 7. アジャイルと言わないエンタープライズアジャイル導入
- 13. 1. アジャイルなIoTプラットフォーム開発 2. 請負で企画・開発・運用・拡張まで担当するアジャイルチーム 3. 自社プロダクト開発現場でのアジャイルなプロジェクト運営記録 4. まだテスト期間とかつくっているの？ ～アジャイルな開発におけるテストとの付き合い方～ 5. 文化の壁をぶち壊せ！日本でも出来る本物の DevOps ジャーニー！ 6. SIerから「はてな」へ／「エンジニア」から「社長」まで 役割が変わる中で大切にしたこと・考えたこと 7. アジャイルと言わないエンタープライズアジャイル導入
- 14. まだテスト期間とかつくっているの？ ～アジャイルな開発におけるテストとの付き合い方～ • テスト完了まで本当の進捗はわからない • 学習の方法論をまとめたものがテスト • GitやCIなどツールを使うことで満足しない • コミュニケーションコストを低くしたい 「こんな感じにしておいて」でいいのが理想 • テストをしなくていいようにする • 手戻り20% => 5%に
- 15. 1. アジャイルなIoTプラットフォーム開発 2. 請負で企画・開発・運用・拡張まで担当するアジャイルチーム 3. 自社プロダクト開発現場でのアジャイルなプロジェクト運営記録 4. まだテスト期間とかつくっているの？ ～アジャイルな開発におけるテストとの付き合い方～ 5. 文化の壁をぶち壊せ！日本でも出来る本物の DevOps ジャーニー！ 6. SIerから「はてな」へ／「エンジニア」から「社長」まで 役割が変わる中で大切にしたこと・考えたこと 7. アジャイルと言わないエンタープライズアジャイル導入
- 16. 文化の壁をぶち壊せ！ 日本でも出来る本物の DevOps ジャーニー！ • リリース後のフィードバックが本番 • 生産性の秘密は物量 • 定期的にモニタリングして価値を測る • 手作業が安全という幻想 • 重要なことは少ない。ほとんどがノイズ • 残り続ける問題はシンプルにして考える • バグは発生するもの。すぐに修正するスタンス
- 17. 1. アジャイルなIoTプラットフォーム開発 2. 請負で企画・開発・運用・拡張まで担当するアジャイルチーム 3. 自社プロダクト開発現場でのアジャイルなプロジェクト運営記録 4. まだテスト期間とかつくっているの？ ～アジャイルな開発におけるテストとの付き合い方～ 5. 文化の壁をぶち壊せ！日本でも出来る本物の DevOps ジャーニー！ 6. SIerから「はてな」へ／「エンジニア」から「社長」まで 役割が変わる中で大切にしたこと・考えたこと 7. アジャイルと言わないエンタープライズアジャイル導入
- 18. SIerから「はてな」へ／「エンジニア」から 「社長」まで役割が変わる中で 大切にしたこと・考えたこと • プロマネから社長までの考え方 • 技術的負債は借金。借りたら返す。 • 手法にフォーカスするのは簡単。 ユーザーにサービスを届けることが大切。 • パフォーマンス100%で考えない • いつもは80%でいいが100%の準備をする。 • 迷った場合は積極的な方を選ぶ
- 19. 1. アジャイルなIoTプラットフォーム開発 2. 請負で企画・開発・運用・拡張まで担当するアジャイルチーム 3. 自社プロダクト開発現場でのアジャイルなプロジェクト運営記録 4. まだテスト期間とかつくっているの？ ～アジャイルな開発におけるテストとの付き合い方～ 5. 文化の壁をぶち壊せ！日本でも出来る本物の DevOps ジャーニー！ 6. SIerから「はてな」へ／「エンジニア」から「社長」まで 役割が変わる中で大切にしたこと・考えたこと 7. アジャイルと言わないエンタープライズアジャイル導入
- 20. アジャイルと言わない エンタープライズアジャイル導入 • SIerのエンタープライズアジャイルの現実解 • 保守契約+３ヶ月定期リリースを作る • 「企業がITでビジネス成果をあげる」 ための必要最低限の期間 • 「システムを作る」ではなく「ビジネス成果を出す」 • 短期での具体化が長期方針の推進力となる • 組織（経営＋現場）をオーナーにすることが必要
- 21. まとめ
- 22. Be Lazy
- 24. ご清聴ありがとうございました。
Notas del editor
- AJ2016本会場のフィードバック
- 名前、住処、やっていることなどをかるく
- 会社の紹介を一瞬だけ
- * 客先常駐せずに受託や准委任でやる方法 * 規模感（１０名+半年で複数のプロジェクト) * 仕様変更は避けられないのでどのようにそのミスマッチを改善するか * お客さんが決めると言っても、決めるまでがすごく長くなる。 * 今日と明日で技術が変わっていくので、ベストを選んでもベストにならない。 正常系をベースに作って、異常系は簡単なものにする。 * プロトで全体の半分くらいを作ってから、残り半分をウォーターフォールに落とし込んで作業する。 * お客さんの持っている大まかなスケジュール感をコミットする。 * 最終的にはウォーターフォールにするが最初のプロト開発で見積もりの概要を把握する。 * プロトは準委任、ウォーターフォールは請負にする。 こうすることで、瑕疵担保や完成責任を負うことでユーザーに安心感を与える。 * １回目のリリースは通過点 * 次期開発に多くの時間がかかる => システム品質が低いと言える。 * 設計書を引き継ぐだけではなく、ソースコードの品質を維持することが品質保障が高いといえる。 複数プロジェクトの山に合わせてメンバー調整をする。 * メインチームとサブチームを作る 交渉者、管理者、応援者、アーキテクト、プログラマ、育成者、UIデザイナ、インフラ、社内基盤 プログラマにはプログラミングとテストが含まれる。 チームは人。 あげてもらったタスクから、どのような仕事をしているか、だから何ができるか考える。 JavaレベルXXとかやっても意味ないよ! 汎用的なものを見たいのではなく、チームの状況を見るためのスキルマップ。 チーム内で、役割のイメージが共有できることが大切。 L1 新人 L2 一般 L3 サブリーダー(決定権なし) L4 メインリーダ(決定権あり) L5 マスター Ex)某社に限る。 スキルマップのスキルはチーム特有のもの。
- 自社プロダクト開発現場でのアジャイルなプロジェクト運営記録 --- こういうとこ来るとフツーにリモート参加前提的な話が多い。 リックソフトの話。 環境は全部アトラシアン。 テスト管理が便利だ。TestLinkとか知らなかったけど、こんなのあったんだな。 (そしてこのセッションあんまり面白くない) 基本的には２ヶ月に1回リリースらしい。 * リリースのリズムを作ることが大切。 * パッケージなのでリアクションがないとダメ。 (edited) (ウーム) * リモートワークでやり難くない? => チャットがあるので大丈夫。 => テストの再現確認はしんどいので、直接。 (WBSガントチャートは便利なんだけど、ちょい高いんだよね) Googleまで使ってるのか。すげぇな。 * グローバルの準備がかかったが、世界に向けて販売したらすごい売れてマーケットプレイスの上位になってすごい嬉しかった。 * ユーザーから翻訳協力があって、ドイツ語やスペイン語の翻訳をしてくれたのが嬉しい。 * チームでマーケティングもしてる。 * 海外だと市場が100倍ある。 (edited) * ユーザーフィードバックはすごく重要。プロダクトオーナーがサポートをすることが良かった? ユーザーとの位置が近くなる。 * 最近ライバルが増えている。 * 新たな問題も出てくる。 (edited) => こっそりレビュー依頼される、こっそりマージされる、こっそりリリースされる！ (ナニソレ怖い) => 新しいプロジェクトでこのような問題が増えている。
- アジャイルをやってたけど、なんかうまくいってない。 もう嫌だからやめたくなって、変えた。 その時のテストの話。 問題 => 白色終わらせるけど、時間がかかるテストや重要なテストが後回しにされる。 => ある類の品質が満たされない(本来こうあるべきだよねというやつ) => 解法は全員でテストする? 大事なトピックを考える。 いろんな議論をしたことによって、テスト期間が0になった話。 * リリース可能 => ストーリーが完了したタイイングでりリースできるように本気でやらないとダメだよね。 => じゃあ、なんでできないの？ => 問題を一つずつ潰していく * 学習 => ある範囲を効率よく学習の方法論をまとめたことがテストではないか。 => 誰の立場でどれだけの情報が欲しいかがテストでは? * オーナーシップ => バグは関心の低い作業(手を抜きたい作業)から生まれる。 => マネージャーやお客さんが簡単に見つかるバグがプログラマが見つけられない。 => お客さんとプログラマがお互いの方向を見てないからばらつきが出る。 => 全員が同じ方向を見れば気がつきやすくなる。 具体例(実践編) 最後にテストスプリントなるものがあって、最後にリリースのテストをしてた。 結果、開発工程の終盤になってバグッが見つかってリリースできない。 なぜ？ * テストが完了するまでは本当の進捗はわからん。 99%終わっても大体終わったとは言えない。 本当の進捗が見えなくなっている。 慣れた人でも結合テストで2週間くらいかかる。 => ストーリーごとにテストする。 => スプリントでコードだけではなくテストもレビューする。 探索的テスト セッション = 30分単位でテストする。 構造化するが、あまり複雑にしない。 テストしたい機能に対する期待する目的をかいて、さらにふりかえるってことか。 * テストで学習をする。 (edited) * ユーザーガイドをまず修正する。 * サンプルにも自動テストを書く * テスターをセーフティネットとして使ってしまうことがあるので、チームメンバー全員がテストする責任を持つ。 * 役割を固定しない。レビューなども固定しない。 * ドラマ仕立てでスプリントの設定をすることでチームメンバーでゴールを感情的に理解しやすい。 (なるほど) * バグを工程で分けない。特徴で分ける。 ってことを地道にやったら、手戻り工数が20% => 5%に。 * ツールを使うだけで満足してて、お客さんから言われたことをなんとなくマッピングして安心していたことがよくなかった。 * テスト期間を減らすためには、テストをしなくていいようにすることが大切。 *そもそもバグを埋め込みにくくすることが大切。 * チームのコミュニケーションコストを低くしたい。 * ドキュメントを書いたり、ホワイトボードに絵を描くんじゃくて、「こんな感じにしておいて」でいいのができるのが理想。
- 牛尾さんのDevOps * リリースは第一歩、そこからフィードバックをうけるのが本番。 * 本番からいかに学ぶか。 * お客さんの求めることをいかにやはくつるかがゴール。 * DevOpsの詳細はビデオ見てね。 アジャイルの導入事例 * 世界 => 95 日本 => 31% ただし日本の半分は野良。。 * 日本文化とアジャイルは合わない、なら西洋文化をインストールすればいい。 * アジャイルやDevOpsを学ぶ前に、関連する西洋文化を学べば導入はすごい早い。 * インターナショナルな人は生産性がめっちゃたかい。 * アメリカ:日本 = 100% : 62% * だから定時でかえってハッピー。 * といいつつアメリカは世界でもNO4くらい。 * 生産性の秘密は、優秀さや速さやなどではなく、物量が違う。 * 一つの価値を出すのに、アメリカで1でいいものが、日本では10必要になる。 海外カンファレンスに行ってレポートを書くとしたら。。。 * アメリカの場合は、絵を描いてコメント描いてお終い。せいぜい2時間 * 動画チェックしてレポート描いて録画して、powerpointに... =>そんなもん動画みればいい。 日本人は10個あったらそれをどうやってはやくやるか考えるが、アメリカでは１０のうち必要な１つのみをする。 `Be Lazy` いかに少なくするか、 少なくするが成果を最大に出すことを真剣に考える。 * 納期はそれほど重要ではない。 遅れた場合は、今回かかった時間を理解してフィードバックする。 * 重要なことは少なくてほとんどノイズ。 * 急がなくていい、定期的にモニタリングして改善して、バリューを図ることが大切。 (edited) — カラダメディカルさん * なんかうまくいってないけどうまくしたいのを改善した話。 (edited) * 会社の方針を変えるのは無理?品質も納期も全部大事。 * 社長に大事なことを聞いたら、意外に違った。 * 手作業が安全という幻想 * テスト報告書や、レビュー記録を作ってバグ発生時にそれ見て解決しますか? (そりゃしないけど、責任的な話が絡むと面倒だよね) * バグは発生するもの。出た速攻修正するというスタンスを取る (SGとかといっしょか) * リリースの承認を最後にやっても意味ない。 * そんなもんは最初の決済時にやれという話 => リリース直前でダメって言われてもどうしようもないでしょという話。 * リリースまでのリードタイムが 13 day => 3 day に。 * 残り続ける問題はシンプルにして考える。
- * 少年野球の監督とかすると頭の切り替えになるよ。 * ただ、３０で転職して７年後に社長になるのでキャリアパスは参考にならんよ。 (edited) * いわゆる島耕作。 * はてなに転職した時 => 顧客、あるいは顧客の顧客が何考えているかを考える。 => 自社のサービスを自分で使う。 => 硬い会社だと情報を共有するのはNGというケースがあるが、ナンセンスだからやめたほうがいいよ。 => 技術的負債は借金なので、必要に応じて借りて開発すればいいが、借金なので返す必要がある。 => 中庸であるようにする。片方にならない。 # ディレクターからプロデューサー * 半年後や一年後を考えて調整を行い、いつかいなくなるものとみなして調整する。 * 手法にフォーカスするのは実は簡単。そうじゃない。ユーザーさんにサービスを届けるのが大切。 * いい感じに目線を外に向けるようにする。 # プロデューサーから本部長 * 何してる人かわかんなかった。 * 開発者以外の話にも耳を傾けるようになった。 * 知らんことが増えてくるので、責任は自分が取って優秀なスタッフに丸投げする。現場主導。 * ただし、理解はするようにする。 # 本部長から社長 * 社長って何？？？？ => ぐぐった。 * 気をつけることは現場に直接介入しないこと。 * 社長はslackに入って色々眺めている。 * 社長が案を出したら社員に叱られてしまう。 * まだまだしんどい。 * 働く人の価値観を作って欲しいといわれ、はてなバリューズというのを作った。 (社長が突っ込まれる会社の雰囲気はいいね) * エンジニアだけが評価されるというのはあんまり未来がないかなともって何かの技術をもつ集団ということを定義した。 * はてなも受託開発してる。 * 単純な受託ではなく、サービスの企画から運用までやるというやりかた。 * 自社のサービスと同じスキームで考える。 * いつもは80%でいいけど、100%出せるように準備はする。 * パフォーマンス100%で考えてはいけない。波があるので油断しないこと。 (edited) * 迷った場合は積極的な方を選んですすんでいけ。 (フム) * 人生はアジャイル * 100%準備してからというのは無理。とりあえずやってみる。 疲れた。。。
- * 計画やかくにんや棚卸しをプロマネだけじゃなくて、チームで考える。 * 目的とコストが明確にならないものはりん議を上げづらい。 * 利害関係者は人数が多く、オーナーの調整相手が非常に多いので調整に時間がかかる * 請負契約に「負」はないよね (edited) * SIer側の立場の人が考えるエンタープライズアジャイルの現実解 * 保守契約+３ヶ月定期リリースを作る => 予算ありきで確保する => 要件定義見積もりのタイミングでスコープ調整する。 => 予算なので使う。 => むりであれば次のリリースにのせるので6ヶ月後になるが、1年が半分になるのでちょうどいい。 => ３ヶ月ごとに営業に行きたいから定期的に変更されるのはすごいうれしいとのこと。 => このやりかたで3ヶ月は短い。 (edited) => 金額にたいして、どれだけ改善活動できるかを目安としてだすようにしている。 (edited) -- => ３ヶ月は無理でもハントして結果を出す必要がある。 => だんだん連携できるとどんどんデーたが欲しがるので手で連携する。 => 役員報告は大変(役員に根回しをして、根回しをしてからさらに各部署に事前に相談をして。。。。ぎゃー (edited) => データなどに関しても色々議論のネタになった。 => 企業がビジネス価値を上げるためには３ヶ月ぐらいはないと効果がわかんないよね。 (edited) => 短ければ経営層を巻き込めないし、長ければダレる。 => システム開発するプロジェクトではなく、ビジネスを生む出すプロジェエクトであると定義した。 => ビジネス成果が何かを問いに対して答えられない顧客側の人はダメ。 => 現場に対して政治センスがあって現場に対してプッシュできる人だと最高。 => 社歴の長い企業は1年でサービスをすぐに辞めることはできないから長期計画は大事。 => 組織をオーナーとするかたちで意識のすり合わせをする。 => りん議は追認ではなく、会社でOKしたことであると意思決定を行うこととする。 => POが誰かを組織に対して聞くのは意味がない。 => 2週間はエンジニアの発想。エンタープライズでは通じない。 => 経営者に2週間でどう儲かったか、価値があったか説明できない。 => 3ヶ月周期でやるなら、年間1億程度は払う覚悟ないと継続的にやるのはなかなか難しい