現場で役立つシステム設計の原則 読書会 に参加してきました。
読書会の第５回目からなのに参加してきました。
読書会は輪読形式。
章の中の小さい章（段落？）を一つの区切りとして
その中の内容で疑問、反論、突っ込み等、議論していく形式。
もちろん、参加者が全員「まぁ、そうだよね」と思ったり、
特に何か議論が発生しそうな内容で無い場合は、議論しない場合もあります。
なので
読む時以外、一切しゃべる事なく人が話しているのを聞いているだけでも大丈夫です。
話を聞いているだけでも
「あ、それ思った。」とか「その視点は面白いな。」とか「あーなるほどね」とか
参加してみたら実感として分かるのでおススメなのですが。
みなさん、色んな事考えながら読んでらっしゃるんだな。というのがわかります。
もし、この本を一人で読んでいる方がいらっしゃるならば
是非、読書会に参加してみてはいかがでしょうか。
自身で読んで体験した事とは別の視点から本を読む事が出来るかと思います。
本の内容的には４章の後半から５章の前半にかけてでした。
４章前半では、ドメインオブジェクトはこうやって作っていくんだよ。
ちょっとでも油断するとすぐにトランザクションスクリプトになっちゃうから
気を付けて、丁寧に設計、開発していかないといけないんだよ。
安易にソースコードにロジックを書くんじゃなく、ドメインを意識してソースコードを書かないといけないんだよ。
的な事が書かれていると思います。
で、後半部分なのですが、そのドメインをどのように育てていくかが書かれているわけなのですが。
読書会でも誰かが言っていましたが「コミュニケーションスキルを磨け」って事が書かれているように見えてですね…。
本当に「ドメイン育てるには、コミュニケーションスキルを磨け」って書いてあるのか？私の思い違いじゃないか？
と思ったのが、この読書会に参加しようと思ったきっかけ。
４章の途中までは、チーム内の共通認識だったり、約束事だったりでドメインオブジェクトは作っていけるな。
とチーム内でも展開しやすい内容だぞ。実践出来そう。と思っていたのですが。
「ドメインの知識を増やすために顧客から業務知識を引き出せ。」
と言われた時に、それが出来るのって、チームか？スクラムマスターの仕事じゃないか？とかチームの共有の情報にするためにどうする？とか
もちろん、製造しているチケットの内容によってはチームが顧客から業務知識を引っ張り出す事は可能かもしれませんが、認識の範囲外の事を引き出すのは難しいんじゃなかろうか。
ワークフローをいかに熟知していたとしても…。
そう思って参加してみたものの
やっぱり「コミュニケーションスキルを磨け」って書いてますよね。
得た知識をドメインに反映せよ。とは書いているものの。
どうやってチームに展開するかとかは書かれてない。ドメインというものは複数人で育てていったとしても、上手にスケールアップしていかないといけないわけで。チーム内でどうやって育てていくか。レビュー以外の場で得た暗黙知をどうやって伝えるか。
ウォータフォールにしろ、アジャイルにしろその辺が課題かなぁ。とか思ってました。
揚げ足取りに近いんですけど。
どうしても、気になって気になって夜も眠れず、これのためだけにブログを更新しようと思ったんですけど。
「業務に習熟した人」と「業務の経験者」と「業務の専門家」
という、意味的に似たり寄ったりな単語が複数使われており、多分文脈的に同じ人を指しているんだろうけど、ここで表現方法が揺れるのはどうなんだろう？もしかして、これは意図的に変えてるのかな？
とか、ちょっと勘繰りが入ったりするので、そういうところは読みにくいかな。と思いました。が、これは私が細かいだけだと思います！！！
スクラム道関西の定例会に行ってきたよ。
スクラム道関西の定例ミーティングでの話
Sierでもアジャイル導入してるって言ってる所増えたよね
という話から
紆余曲折あって（紆余曲折はスクラム道関西に来ると聞けるかもね！（ダイマ））
SierでCCPMが流行らない理由がわからない
じゃあ、スクラム道関西改めCCMP道関西で流行らせるか！
というような冗談なのか本気なのかわからなん与太話になったりならなかったり。
なんで流行らないのかな～って理由を個人的に考えてみたので、書いてみようと思う。
個人的な意見なので、浅いし突っ込みどころ満載です。
その１．アジャイルはWFと比較出来る
アジャイルとWFを比較して説明しているサイトを見かける
疑問でしか無いけれど何故か相対するものとして扱われている事が多い
WFじゃリリースまでの手順を踏むと重厚過ぎるからアジャイルに移行した
というのも一つの要因だとは思うけれど、WFが悪アジャイルが正義なわけでもない
一つの手法というだけで、それ以上でもそれ以下でもないと思うけれど
まぁ、この辺は本筋には関係ない持論なのでどうでもいいとして
単純にブログネタとして扱い安いんだろうな。
システム開発に携わっているならイメージしやすいだろうし。
その２．PMBOKの変わりになるの？
なので、開発者は興味無し。
マネージャはスケジュール管理の部分（スコープ管理も含むのかな？）だけ
なのでPMBOKの変わりにならない
（品質どうすんねんとか調達、組織管理どうすんねんとかとか）
その３．上手く回してるプロジェクトマネージャーは同じような事やってる
多分、やってるキガスル
以前メンバーとして参加していた上手くいったWF型プロジェクトを
ぶん回している人が同じような考え方してた。
呪文のように
「WBSはプロジェクトで一番出来ない子がやってギリギリ終わる（と思う）
工数で引け」
って事を会社の先輩に言われた事がある。
（そのプロジェクトは割と上手くいった。俺がバグ出しまくったけど。）
下手打ってるプロジェクトマネージャーはそういう事やってないし
そもそも、意識を外に向けて色々試してみようという事せずに、
開発やら設計やらに責任転嫁してるダメな人が多い気がする。
その４．具体的な事例が少ない
そのままですが、
アジャイルにCCPMを取り入れてみた！
とか
PMBOKにCCPMを取り入れてマネジメントするとこうなる！
みたいなブログが乱立するようになれば。。。
ってそうなったら流行ってる事になるのか。。。
その５．そもそも流行ってる
私が開発者界隈にいて気が付かないだけで
プロジェクトマネージャー界隈では既に常識になってる。
CCPMの考え方は、1つの解決策にはなると思うけどな。
スクラム道関西の定例会に行って来たよ。
定例会
マルチタスクのワークショップの素振り（？）を体験
①：A ～ T
②：7の倍数
③：○×△
それぞれ20文字書く。
1回目、すべて同時進行
2回目、それぞれ書く
同時進行だと、前の文字を確認してからでないと続きを記述する事が出来ませんでした。
おっさんの思考回路だと、今どの地点にいるのか把握するのは難しい。。。orz
あからさまに2回目のスコアが良い。
常日頃から思ってましたけど。
コンテキストスイッチってほんとにムダというのを実感。
次回の新人講習会でやろうかな。とかコッソリ思ってました。
個人的になにかに似てるな。。。と思っていて。
ドラムの楽譜を思い出した。
裏拍表拍、左右手足を別々に動かさないといけないとか。
脳みそと神経がどう繋がってんだと感心したもんだ。
全部の拍と手足をどの順番で動かせばいいかを順序立てて無理矢理シングルスレッドで脳みそから命令出せばおいらでも出来たけれど
こういう楽譜を初見でスラッと叩ける人はマルチスレッドなんじゃなかろうか。
そういう意味で言うとスコアもいろんな楽器が混ざってるけど、自分で演奏するわけじゃないし、そもそもスコアってどういう曲を作るかの設計図であって別にマルチスレッドで脳みそを動かしているわけじゃないのよね。（高校時代の生徒指揮で指揮棒握ってただけの人間なんで、そんなわけないと思われたらごめんなさい。）
反復的に訓練すればマルチスレッドという名のシングルスレッドで動かす事も可能だけど、本当の意味でのマルチスレッドが出来る人っていうのは稀なんじゃなかろうか。
あと、扇町公園はポケモンがいっぱい（謎）
真の定例会
出産スクラム
・POは奥さん
・出産準備品リストはバックログか？ただの買い物リストか？
・自宅に帰ったらデイリースクラム
・今までは2週間に1回デプロイ（妊婦検診）があるので、それが終わったら振り返り
今週からは1週間に1回デプロイ
１と０
リーンディスってるってよ！！！
リーンスタートアップの成功の影にどれだけの失敗があると思ってんだ！
（関西スクラム界隈の重鎮談）
スクラムがわからない
私はスクラムって↓だと思ってる
なので、別に
CCPMが混ざろうが
XPが混ざろうが
それは別にいいんでないの。
だってフレームワークなんだもん。
オブジェクト指向ってなんですか？な人が作った独自フレームワーク（ｷﾘｯ
にさえならなければ、いいんじゃないでしょうかね。
技術の組み合わせは日本人の得意分野では？
だから間違ってないと思いますけどね。
バックログ1個減らすと100万儲かるらしいよ！
途中から話聞いてなかったけど、アジャイル界の重鎮と電子遊戯業界の重鎮が話してました。
品質の定義
品質が～品質が～って言われたら
「qualityって言葉と使わずに、お前の品質を説明してみろ」
って言え。
ってアジャイル界の重鎮がおっしゃってました。
「それがお前の思う最低限の品質なんだな、それに5%上乗せしてやりゃ満足するだろ」
みたいな事をアジャイル界の重鎮がおっしゃってました。
品質って言葉の定義って曖昧だよな～
最低限の品質ってなんですか？って聞くと
Poorなバグが出ない事
って返って来たりするけど、結局PoorってどこまでPoorなんじゃろ。
って思う。
マルチタスクのワークショップは誰のため？
Aさんの意見
7の倍数にする → チームはこんくらい複雑な事やってんだよ！ってのをマネージャにわからせるために、7の倍数みたいな複雑な計算にする。
Bさんの意見
１～２０までの簡単なものにすることでマネージャ層＝それなりに経験を積んだ偉い人
の「こんな簡単なもんだったら、ワークショップの主旨に反して、期待値よりも上のスコア出しちゃうぜ」というマネージャ層の自尊心？に火を付けて、「あれ、思ったより出来ないじゃん、コンテキストスイッチうぜー」という効果を狙う。
つまり！
マネージャ層に対してのものなのね。って思ったけど
マルチタスクはアカンってのは、新人とかン時に教えておけば変に作業を全部受けて平行でやる子が少なくなっていいかにゃーとか思ったり思わなかったり。
ワークショップとティーチング
ファシリテーターも学びが無ければ、ワークショップじゃない。
ティーチングすればいいじゃんって話。
イレギュラーなケース
例えば、マルチタスクのワークショップで、マルチの方がスコア良かった人がいる
そういう人をイレギュラーとかエラーとか少数だからとかで切り捨てるのはダメ
なんで？どういう思考で？とファシリテーターが自分から学びに行く姿勢を参加者に積極的にみせていかないといかん。
って話。
真の定例会の方の話の方が濃いのはいつもの事。
