昨夜のXP祭りの実行委員ふりかえりを Post It Plus でキャプチャして共有してみました。
写真は内容を読めないように加工(blurフィルタ)しておりますが、オリジナルは付箋の内容までだいたい読めます。
Post It plus を使ってキャプチャしたものを PowerPoint で出力して Google Drive 上で回転とか余分なもの削る、というフローで、とりあえず仲間に共有まではいけた。
写真共有と違って、付箋一枚一枚がオブジェクトなので多少いじることができたり、PowerPointでコメント入れたリが楽しそう。このあたりは既存のやり方(写真を取って加工)にないところなので、面白い使い道がありそう。
PostIT Plus で取り込むときに付箋が重なっていると認識が弱いので、離して貼るのがよさそう。
今年も楽天テクノロジーカンファレンスを10月25日に行う予定です！
これに先立って、前夜祭と前々夜祭も行われます！
ちなみに社内では、前野菜・全然野菜とも呼ばれ、たいへんヘルシーなことになっております。
Copeからの組織パターン研修へのお誘いメッセージをざっくり翻訳してみました。
(I did quick translation of Cope's message to Japanese friends.)
This is to all my Scrum friends in Japan:
I'll be visiting you guys in a few weeks to enjoy the country and to continue work with some old partners.
While I'm there I once again will be running the seminar on "Improving your Scrum with Patterns" on 7 November.
日本にいる私のスクラムフレンドすべてに向けてのメッセージです。
私は数週間後に日本を訪問して、以前からのパートナーと一緒に仕事をします。
その間に、もう一度「パターンを使ってスクラムを改善する」研修を11月7日に行います。
This is a rare opportunity for ScrumMasters to learn concrete approaches to improve their teams' performance,
or for entire Scrum teams to come together to accelerate their practices.
This is what Kaizen mind is all about.
So if you've gotten started with Scrum and have been working hard to make your practices better over the past months or years,
and wonder how you can achieve the levels of performance that people like Jeff Sutherland talk about,
consider making an investment in this workshop.
これはスクラムマスターにとって、チームのパフォーマンスを改善する手法を学ぶ、とても貴重な機会です。
スクラムチーム全体にとっては、プラクティスをみんなでよりうまく使う方法を学ぶいい機会になります。
その正体は、改善マインドです。
ですから、もしあなたがスクラムを始めてから、何ヶ月も何年もプラクティスをよりよくするために頑張ってきたなら、
そしてジェフ・サザーランドさんが言うような素晴しいパフォーマンスをチームで達成するやり方を知りたいなら、
このワークショップに投資することを考えてみてください。
We will be describing how to use the Organizational Patterns that we have been writing over the years
— including patterns contributed by Mike Beedle, Gabrielle Benefield, Jeff Sutherland, Neil Harrison, myself,
and many more — to improve your Scrum. We'll be focusing on the patterns in the Organisational Patterns book.
私たちは組織パターンを使いこなす方法を説明します。組織パターンはスクラムを改善するために、何年もかけて、
マイク・ビードル、ガブリエル・ベネフィールド、ジェフ・サザーランド、ニール・ハリソン、私自身、
そしてもっと多くの人々の貢献を受けました。私たちは組織パターンの書籍を詳細にみていきます。
You can learn more at http://members.scrumalliance.org/courses/20144219-extended-education
or can sign up at http://agilergo.wufoo.com/forms/registration-agilergo-japan-2014/.
There's a substantial discount if you attend as a Scrum Team!
We hope to see you there!!
内容について詳しくはこちらに: http://members.scrumalliance.org/courses/20144219-extended-education
登録についてはこちら: http://agilergo.wufoo.com/forms/registration-agilergo-japan-2014/.
スクラムチームとして参加する場合には割引もします！
研修でお会いしましょう！
組織パターン (Object Oriented SELECTION)
![組織パターン【電子書籍】[ James O. Coplien ]](http://thumbnail.image.rakuten.co.jp/@0_mall/rakutenkobo-ebooks/cabinet/9257/2000000149257.jpg?_ex=128x128 "組織パターン【電子書籍】[ James O. Coplien ]")
組織パターン【電子書籍】[ James O. Coplien ]
![組織パターン [ ジェームズ・O．コプリエン ]](http://thumbnail.image.rakuten.co.jp/@0_mall/book/cabinet/8443/9784798128443.jpg?_ex=128x128 "組織パターン [ ジェームズ・O．コプリエン ]")
XP祭りの懇親会では(最近は大体そうなのだけど)、日本的な乾杯の概念をちょっと緩めて、乾杯をした。継続的乾杯と名付けた人がいて、なかなか素晴しいネーミングだと思った。
日本的な乾杯から、以下の制約をはずすだけでだいぶ快適になると思う。
1は特に海外の人に理解されづらい日本の慣習だと思う。「ウェルカムドリンク」と名を付けることで、日本の人にも比較的抵抗なく、この制約を外すことが受け入れられると思った。
2の制約を外すには、「乾杯の練習」と名付けるのがうまい作戦だと思った。コミュニティでよくやられている。
3は1-2と結びついた上に長くなると問題になるが、逆にそうでなければよいので、お願いの仕方を工夫すれば大丈夫だろう。いきなり振られても困るケースが多いので事前にお願いしておくのがよいと思う。とくに海外の人。
以上、私が発見したわけではないが、制約を緩めることに関して社会的認知が高まるとうれしい(やりやすい)ので、ここに記録に残してみた。
XP祭り2014を開催した。大きな事故もなく終えることができたのはみなさまのご協力のたまものだ。規模が大きくなっているのに、手作り感が残っているのがよいというご意見もいただいた。スタッフは少人数でそれなりに大変なので、実行委員をやっていただける方が、ボチボチと手を上げていただけると助かる。すでに手を挙げていただいた方もいる。毎年、「初めて来ました」という方が多いのが特徴だ。数年ぶりという方もいる。気軽に来て、なにか発表してみたり、他の方からエネルギーをもらったり、相談できる仲間を見つけてかえっていただけると、うれしい。
前説の資料はこちら。なるべくコンパクトにXPの説明と、XP祭りの説明を入れることを試みてみた。
https://speakerdeck.com/kawaguti/xp-matsuri-2014
今回は、Joseph Yoder もカンファレンスに寄ってくれた上に、トークもやってくれた。今後もタイミングが合えばぜひ英語でのセッションも用意できればと思う。5分でキッチリ銅鑼を鳴らすLTの形式に興味を持ってくれて、懇親会で5分スピーチにチャレンジしてくれたのが、とてもよかった。
ありがとうございました。
よしおかさんがざっくりいいきるときは、だいたい適当なので、突っ込んだ方が損した気になったりするものなので、適当には適当で返しておこうと思います。なのでこちらの話はとても適当ですので、突っ込まれると知識不足が露呈しますが、予めご容赦ください。
システム管理者、感謝の日イベントに参加した。 - 未来のいつか/hyoshiokの日記
どんなプロジェクトも工期通りに終了する。工期が遅延して品質もぼろぼろといういわゆる「デスマーチ」のようなものは建設業ではほとんど起きないそうである。それはやっぱり工事現場だとものが出来ていくのが見えているので、ヤバい問題はわりと早く発見できるかららしい。結局、問題を可視化して、早期に問題を発見し、早め早めに手を打つということらしい。
ワールドカップやオリンピックごとに、建築間に合うのか問題が起きているのは、日本じゃないから、という事なんでしょうか。うまくいってない工事というのもあり(東京青山の億ション工事で最強トリオが引き起こした前代未聞の大失敗)、そこまでいかなくても、ディテールを修正して間に合わせるという判断も起きているはず。そういう意味では、細かな要件の見送りや削減は日常茶飯事でしょう。土地図面の信頼性はあまり高くないらしいので、掘ってみないと分からないことは多いっぽいです。掘ってみたら遺跡が出てきて大幅な工期遅延ってよく聞きます。都市伝説かもしれませんが。
たぶん、SIer(IT業界のゼネコンさん)も同じこと言うと思います。「うちは要件定義と調査能力に強みがあるので、発注いただいた後の工程の大きな変更は起きないですし、問題が起きてもすぐに対応していますので、デスマーチのようなことはなかなか起きないと思います。ただ、もちろん、お客様のご都合になるべくあわせ、最終的にはなんとかします。」とかとか。
実際は営業さんと付き合いがあまりないのでよく知りません。適当です。
ソフトウェア業界の問題は、従来は請け負ってこなかった分野をパワポ一つで取りにいってしまう、エンジニア経験のない営業さんが起こしている部分もあるのかもしれません。業務要件をきちんと理解し、PMBOKやITILをきちんと勉強していれば防げるたぐいの凡ミスも多いんじゃないかと推察します。エンジニアサイドで昔からよく聞く話は「営業がこんなの約束してきやがった。」です。
あ、関係ないですけど、だいぶ前に、引っ越し屋さんも同じこといってました。
たぶん、日本のソフトウェア業界ではエンジニアリング知識(コンピュータサイエンスとまで言わないまでも)を持った人がすくないので、そういう人が営業することもないし、顧客やユーザーとの折衝に入っていくことも最後の手段と見られています。そんなことよりコードを生み出せ、と言われていると思います。でも実際は、エンジニア知識がない人がたくさんのムダな仕事を生んでいたりして、結局すり切れるまでエンジニアが火消ししている、なんて状況がたまにあります。ちょっとできる若いエンジニアの人からすれば、そういう時に頼られることがカタルシスだったりしますし。
あ、これ20代くらいの自分を見返して書きました。すみません。
建設業界のゼネコンさんって得意分野が明らかで、作ったことがあるものを量産するタイプのマンション建築ではそういうのが得意なメーカーさんが優位性を持っているようです。ちょっと難しいのを中心に請け負う最先端のメーカーさんもあるみたいです(ブランドがある)。構造設計が難しい橋梁建築も、特定の会社しか受けないと聞きます。
ITゼネコンさんも以前は分野が明らかで、ノウハウの蓄積先も明瞭だったのでしょうが、そのあたりが徐々に崩れてきて、技術者もキープできなくなって...というのがここ10-20年くらいの流れではないかと思います。これはたぶん順番としてはITが早くきていて(クラウド)、徐々にモノ作りメーカーの技術者に進んできている、という感じもします(もちろんモノ作りベンチャーさんは以前からたくさんいますけれど)。
Facebook の方で、Yoshiya Tachikawa さんに、「事柄、建設業の方と接する機会が多いのですが、結構デスマーチありますよ。分かり易い例だと工事中の事故が起きた時とか。事故だけでも年間2万件以上ありますので。」というご指摘をいただきました。ITだと精神疾患が多く判定が難しいため、労災の適用になる比率は多くないかもしれません（そういう意味では、建設業界の方が労働災害が明確に見える化されている、と言えるかもしれないですが、そんなこと分かっても誰も得しないですね）。
建設業における労働災害発生状況
http://www.kensaibou.or.jp/data/statistics_graph.html
えーっと、こういったデータを元に、建設業界とIT業界の優劣を論じる気はありません。
「ITゼネコン」という単語が正しいかどうかにも、興味はありません。
同僚が、
「自分より長生きするモノが作れたら、開発者としては幸せだろうね。」
と書いていた。
私も以前はそう思っていたんだけど、いつ頃からかそう思わなくなった。その「想い」によって、よいソフトウェアも、ダメなソフトウェアも生み出されるんじゃなかろうか...と考えるようになったからだろう。
ダメなソフトウェアというのは、いろいろあるが、開発者が去った後にメンテできなくなってしまったソフトウェアも、やはりダメなものだと思う。ソースコードがいかに優れていても、メンテナンス体制が組まれなくなってしまえば、徐々に利用価値を蝕んでいくようになる。実装がまともでないものは論外だが(リリース時点でだめとか、リリース前に負けてるとか)、設計も実装も当初の運用もすべてまともであっても、時が過ぎるとダメになってしまうものは、よくあるのだ。
自動車のエンジンが危険なく動き続けるためにはメンテナンスが必要で、それは少なくとも製品の寿命に等しい期間必要になる。なので、その期間存在できるチームを作る必要がある。外部の力を頼ってもそれは同じで、保守費はかかるし、バージョンアップのときに前のソフトウェアは引き継げない。
だから、本質的にはチームを小さく維持して長生きさせることと、継続的にアウトプットを出し続けるようマイルストーンとバックログを整備することが、ゾンビを生み出さない唯一の道なのではないか。
実は、ソフトウェアを必要としない状況であればゾンビも生まれないのだけれど、実際は目の前の状況は既に生まれたゾンビと新しい状況への対応で日々戦っているので、今のところソフトウェアを要求していることが多いとみている。次善の策として、複数のゾンビを処理しながら、一つの生きているソフトウェアを生み出し、それをやり続けるチームを維持する。
あと、つらいと思ったら続かないので、楽しくやる仕組みを考えるのは大事なことだと思う。
- - -
こういうことが、スクラムに出会ったときにちょうど気づいたところだったりする。
...ような気がする。
