Jim Coplien氏の認定スクラムマスター研修に行ってきた

システム開発 プログラミング

アギレルゴコンサルティング社主催の7月2日〜3日に実施されたJim Coplien氏の認定スクラムマスター研修に行ってきた。

Jim Coplien - Wikipedia

 

認定制度には懐疑的なんだけど、個人的にJim Coplien氏の本は好みのものが多く、彼のスクラム・パターンの研修を受けて非常に感銘を受けたので、今回認定スクラムマスター研修に行ってきた。

 

以下は面白かった点の備忘録。自分の貧弱な英語で通訳なしで聞いた結果なので聞き間違いや、勘違いもあるかも。（通訳は提供されてたが、自分は使わなかった。）

また、色々主張は強いが、質疑応答などでも現場のコンテキストを尊重する姿勢があった。機械的にこうやれ、と言っているわけではないとおもう。高みを目指すなら正しいのは、こっちだ！という主張と理解している。

 

  • スクラムアライアンスとスクラムを一緒にするな
  • 開発マネージャーというのはない。チームがやる。マネージャの仕事は部署間調整などチームが働く環境を整えること、そして大幅な組織改革「カイカク」をやる。チームがやるのは「カイゼン」
  • 基盤となるようなビジネス要求というのは、実は安定している。変化するのは要求の理解である。
  • ユーザストーリーはバックログに入れるものではない。バックログに入れるのは、要求/機能、技術、課題である。ユーザストーリーは要求を理解するためのコミュニケーションに使うもの。
  • JIRAのようなバグトラッカーは無駄である。バグはすぐ直す。バックログ管理は簡単なExcelシートで充分。
  • 研修のようなものもバックログに入れる。そうでないとチームから時間を奪うことになる
  • ユニットテストは無駄。システムテストは無駄だけど、現時点では必要
  • 完了は完了（DONE is DONE）。それ以上やることがないこと。リファクタリング、文書作成、システムテスト、性能テスト、デプロイ。全部終えて完了。POと合意する。
  • 信頼を築くには、まず、自分から信頼すること。
  • 心理的安全性は単なる結果。パーソナルな問題も持ち込んでいい。もし、心理的安全性を保つために、パーソナルな問題に踏み込まなかったり、壁を作っているような場合、それは病んでいるってことじゃないの？信頼が大事。
  • デイリースクラムでは、ペットが死んだ、みたいなものも共有して良い。開発の障害は全て。スクラムは全体性。仕事と個人を分ける必要ない。
  • チームがコミットするのはスプリントゴール。スプリントゴールによって、一体感を醸成する。
  • POが出してきた要求にもチャレンジすることが大事
  • アジャイルコーチを雇っても、開発チームと接触しない。スクラムマスターに対してコーチングする。（どこまで強い主張かは不明）
  • スプリント毎の振り返りでは、浅い振り返りになる。年に３日とか使ってしっかりと振り返りをして改革につなげたりする。
  • ベロシティなども統計的に管理する。一度ブレただけで次の予測を変える必要はない。３スプリント連続で変わったりするなら再考必要

 

前から思っていたけど、ＰＯの役割が死活的に重要と改めて感じた。製品ビジョンを持ち、製品機能を定義し、ＲＯＩを想定しながら、順位付けをしていく。開発者の助けを借りて、やるのだけど、かなり技術にカンが働かなければ難しいとは思う。そもそも、トヨタのチーフ「エンジニア」の役回りの一部らしいので。

 

講師によっては、開発者が考える、と割り切って伝えている場合もあるようだ。

dev.classmethod.jp

 

coplienさんは、はっきりとは確認してないけど、基本的には開発者の助けを借りて、ＰＯが書く立場と思う（開発者も含めたステークホルダーは追記できはする）。プロトタイプを開発チームに渡して説明したりする、ということも言っていた。

ロールを全うするには、個人的には、ＲＯＩに責任もてない開発者がとやかくいうのではなく、ＰＯチーム側にエンジニアリングがある程度分かる人が入ったりする必要があるんではないか、と思った。

 

最後まで、内製チームを想定しているみたいだったな。受託でやるときは、顧客側がＰＯチームにバックログアイテムの検討を支援するエンジニア/コンサルタントを、開発チームと別契約で結んで支援してもらえばいい、と思った。コンサルティング契約とかと似たようなもの。スクラムマスターは開発チームが必要に応じて連れてくればよい。

 

追記①----

  • 多分、スプリントプランニングの時と思うけど、３本指テストでPBIをやり切れるか、の自信を試すといい。

 

追記②----

上に引用したブログによると、POは顧客ではなく、開発者の組織がやり、チームのROIに責任をもつ、とある。正直、自分には「チームのROI」の意味が理解できないし、プロダクトを実際に利用する顧客ビジネスのROIがスクラムのプロセスの中のどこで考慮されるのかが、分からないから、それはbad ideaじゃないかな、と思っている。

とはいえ、それで上手くいく場合も絶対あると思う。というか、そのほうが上手くいくことがほとんどかも。実際、スクラムじゃなくても、SIとかでは、顧客が考えられない場合、製品ビジョンは開発者側が考えちゃったほうが上手くいくこと多いと思う。全体的にくだんの講師のかたは現実解みたいなものを伝えている気がする。

 

でも、個人的にはそれには限界があると思うので、やはり高みを目指すなら、ということ。

 

 追記③----

coplienさんから回答が来た！

 

以下翻訳。

開発者は他のあらゆる面でPOを支援するのと同様に、テストによってPOを支援する。でも、どんなテストを実施するのか、を特定するためのほとんどの作業をPO自身が行う。そして、POがテストすべきエンドユーザー向けの機能とその機能が何をもたらすか、についての最終決定権を持っている。

 

google翻訳で読んだのかな？もしくはまだ、日本にいるから、誰かに訳してもらったのかも。 

 

追記④----

ユニットテストが無駄である旨の記事

https://rbcs-us.com/documents/Why-Most-Unit-Testing-is-Waste.pdf

上記記事のからの引用


• Keep regression tests around for up to a year — but most of
those will be system-level tests rather than unit tests.

回帰テストは続けろ。でも、そのほとんどはユニットテストではなく、システムレベルのテストだ。


• Keep unit tests that test key algorithms for which there is a
broad, formal, independent oracle of correctness, and for
which there is ascribable business value.

広範性、形式性、独立性、正確さがあり、ビジネス価値に帰結する中心的なアルゴリズムに関してはユニットテストを維持しろ

（ビジネスルールのアルゴリズムとか？）


• Except for the preceding case, if X has business value and you can text X with either a system test or a unit test, use a system
test — context is everything.

上記以外の場合、そのコードがビジネス価値を持ち、システムテストでもユニットテストでもテストできるのなら、システムテストを採用しろ。コンテキストが全てだ。


• Design a test with more care than you design the code.

プロダクトコードをデザインするより注意深くテストをデザインしろ


• Turn most unit tests into assertions.

ほとんどのユニットテストをアサーションに変換しろ


• Throw away tests that haven’t failed in a year.

1年間テストして、失敗しなかったテストは捨てろ


• Testing can’t replace good development: a high test failure
rate suggests you should shorten development intervals,
perhaps radically, and make sure your architecture and design
regimens have teeth

テストはよい開発を置き換えたりはできない。高い失敗テストの比率は、開発のサイクルを短くするべきであることを示している。さらに、根本的には、アーキテクチャと設計に改善の余地が大いにあることを確証している。


• If you find that individual functions being tested are trivial,
double-check the way you incentivize developers’
performance. Rewarding coverage or other meaningless
metrics can lead to rapid architecture decay.

もし、テストされた関数が些細なものであったなら、開発者をどのように動機付けしているのかを厳重にチェックしろ。カバレッジやその他の無意味なメトリクスはアーキテクチャを劣化させる。


• Be humble about what tests can achieve. Tests don’t improve
quality: developers do. 

テストが達成できることに謙虚になれ。テストは品質を向上させない。それは開発者しかできない。

 

 

 

IntelliJ IDEAハンズオン に行ってきた

プログラミング システム開発

こちらにいってきた。

samuraism.doorkeeper.jp

 

仕事で使っているわけではなく、個人用に有償版を何年か前から購入させてもらっていたのだけど、使いこなせている感が全くなかったので参加。ツールを追求するのは苦手。。。

仕事ではEclipseだけど、使いこなせている感覚はない。。。

 

当日のカリキュラム

・JetBrains社の紹介
・製品紹介
　・TeamCity/Upsource/YouTrackなどのチーム開発製品の紹介
　・各種開発ツール
・ハンズオン

　・キーマップなどの初期設定

　・ショートカットと補完機能をフル活用したFizzBizz

　・デバッグ機能

　・Git

・クーポンなど
・質疑応答

 

注意点

 

感想その他

・チーム開発のツールは少人数なら無料みたいなので必要なら積極的につかってみたらよさそう。Upsourceがよさそう。

・コード補完機能は、変数の宣言と初期化が「値.var」「変数.if」や条件式.notでコード生成したり、条件式変更してもらえたり、これは、全く知らなかった。。。流れるようにコーディングできて、使いこなすと生産性がかなり変わりそうな印象。

・デバッグ機能は、Eclipseでも使いこなしていなかったけど、実際に目の前でデモしてもらうと分かりやすかた。

　※特定の条件でのみブレークポイントで止まるって機能、Eclipseにあったっけ。。。

・有償のChrononデバッガーがインストール可能なのでそれも使える、とのこと。業務ではまったときとかは使えそう。

Chronon Time Travelling Debugger | Chronon

・Gitの機能もほとんど使ってなかったのでやくだった。一部だけコミットしておくとかって結構使えそう。

 

結論

・時間は金で買える。

・そして、使いこなすのに時間を使うくらいなら、ハンズオン依頼しちゃうのがいいと思った。

 

 

 

コインチェック盗難事件とソフトウェアの複雑性

システム開発

tweetをまとめる。

事件の経緯

第一報？

news.yahoo.co.jp

 

 

会社と社長について

www.businessinsider.jp

 

自分のtweet

 

記者会見

http://logmi.jp/260622

 

会見読んで

 

そこから考えたこと

 

CEO、どう考えても優秀な人だと思う。こういう未熟さは年の功がないとどうにもできない。わきの甘さは後付けで何とでもいえるけど、周囲のおっさん/おばさんもいいアドバイスができなかったんだと思う。

 

追記

 

追記2

返金する方針らしい。興味を失ったので、続きは書かない。

corporate.coincheck.com

書評『現場で役立つシステム設計の原則』

システム開発 プログラミング 書評

下記の本のレビュー記事。

 

現場で役立つシステム設計の原則 ~変更を楽で安全にするオブジェクト指向の実践技法

現場で役立つシステム設計の原則 ~変更を楽で安全にするオブジェクト指向の実践技法

 

 

内容

特定の理論や手法を説明したものではなく、それらをどのように組み合わせていけば、変更が楽で品質の高いシステムを開発できるのか、って問いに答えるオブジェクト指向アプリケーション開発の秘伝の書。

基盤となっているのは

あたり

 

感想

最初の雑感

とにかく様々なことを勉強した上で、現場の実践で考え抜かれ、蒸留されたノウハウが詰め込まれている。ありがとうございます、としかいいようがない。本当に使えるノウハウが体系的に整理されている。

教育コンテンツとしても完成度がめちゃめちゃ高い。前提知識をほとんど要求しないので、Javaなどの静的オブジェクト指向言語とデータベースの入門書レベルをしっかり理解している人ならそれなりに理解できるように記述されている。語られている範囲が広いのに、ボリュームも少なく、頭に自然に入ってくる。これは驚異的。相当推敲を繰り返したんではないか。

古い設計理論や開発プロセスも踏まえて語られているので、昔ながらのSIの現場にも伝わる内容になっている。そして、伝統的なやり方がなぜだめなのか、どうすればうまくいくのか、がしっかりと書かれている。あとは現場で考えてね！で逃げないのって本当にすごく難易度が高い。

 

誰向けか

若手～ベテランまで広くお勧め。そして、SIのマネジメント層に読んでほしい。

 

ドメイン駆動設計との関係

エヴァンスのドメイン駆動設計にある、Entity（エンティティ）やAggregate（集約）みたいな重要なものが語られていない。これは、実は重要でない、というか、意識して作らなくてもいいんでないか、という主張なのではないか、と自分は思っている。エヴァンズのドメイン駆動設計のアップデート。だから、エヴァンスのドメイン駆動設計を知りたかったら、やっぱり原典に当たったほうが良いかと思う。

エリック・エヴァンスのドメイン駆動設計

エリック・エヴァンスのドメイン駆動設計

 

 

プロセス

アジャイルのような反復開発でどのように開発を進めていくのか、ということも書かれている。重要なところに当たりをつけて部品を作っていって全体をくみ上げるってのがオブジェクト指向開発、とな。。こういうのが明確に語られている本は記憶にないなあ。

そして、これはScrumみたいのを形式的に適用したらオブジェクト指向開発はうまくいかないってことになるんだよね。バックログがPO任せだと、POのやりたいことが順番に降ってくるだけ。ウォーターフォールと大差なくなってしまう。

 

画面とデータベースに真っ向から取り組んでいるのがいい

従来の教科書的なオブジェクト指向設計の話だと画面設計やデータベース設計と絡めて語られることがほとんどなくて、現場で一番苦労するのがそこだったりするので、

「オブジェクト指向使えない」

みたいなことになってたような気がする。

この本では、画面とデータベースという、コードを汚くする2大源泉に真っ向から取り組んで、成功しているように思える。そのブレークスルーの源は「ドメインオブジェクトの主役は値オブジェクトのようなスモールオブジェクト」って洞察だと思う。

 

読んでなるほどーと思ったとこ
  • 画面は利用者の関心事（ドメイン）を反映してるって視点。
  • ドメインモデルとデータモデルの本質的なミスマッチ
  • 業務マニュアルを初期から作っていく

なんとなくもやもやしてたけど、明確になった。

 

まだもやもやしているとこ
  • 小さいWebAPI→性能大丈夫か？？
  • メッセージ文字列をドメインオブジェクトに直書き→国際化とかは？メッセージ一覧ほしくならないのかな？
書いてないけど、書かなくていいと思っていること
  • フレームワークとか、下回り（Radisとか）の話
  • 非機能面（性能とか）の対処→疎結合、高凝集の構造だと問題起こっても何とかしやすいからね。

 

書いてほしかったこと
  • テスト→多分、ユニットテストの重要性は小さくなっているはず。メンテもつらいし。開発の中でどうテストし、モデルの成長に合わせてメンテしていくのか、って話をちょっとだけでも書いてほしかった。

プログラミング初心者にはGoがいいんではないか、という話

一応、リンク張っとく
 
よいと思う理由
  • 文法が少なく、覚えやすい
  • 実行可能なバイナリをつくるもので、ソフトウェアがどういうものか、って基本が実感できる。
  • 手続き型言語であり、関数、構造体、抽象データ型、ポリモーフィズム（インタフェースによる）という歴史をなぞる形で学んでいくことができる
  • モダンなプログラミングスタイルのいくつかは備えている（クロージャなど）
  • 例外処理が簡潔
  • 標準ライブラリが充実していて、どれも簡潔な記述ですむ素晴らしい設計（Webアプリ、並列処理、DBアクセス）
  • 新しい言語であり、どんな企業いっても知っていて無駄になるってことはない（と思う）
OOPは手続き型の後に出てきたもの。Javaのようにいきなりクラスってのはつらい。Rubyとかもいいと思うけど、コンパイルって概念とか、型の存在とかは最初に知っておいたほうがいいと思う。
 
Javaを教えていて、これ、本質じゃないんだよなあ、って感じるところがさっくり教える必要がなくなっているイメージ。
 
ある程度センスのある人なら、短期間でかなりしっかり身につけられるんじゃないだろうか
プログラミングやアプリケーション開発がどんなものか、って全体像が最短距離で分かると思う。高校や大学で文系がやるんなら絶対にお勧めする
 
初心者向けのいい入門書が待ち望まれる

心理学的ワークショップを組織でやるときに注意すべきこと

コミュニケーショントレーングやリーダーシップ開発、組織開発で、瞑想や深い内省を促すワークを取り入れる場合がある。

 

昔の感受性トレーニングなんかでは、色々事故も起こっているのでそれなりにリスクある。けど、うまく設計すれば、コミュニケーションの取り方や対人関係構築力、指導力なんかが劇的に向上することもあるので、それなりには各企業で取り入れられている。

 

最低限注意すべきこととしてはこんなのがあると思う。

  • ワークへの参加を拒否する権利を認める。
  • グループへシェアするのは自分の判断でシェアすることを強調する。

 

変な自己啓発セミナー紛いのワークショップだと、トラウマみたいのをシェアするのをファシリテータが強制したり、促したりすることがあるけど、そういうのははっきり言ってろくなもんじゃない。ファシリテータは出てきた時は受け止める必要あるけど、そうした上で、そういうセンシティブなコンテンツに過剰な重要性を持たせない方がいいと思う。

 

ビジョンなるもの

人材育成 思索 成長と変容

経営にも、製品にも、人生にもビジョンは必要。

けど、経営ビジョン作っても、現場ではしらけたり、製品ビジョン作っても、設計段階で意味なくなったり。

 

ビジョンに駆動されていない人や組織がそうなるためにはどうすれば良いのか。例えば、こんなことを考えたらいいと思う。

 

  • とりあえず、作る。部外者が理解できるかよりも、自分たちがテンション上がるかを重視して作る。世の中の良いとされるビジョンは、大抵、その言葉だけでは理解できない。具体的な組織や個人の実践あってはじめて理解される。
  • ビジョンが実現した状態と現在の状態を定義する。現在とどう異なるのかを考える
  • 具体的な行動が、ビジョンに向かっているかをチェックする
  • 必要に応じて修正する。いきなりいいビジョンが描けるって幻想は捨てた方が良い。ただ、テンションは下がる感じに修正してはいけない。
  • 重要でないものを削る。削ってもテンションが下がらないものが結構あるもの。

 

ポエムだが。。。