読者です 読者をやめる 読者になる 読者になる

部屋とアジャイルと私(仮称)

前略。あらゆることの仕組みが複雑化し、テクノロジーに人間が翻弄すらされている今日、ソフトウェア開発に携わるエンジニアの"はしくれ"として、世の中に提供すべき本当の価値を日々迷走中。。。

当Blogを始めて1年経過しました(ふりかえり)

2014年も最後の12月。俗に「師走」なんて言ったりして、先生が走り回るほど忙しい月って小さい時には習った気がするのですが、この師は先生ではなくお坊さんのことらしいとか・・・諸説あるようですが、教師でも坊さんでもない自分も、最近は結構走り回っております。

f:id:uhe_uhe_uhe:20141221234400j:plain

さて、昨年12月にふとしたきっかけからスタートしたこのBlogですが、まだタイトルが「部屋とアジャイルと私(仮称)」のままだったりしますが、取り敢えず、なんとかのらりくらりと続いてきたこともあるので、ここでいっちょ軽く「ふりかえり」を行って、新年を迎えてみたいな、と。

 

 とりあえず定量的なデータ

2013年12月〜2014年12月をワカル範囲で書いてみる。

  • 記事の数:23本
    • セミナー等に行ってきました系:10本
    • 社内勉強会:3本
    • 本:3本
    • Mac:1本
    • その他:6本
  • 合計アクセス数:2600ぐらい(1日平均7ぐらい)
  • 1日での最大アクセス数:たしか140

 

 なるほど・・・

まぁ、個人の備忘録で始めたプライベートBlogではあるし、アクセス数はこんなものかな、と。継続的に何かをテーマにしてアウトプットし続けていないので、定期的にチェックするような人もいないでしょうし。でも、イベントやセミナーで感想系をBlogにアップしてTwitterで呟いたあと、有名人のリツイートからアクセス数が増える事は多々あり、それはそれでオンライン事後コミュニケーションも図れたりという面白さも感じることができました。感想をTwitterでだらだら書くのはイマイチですし、その時の自分の感想・意見を文章にまとめるのは、自分の頭の中の整理にもなるし、今後も続けていきたいな、と。

たぶんどっか1ヶ月を除けば、結果的には毎月最低1本は記事をアップしていたので、細く長く続けるコツは見つけたのかもしれない。色々ある中で、Blog記事を書くときはその事に関して自分の中で何かが盛り上がっているときなので、そういうのが月1回ぐらいあるのはいいとおもうし、逆に少なくとも月1回ぐらいは定例ではないそういう新しい場所に出向くというキッカケにもなるし、なかなかプラスかなーなんて。

あと、たしかTDD系でしたが、自分の記事に対してコメントを頂いたり、自分の記事引用で有識者の方が記事を上げて頂いたり、そういったエンジニア同士のBlogコミュニケーションはとっても勉強になったので、今後もそういうことは経験したいな。もちろん敢えて炎上を狙うことはしませんが(w

良い意味、悪い意味、どちらでも、燃えている記事はネットニュースや個人のタイムラインにすぐに流れる時代なので・・・ 

 

 総括

取り敢えずこのままのペースで今後も続けていこうと思っております。

Twitterとの連動、自分のリアルアクション(新しいイベントに出向く等)は意識しながら、色々な方とのコミュニケーションのきっかけのひとつになる可能性は高いですし、なにより、自分の意見を文章にする事はとっても難しいけど、かなり頭の中の整理にもなるので、うまく付き合っていきたいな。

なので、このハテナのサービスには特段不満も無いです。

もっとハードユーザーの方、所謂Blogerの方の域に近づくと意見も変わるのかもしれませんが。

 

 

最後に、もっと短い文章で言いたい事をまとめる・伝える力ってのは、もっともっと鍛えなきゃって感じです、はい。

 

来年もぼちぼちやりまっせーーー(・∀・) 

Agile Samurai Basecamp 2014 InceptionDeck(Again)に行ってきた。

《改訂履歴》

  ・当日スライドへのリンクを追加(2014/12/24)

 

いや寒い。マジで寒い。明日の選挙はもっと寒い。

ということでこんばんは。期日前投票をしていないアラフォー男です。(明日、寒い中でも、頑張るぞ!)

 

ということで、今日は、Agile Samurai Basecampに行ってきました。実は通算3回目。でも両方ともTDDネタだったので、インセプションデッキの話も興味ありありだった自分としてはこのAgainは超嬉しいAgain。

Agile Samurai Basecamp 2014 InceptionDeck(Again) - Agile Samurai Base Camp | Doorkeeper

f:id:uhe_uhe_uhe:20141213124455j:plain

思い返せば1年前、自分はこのイベントでの衝撃トリガーで、TwitterとこのBlogをスタートした訳で、でも語れば長くなるので、今日はその時の記事をリンクするだけにとどめておくことにしよう。

 

 そもそもインセプションデッキって?

インセプションデッキの経験がない自分としては、プロジェクト憲章のアジャイル版なんだろーぐらいな認識で、メリットはなんとなく分かるものの、実際にどうやればいいのかがイメージつかず状態。そんな中、実際の運用というかデッキをこんなふうに使ってるよ話を聞けたのがとてもよかった。

んー、とは言うものの、自分はプロジェクト憲章をちゃんと作ってPMにアサインされたこと皆無な訳ですが。

そんな中、ひとつの例として、RAKUTEN及部さんの邪道話はとてもリアルだったな、と。

  • プロジェクトのインセプションデッキ、チームのインセプションデッキの使い分け
  • 事前にProduct Ownerと埋めれるとこ埋めてからキックオフで完成させる
  • ふりかえりでちゃんと見直す
  • 個人目標を盛り込む(4tate(帆立)を呼ぶらしいw)

チームを盛り上げるネタに満載で、

  • キャッチフレーズ、進撃の○○とか
  • ドラクエの作戦に例えたり

いろいろ盛り上がっている様子が目に浮かぶ感じ。そういう雰囲気のチームって仕事しやすいし、みんなモチベーション高めだし、まとまった時の強さってパネ〜し、とっても魅力的でした。まさに「やるかやるか(これはやるしかない)」ですね。

 

 

「プロジェクト憲章のアジャイル版なんだろーぐらいな認識」について言えば、自分の結論は、関係者の認識を共有するという意味で目的は近いけど別物だ、です。インセプションデッキはプロジェクトやチームが自ら作るもので、与えられるものではないですね、明らかに。

その場で質問させてもらって気付いたが、デッキの中にある「やらないことリスト」については、ちゃんとした合意を得るのはシンドイし、場合によってはかなりセンシティブだなっとも思った。ちゃんとその合意を得る時に、ふりかえりのタイミングで定期的に見直すことも一緒に伝えておかないと、形だけの合意になってしまい、権力に負けてしまう恐れもあるだろうし。(この辺は組織のコンテキストによって色々あるのでしょう)

 

順番前後しますが、直人さんからインセプションデッキってそもそも何だ?って話や、市谷さんからは事例の話もありました。沢山いい話が聞けたな~

 

 

 

 実際にデッキの一部を作ってみた感想。

 

西村さん、市谷さん両氏によるワークショップ。自分のチームは5人で皆、MacBookでちょっと笑ってしまった。ま、でも、みんなそれで仕事してるって言ってたから、かっこえぇなぁと、全然関係ないところで勝手に盛り上がっていたりw

ちなみに自分はこのイベントの本である「アジャイルサムライ」のパッケージデザインとエレベーターピッチ作成。

テーブルでも盛り上がったし、歩き回って見せ合うのでも盛り上がったし、あっという間に終わっちゃった感じ。こういう「作ってて楽しい」ってプロジェクト憲章とかプロジェクト計画書には無いんじゃないかなぁぁぁ(´・ω・`)

 

※恥ずかしいが自分のアウトプットを晒してみるテスト(むは!キタねぇ字だな…)

f:id:uhe_uhe_uhe:20141213230453j:plain

 

そういえば、このパッケージデザインのキャッチコピー、アジャイルサムライ著者のジョナサンに言わせれば cheesy でいいらしい。(西村さん談)

この場合のcheesyは悪い意味ではなく、ワザとらしく大げさでいいって意味ですかねぇ〜

cheesyの意味は何でしょう ー セリーヌディオンはcheesy? | 英語 with Luke

 

 

 おまけ

最後に個人的なホットtopicを。

もちろん今日はインセプションデッキの日なので、その学びがメインではあったのですが、個人的な裏目標もありました。結果的にはその裏目標にも踏み込めたかな。

このアジャイルサムライは原書が英語で Agile Samurai であるとおり、国境を越えたアジャイル開発なんてものに最近興味が出てきちゃったのですわ。なはは。

西村さんと話していたら、原田騎郎さんをご紹介してもらえたりと、沢山の方との出会いに感謝でございまするm(_ _)m

 

次は当Blogの1周年記念記事を書くつもり。つもり。つもり。。。

 

It's so hard :-)

1ヶ月ちょっと、更新が滞っている間に、もう冬将軍間近。明日から12月ぢゃないでっか!!

この1ヶ月ちょっとを一言で言うと、学生時代に意識・無意識に避けてきたこととにもう一度チャレンジし始めますた、って感じ。

 

 

それは、「統計解析」と「英語」である。

 

f:id:uhe_uhe_uhe:20141129232906j:plain

 

中学時代、数学は好きであった。解けた時の快感がたまらなかった。でも、高校の数Ⅱあたりだろうか、∞(無限)とかlim(極限)とかあの辺りから徐々に冷めてしまい、気付いたら文系に進んでいて。。。いまはメトリクス分析等のためにJMPというツールを使いこなすため、統計解析の基礎を本とか研修とかに勤しんでいる。

しかし数式で言われても、基本がなってないから、分からんのですよ!

理解したいオレの思いを嘲笑うかのように、本当に分からんのですよ!!

 

 

 

そして、英語。

会社からTOEICを受けろというのはまだいい。昇進に点数でハードルができたのもこのご時世まだ理解できる。でも、中学レベルの英文法すら記憶の奥底に封じ込められている現状をみると、いかに学生時代、受験のためにだけ頑張っていたのかが分かる。たぶん大学受かった「瞬間」にそれまで刷り込んだ英単語とか英文法とか見事に吹っ飛んだんだろうな。

また英語については、英会話の方の問題もある。海外旅行や出張で、空港とかホテルとかをなんとか乗り切れてたとしても、普段の日常で外国人を前に英語なんか出てこないのである。間違った英語を話したら恥ずかしいし、「はぁ」って顔をされたら下向いちゃうし・・・

 

そんな英語であるが、聞き取りや文法力はあまり伸びていないと思うのだが、英会話については、ちょっと前進しつつある気がする。

「英語を使えると、世界が広がる」

これを頭ではなく、体というか肌身をもって、最近感じている。

 

実は先月、社内の同僚からインドのグループ会社のエンジニア(現在2ヶ月限定で来日中)を紹介してもらった。彼らの会社はScrumを中心にいろいろAgileをやっているから、と。

そして、何を焦ったか、話を貰ったその日の夕方に対面することに。

もちろん英語を予習している時間など無く、ぶっつけ本番。

日本初来日のインド人の彼は当たり前のように英語で、日本語など皆無。

情報交換という名の雑談だと割り切り、失うものはないと開き直ってみたら、これまた意外に、コミュニケーションは取れるぢゃないですか!!

 

特に、AgileやScrumについては、基本的なコンテキストがだいだい一致してるので、単語レベルでも話はだいたい通じる訳で、

「最近はTDDが熱いお、やってるか?」

「お、Red→Green→リファクタリングやな。絶賛チャレンジ中やで!」

とかそんなイメージ。

逆に、コンテキストの説明からしなければいけない、日本のSIビジネス・人月積算モデルの問題点とか、契約も絡めての顧客を巻き込むことの枠組み的な難しさとか、そういう系の話は、言いたい事を伝えるだけでも苦労する。そして苦労して伝わらない(伝えられない)。。。

ま、でも書籍「AgileSamurai」とかの本の話から、侍の話とか、忍者との違いとか、気付いたら初対面でめちゃめちゃ盛り上がってた(はず)。

この日、英語をちゃんと使えるようになろうと心から思った!!(・∀・)

 

 

インド人のエンジニアの彼はあと少しで本国に戻るが、毎月開催しているアジャイルの社内勉強会にも来てくれたし、LT祭りでも喋ってくれたし、あっちのCMMIの担当を紹介してくれたし(来週Skypeで繋ぐことになった)、アジア最大のアジャイル祭典「Agile India」に行きたいからその時はSpeakerにエントリーしちゃえって話になったし、なんというか間違いなく自分の世界が広がっていく感じ。

可能性が広がってきていることを肌身で実感。

英語という言語のハードルを低くする事で、見える世界は一気に変わること間違いない!

 

「英語なんて所詮ツール

 

と一日でも早く言えるように、日々精進しようと心に誓った。

もちろん、英語の基礎力もつけなきゃいかんが、とてもいい感じのレベルのモチベーションを感じている。

 

でもさ、

TOEICの勉強、辛いっすよ。。。

こういったことに比べると全然楽しくないんすよ。。。

 

ま、しゃーないな。

適当な受験英語で凌いできたツケと思うことにした  m9(^Д^)プギャー

 

 

《追伸》

彼には色々お世話になったので、お礼にAgile Samurai(原著=もち英語)をプレゼントした。読んだ事無いっていってたし、喜んでくれてよかった!

今度はインドで読書会でもしますかな w(・∀・)w 

The Agile Samurai: How Agile Masters Deliver Great Software (Pragmatic Programmers)

The Agile Samurai: How Agile Masters Deliver Great Software (Pragmatic Programmers)

 

 

 

『エッセンシャル スクラム』セミナーに行ってきた!

《改訂履歴》

  ・講演資料スライドを追加(2014/10/10)

 

すっかり秋の風を感じながら、いそいそと道玄坂を登る。この坂、一生懸命歩くと地味にクルのだが、真夏には考えられないほど快適に足が進む。

今夜は、JUAS勉強会の後、気分を変えて『エッセンシャル スクラム』セミナー(第22回 SEcafe、翔泳社)へGo!!

 

会場は初潜入のVOYAGEさん。

f:id:uhe_uhe_uhe:20141010002559j:plain

なんじゃこのお洒落感!! TDLアドベンチャーランドかと・・・(´Д`)

社内にBarがあったり、会議室も畳部屋とか色々あるし、こんなオフィスで働いてみたいものです。いいもの作れそうだな〜〜〜、マジで。

 


翔泳社:第22回SEcafe 『エッセンシャル スクラム』セミナー

 

 

 メインの話
  • エッセンシャルスクラムを素敵な声でダイジェスト紹介(高木さん)
  • 銃士の姿勢、チームとしてのスタンス(チーム全員で仕事を成し遂げるという姿勢)がとっても大事。役割の分担は必要だが、仕事を変に分担して線引くとダメだよ、とCOOLに語る。(岡澤さん) → さっそくこの部分を読みました!
  • スクラムを語る上でマネージャーの話が抜けてしまいがち、でも実際にはマネージャーは必要。具体的には人材資源管理や調達回りなどなど。ということでタイトルは「アジャイルの左手、マネージャーの右手」。あとでスライドを見直そう。(角さん)
  • スクラム界のちょっと複雑な話。認定スクラムの話。スクラムガイドの話。タイプの手が止まらん・・・(角さん)
  • プロセス品質の話(角さん)におもいっきりピクッ!そうなんですよね。自分もその部分が非常に引っかかっています。アジャイルでもプロダクト品質はちゃんと確認しているとしてプロセス品質の話はこれから個人的にも掘り下げたいところ。製造業的な、ソフトウェア工場的な、プロセス品質でプロダクト品質を担保する世界とは考え方を変えなければいけない。ただ、規制の多い製薬業界とか従来型の品質保証が求められる業界がまだまだあるから、そことアジャイルを今後どう絡めていくか、という課題でもある。
  • 翻訳〜出版までの作業自動化、スゴい! ソフトウェアを作るだけの世界ではなく、こういうところでも色々なツールがあるんですねぇ

 

  • 将棋好きw(和智さん)将棋が指せるBARがあるらしい
  • 夏サミで拝見した時よりもカジュアルかつアバンギャルドなイメージ(和智さん)
  • アーキテクチャ大事(先に決めなきゃいけないこと)の話は、エンプラで受託をやっている自分としてはとっても良く分かる話。鋼鉄のWBSが必要なときも普通にあるし、すんごい仰っていることがグサグサ来る。(和智さん)
  • チームの寿命よりもプロダクトの寿命の方が長い、なるほど!(和智さん)

 

そうそう、岩切さんの呟きがとってもナイス♪♪♪ 

会場にWifiあると自分も楽だな〜(マジで)

 

 出会い

懇親会がメインイベントというと怒られるかw

でも訳者4人はもちろん、色々な方と面白いお話が沢山出来たのもおっきな収穫。楽しい夜だった〜

今日あった話の深堀りからはじまって、スクラムアジャイルにTryしている組織の話、アジャイルと品質の話(やはり新しい品質保証の考え方が生まれつつあるのは間違いなさそう)、ECサイトのレコメンドエンジンの中の話(これまた興味深い!こんな話が聞けるなんて・・・)、夏サミでのGxPさんの話・・・あーほんとお腹いっぱい。楽しかった。みんな気さくで話が面白い!深い!新鮮!斬新!お腹いっぱい!

 

facebooktwitterで繋がって頂けた皆さま、今後ともヨロシクです。

facebook派、twitter派、両刀派、色々な方がいらっしゃいますねぇ。タイムラインの雰囲気が大分変わってきたぞ(・∀・)

 

素敵な企画をおっ立ててくださった翔泳社の方、お洒落オフィスのVOYAGEさん、ありがとうございました。

 

 

そして帰り道になんとなく呟いてみたり。。。

 

 おまけ

エッセンシャルスクラム本、買おう買おうとしてamazonのカートで眠っていたのですが、1割引というのもあり、訳者4人が勢揃いということで、ノータイムで BUY BUY BUY!!(あ、1冊だけど)

f:id:uhe_uhe_uhe:20141008010947j:plain

訳者4人のサインも揃ったwww

f:id:uhe_uhe_uhe:20141010004704j:plain

サイン貰ったのなんて、学生時代に小島武夫プロ以来かもwww(あの雀牌は実家に置いてきたような・・・)

 

さて読むぞぃぃぃぃ!!!!!!

 

XP祭り2014に行ってきました!!

2014年9月7日(土)、初めて早稲田大学のキャンパスにこの足を踏み入れてきますた。

初参加の「俺の」XP祭り、思った以上にゆるーい雰囲気の中、沢山の「俺の・・・」を聞き、沢山得るものがあったような気がする。

自分のEvernoteメモを元に、遅ればせながら、個人的に気になったところをblogってみようかと。

 

XP祭り2014

 

 

 アジャイルのダークサイド

聞く話は自分のコンテキストで理解しようと最近しているが(そういえば、最初のお菓子漫談で小井土さんもそんなこと言ってたような)、この日MAXビジバシ感じるものがあったのが、鈴木雄介さんの話

特に最後の『社会基盤を担う大企業にITの使い方を変えてもらいたい云々』 というのはシビレタなぁぁぁ。 あの会場に同じことを感じた人がどのぐらい居たのか分からないが、自分には、スンゴイ切実に響いた!!そんな大企業のSIはまだまだ従来型の人月積算工数で1システムおいくら万円の世界ですし、ここに凄まじい可能性が埋もれているはず。ITを使う側は「アジャイル」なんて言葉はどうでもよく、だからこそ余計に、情シスやSIerが勝手にアジャイルのダークサイドに堕ちやすいって側面もあるかな、と。

知らない間にオレも堕ちかけていることを気付かされました(;´∀`)

 

そういう意味でも、アジャイルという手法に拘るのではなく、アジャイルを手放して、組織ごとに最適なやり方をちゃんと考えた方がいいっていう提起にはもう唸ることしかできなかった。

 

 

 以下箇条書き

・ISO品質モデルから、ソフトウェア作るのは難しいんだよ

・だからこそ、マネジメントとアーキテクチャの両輪が重要

アジャイルは全体整合性(アーキテクチャ)を軽視しているようにも感じる。それはアジャイルの伝道師たちにとっては、アーキテクチャの重要性なんて当たり前の話しすぎたからなのかも(仮説)。

・「良いものを作りたい」という覚悟がないと、アジャイルのダークサイドに堕ちやすい。自分で運用しない人とか偉い人とか危険。情シス部長とかSIerとか。

・言葉上は、ダークサイドに堕ちる人と堕ちない人が同じことを言っているから、さらにたちが悪い。「良いものを作りたい」という覚悟、自分ももっと拘らないとダメだとも感じた。(リスクの低い方低い方へ流れたがるSIって妥協の産物的な要素が強いし)

アジャイルはこうすればいい、と思った時点で思考停止してしまう。状況によって重要性・価値観は変わるもの。(アジャイル宣言の右と左)

★どう作るか(手法)ではなく、どこへ至りたいか(ビジネスのゴール)を考えろ!!

  

 

 関さんの話を誤解してみる

基調講演の関さん。失礼ながら今回、初めて名前と顔が一致しましたです。

Twitterでつぶやいていた人がいたような気がするが、関さんは本当に不思議な雰囲気を持っている方。吸い込まれてしまう感じ。たぶん自分は話の9割分かってないんだけど、半分ぐらいは分かった気になってしまったし、たぶん結構誤解しているんだとおもう。でも、今回の話は、SECIモデルでは形式知を誤解していいんだって話もあったし、そもそもXP自体が人は間違うことを前提にしているから、それでいいんだと、妙に納得感。

お話、のっけから、550イテレーションで数万チケットが溜まっているから統計噛ませて云々とか、もうホント異次元の世界の話を聞いた感じ。ありがたや。

 

気になったこと箇条書き

・減らすのは難しい、増えるのは簡単。テストケースの話。だから健康体でテストは望もうね、と。

・従来の開発手法と異なり、XPは人がミスすることを前提としている。そういう意味でも1つ1つのミスを小さくすることができるモデルと言える。

・ソフトウェアの信頼性。CheckingとTestingの話。モデルベーステストと探索的テスト的なイメージかな・・・

・忍者式テスト、初めて知りましたが、人が学習しながらテストを育てる(テストケースを洗練)感じでしょうか。自動化テストはChecking。人がテストしてテストケースを書き直したりはTestingってことかな・・・

・計画ゲームがアツイ。

・ビジネス側と開発側はうまくいっていないことが多いのだが、この計画ゲームでは、やりながら分かることがあることを前提にしているから、お互いが理解し合える、歩み寄りができる。

・質問の回答で「うちのチームにリーダーはいないからわからん」とか本当かなぁって思ったが、ゴールは同じで途中ズレていることはあるかもしれないけど歩調を合わせていくような話をしていたので、なんとなく理想的なチームを想像した。

・(製品開発をされているのだとおもうが)現在、ビジネス側は開発側のスピードに不満がない的な話をしていたのも印象的。ビジネス側は効率化・コスト削減を常に考えていると思っていたが、それをも駆逐するチームがこの世にあるのかもしれない。

 

うーん、 たぶん誤解だらけ。

 

 

 ビジョンとミッション

 Fearless Changeと超迷ったが、先日の受託開発イベントに行けなかったので倉貫さんの話に言ってみた。 すげーエネルギッシュなトークの中に、SIerに身を置く自分にとって「今の俺ならどうなんだ?」って考えさせられる話が山盛りだった。

何度か「アジャイルは結果」という倉貫さんの言葉を見たが、それを改めて感じた。

自分は何をしたいのか(理想=ビジョン=ゴール)を考え、そこ向かうために今何をすべきか(ミッション=スタートライン)というメッセージは、まだ咀嚼し切れていないが、今の自分も向き合わなければいけないこと。

 

気になったこと箇条書き

・2000年あたりからSIerは「マネジメント重視」に。(PMBOKとかオフショアとか確かにその流れ)で、それまではその会社のことを”技術の○○”って・・・すげー思い当たる話

・プログラム書くのが好きな自分は、デスマに放り込まれて、辞めようとおもって役員に相談したらしいが、社外で活躍したいならもっと有名になれ。でないと辞めてもうちの下請けになるだけだぞ、と。そして仲間を作れ、と。それを実現してソニックガーデンなのですねぇぇぇ(・∀・)

Don’t just do agile, be agile!(これいい言葉)

アジャイルをやる?それって本当に組織のためになるの?みんながみんなアジャイルをやりたい訳ではない。出来る訳でもない。(雄介さんの話にも似た話あり)

・帰り道にリフレインし続けた一言

 『 理想を語れ、そして行動しろ。共感を得られれば仲間は増える!』

 

 

 

倉貫さんは元XPユーザー会の代表。

知っている人をイジリながら、会場の空気を自分のモノにしたり、話の内容もさることながら、すごいなーーー

 

 

 他にも沢山の話を聞いておなかいっぱい

最後はLT祭り。14本連続は正直ぐったり・・・疲れ果てますた:(;゙゚'ω゚'):

みんな個性たっぷり面白い話が多かったが、自分のコンテキストに置き換えて聞くような余裕は全くなく、話についていくのに精一杯。

進行の方の合いの手も絶妙で、あの雰囲気はLTじゃないとあり得ない。

 

以下、自分のメモと順番が合わないが・・・

 

 

デザインスタジオというアクティビティの紹介:平松 欣也さん

  → Yahoo!モバイルのUI/UXのお話、のっけから勢いありまくり

 

僕がスクラムマスターをクビになった訳:石井 智康 (@zambiker)さん

  → スクラムやってて管理層から言われるあるある。「で、いつ出来るの?」「もっとベロシティあげてよ」 「人投入すればできるでしょ?」非開発者のアジャイルには気をつけろ!禿同。

 

俺の「機能横断的チーム」 に近づくためのあれこれ:渡邉 太一さん

  → スクラムの取り組みの中で、全員に全部できるようになってほしいというなか、あえて機能特化型チームをつくったというお話。ある程度は自分の持ち分が明確な方が動きやすい人って多いし、結構現実的だなーって思いながら、自分だったら・・・と聞き入ってしまった

 

忍者式テストをやってみた:中島 滋 (@ledsun)さん

 → テストケースからちょっと外れたテストでバグが見つかるって本当にあるある。だからこそ成長する忍者式テストの話、続きがキニナル・・・

 

俺の事業:木下 史彦さん

 → 実は木下さんのセッションも聞いていた。Twitterでのリアルタイムツッコミ(寿司で釣っているとか)も面白かったwww 永和さんのチャレンジ精神、すごい!

 

チームや組織を良くしようとしている皆さんへ〜課題解決型イベント「Scrum master’s Night」のお誘い〜:長岡 実さん、知花 里香さん

 → 本気で今度行ってみたいな〜 スクラムマスターぢゃなくても大丈夫かな〜 ということで早速connpass.comをチェックしてみたらまだ無かった Yahoo! × DeNAってのもスゴ〜

 

ももたろう:てらひで (#terahide27)さん

 → てらひでさん、まさかの英語すぴーち( ´ ・ω・`)!! しかもそのTシャツ!!(゚Д゚≡゚Д゚)ワラタ!!

 

アジャイルソフトウェア開発の道具箱~永和システムマネジメント勤続10周年記念講演:伊藤 浩一 (@koic)さん

 → なんかイケてる雰囲気な方で、壊れているおもちゃを用意するとか、うちの息子に・・・(ry

 

8年目の活動報告:よねざわ まことさん

 → 関さんと咳さんってどう違うのでしょうか? 自分もスピード違反注意しないと:(;゙゚'ω゚'):

 

○○したら受託開発が180°変わった:原田 敦 (@harada4atsushi)さん

 → あれ?写真見たことあるとおもったら、あじゃいるヒヨコクラブの方ぢゃないですか。(今度行ってみよっかなー)

 

リーンスタートアップと野球2014:中川 伸一さん

 → いやー、最高に面白かった!!スポーツの世界のデータサイエンティストの話。自分も野球好きだけどここまでdeepぢゃなかったので、興味津々。ピタゴラス勝率とかちゃんと理解してみたいな。

【Report】XP祭り2014に参加しました&LTをやってきました。 - Lean Baseball

 

アジャイル病を患ったおっさんビギナーが現場でトライしたこと:すなだ (@orinbou)さん

 →  なんかとっても親近感(勝手に) 朝会に集まらないってこれもアルアルwww アジャイル語を口にしてはいけない現場、爆笑 これも身近にアルアルwww

 

モデリングもしないで”XP”とは何事だ:原田 巌 (@iwaoRd)さん

  → XP祭りの盛り上がりを自分のLTの盛り上がりにすり替えるテク「いただきます(・人・)」

 

メトリクスによる「見える化」のススメ: エッセンシャル・リーン:伊藤 宏幸 (楽天)さん

 → agile2014登壇の伊藤さん、自分の理解しているメトリクスとここでいっているメトリクスはちょっと違うような気もしたが、すげー興味深い話だった。見ている世界がグローバルでもあり、測ることは目の前の自分のことでもあり、いろいろ掻き立てられた

Agile2014に参加してみて分かった昨今の世界のアジャイル事情 - THE HIRO Says

 

 

 

 

 

あ、ちなみに野良LTもあったみたいだけど、どんなかんじだったのかなぁぁぁ

 

来年はネタ作って出てみるか〜〜な〜〜 ( ´ Д`)

 

 

 最後に

初参加優先で頂いた戦利品。読んだらレビュー書きますです。

ありがとうございました! 

ちなみにこの津田さんの「タイムボックスの話」も聴講していたのですが、スライドもアニメーション効いていて、話がすげー分かりやすく、マジでパクりたくなりました。分かりやすく説明するスキルってとっても大事!!!嫉妬。

f:id:uhe_uhe_uhe:20140909001224j:plain

 

LT祭りでMPをすべて奪われてしまい、懇親会にドタ参加する元気までありませんでした。沢山の人の話を聞けたのにで、その後いろいろと突っ込んだ話を聞けると更にいいんですけどね。次回のための良い教訓です、はい。

 

スピーカーの皆様、スタッフの皆様、本当にありがとうございましたm(_ _)m

 

 

追伸

この記事を書きながら、お話を聞いた人を見つけては次々をフォローしていますナウ。あと発表で使われたスライドも見つけ次第、リンクさせていただきます。どうぞヨロシクおながいします。

 

 

 

 リンク集

しかし、みなさん、blogにまとめるのが早い&上手いな〜〜〜

 


XP祭り2014に参加してきました。 #xpjug - ミッションたぶんPossible

 


2014-09-08 - Vestige is fragments of memory


XP祭り2014に参加してきました! -Agileってなんなんだろう が少しわかったお話- #xpjug - エンジニア的なネタを毎週書くブログ

 


XP祭りに行きました #xpjug - @ledsun

 


XP祭り2014に参加してきました(1) | NCデザイン&コンサルティング株式会社

 

「納品」をなくせばうまくいく ソフトウェア業界の“常識"を変えるビジネスモデル

Book

を読んだ。実は1ヶ月以上も前だったが、実はブログを書いていないことにさっき気付く。

8/27のイベントに先立ち、事前に自分の頭の中を整理しておきましょうって感じの2本目記事。

1本目はこちら。

 システムインテグレーション崩壊 ~これからSIerはどう生き残ればいいか? - 部屋とアジャイルと私(仮称)

 

 

さて、Amazonでベストセラーになっているとも聞く「納品をなくせば・・・」だが、元々はソニックガーデン倉貫氏のブログをちょくちょく見ていたので、待ちに待ってた書籍化であった。著者である倉貫氏は大手SIer(TIS)に居ただけあってSIの実態をちゃんと把握されていて、いつも説得力のある文章でまとめられているが、今回は書籍ということでまたいつも違う新鮮さもあった。

 

 

「納品」をなくせばうまくいく ソフトウェア業界の“常識

「納品」をなくせばうまくいく ソフトウェア業界の“常識"を変えるビジネスモデル

 

 

 

 サマリ

 

一括請負のSIモデルでは、作ったシステムを「納品」して売りが上げるSIer(受注側)と、そのシステムを動した後に効果が生まれる顧客(発注側)という相違のため、お互いディフェンシブになりがち。またシステム開発金額は人月積算のため労働集約型。この根本的な問題点に対して「納品」を無くし、開発〜運用ず〜っと顧客と一緒に、月額定額契約で「受託開発(運用・メンテ)」を実施するという新しいビジネスモデルを提唱。ソニックガーデン社はこの形でもう3年ビジネスを行っている。ポイントは顧客と一緒にビジネスを育てていくというCTO的なITプロフェッショナルサービスで、俗に言うDevOpsにも通じるし、Webを使った新規事業のスタートアップでの事例が多い。開発スタイルは(結果的に)アジャイル開発。IT業界のエンジニアは「ナレッジワーカー」であるため自律的でなければならず、また、会社が1つのチームとして機能することを最優先しているので、エンジニアを大きく増やすことは考えておらず、「のれん分け」という形でのビジネス拡大にもチャレンジ中。

 

ザックリいうとこんな感じであろうか。

ひとつひとつの部分について、倉貫氏が大切にしている考え方や価値観(およびその裏付け)が反映していて、それが見事に1つにまとまり、実際にビジネスモデルとしても成功しているというから本当に説得力がある。

 

とても読みやすい文章で、事例や生の声もあり、自分の身の回りでも沢山の人に読んでもらいたいと感じた本である。特にエンジニア仲間というよりも、上司や経営者に読んで欲しいな、というのが率直な感想。

 

 

 ここもポイント

 

キーとなると感じたポイントをいくつか。

 

1.工夫したくなるビジネスモデル

新しいことにチャレンジしたり生産性を向上させるために工夫したり・・・というのはエンジニアの知的欲求の本質。この「納品のない受託開発」は、それらを阻害しやすい(もしくはやっても評価されない)従来型のSIビジネスやSIerの人事評価の問題点が解消しやすいビジネスモデルといえよう。

 

2.顧客からの信頼を得やすいビジネスモデル

「納品(もしくは本稼働)」を目指して受注側と発注側が協力する形よりも、共に新しいビジネスにチャレンジしながら、試行錯誤する形は、結果が出なかったときもWin-Winの形を作りやすいと言える。IT投資の費用対効果は実は測りにくいため、月額定額というのもポイント。

 

3.技術の統一化

扱う技術を統一していることも実はとっても大事なポイント。クラウドサービスの普及で更に一段と技術的な複雑度が増す中、このこともとても重要なポイント。Ruby on RailsAWSLinux・・・という形で技術は統一化し、もちろん進化させているとのこと。 

 

4.マネジメントしない?

というと語弊があるが、要は指示命令で動くエンジニアではなく、自分で考えて行動できる自律したエンジニアである必要があるということ。平鍋氏のいうマネジメントは「コマンド管理型」から「リーダーシップ協調型」へ、という話がリンクする。そしてチームとしては自己組織化された形。どのようなビジネスにおいても、これは理想であり、常にここを目指すべきであろう。

 

5.属人性を排除しようとしない

サブ担当者を置くなどしているということだが、「属人性を排除」することよりも「人を大切」にするという。属人性排除はプロセスありきになるが、個人的にはこの部分は非常に迷いがある。プロセス標準化によって定量化・見える化が実現され、エンジニアリングが発展するためにはこのことは大切なのだが、プロセスなんて糞喰らえってエンジニアが多いのも事実。自律したエンジニアとこの属人性排除はセットで考えた方がよさそうだ。

 

いずれにせよ、ソニックガーデン社はエンジニアの皆さんにとって従業員満足度がとっても高いのだろうと推測する。それは、給与もそうかもしれないが、やりがい的な部分が大きいのだろう。ビジネスモデルの裏にある話かもしれないが、ここが一番の差別化できている部分なのかもしれない。

 

 

 最後に

 

既存SIもしくは、既存受託開発は、明日から無くなることはないが、新しいビジネスモデルが求められているのは事実であろう。倉貫氏は「納品のない受託開発」という新しいひとつのビジネスモデルを作って、ビジネスとして成功させ、そして華々しい舞台にいるのだと思う。そして何よりもご自身のチャレンジを社会に還元しようとしている姿勢は、利益追求を超えた、経営者として素晴らしい方なのだと。そして、現在はまだ模索中であるが、いずれ自分も新しいビジネスモデルを形にしたい!

 

先日の夏サミで、倉貫さんとお話しする機会があった。 ま、実際は、この本が手元に無いのにサイン会に自分が勝手に押し掛けたのだが・・・ でも、とても気さくに対応してくださったのだが、その飾らないけど輝くオーラは、ブログ等で感じてた印象そのままだった。だからといって、この書籍のベタ褒めはしたくないのだが、ビジネス書としても類い稀まれな良書だとおもう。

この業界を知らない父にも薦めてみようかな。あ、でも、その前にうちの上司と経営陣に読んで欲しいな。

 

エレベータ・ピッチを練習だ!!(・∀・)

 

 

最後に、

8/27のイベントが更に更に楽しみになった。何を質問しようかなぁ〜

受託開発ビジネスはどうなるのか、どうすべきか | Peatix

 

 

システムインテグレーション崩壊 ~これからSIerはどう生き残ればいいか?

Book

を読んだので書くことにした。

8/27のイベントに先立ち、事前に自分の頭の中を整理しておきましょうって感じで。

もう1本目の記事はこっち。 

「納品」をなくせばうまくいく ソフトウェア業界の“常識"を変えるビジネスモデル - 部屋とアジャイルと私(仮称)

 

最近、SIビジネスが曲がり角に来ている話題はなかなかホットトピックスで、自分自身もSIビジネスに携わるものとして、また新しい価値を生み出すITサービスを実現するためにも、この話題はとても興味深いところ。

 

 「SIの闇」に光を当てたい! 

 

システムインテグレーション崩壊 ~これからSIerはどう生き残ればいいか?

システムインテグレーション崩壊 ~これからSIerはどう生き残ればいいか?

 

 

 

 サマリ

 

ビジネス環境変化に対して「SIビジネスも変わらなきゃいけない」理由から、では「具体的にどういうアクションが重要か」という提案までが、読みやすく簡潔にまとまっていたと感じる。特に、「変わらなきゃいけないけど、でもどうやって・・・」と認識している人を対象にしている印象。

 

終盤に書かれている、既存SIを進めながら新しいSI事業(文中は"ポストSIビジネス"と表現)を作り上げる、部分については、同じことを考えている人は多いはず。顧客(情報システム部門とかの発注側)とSIer(ベンダーなど受注側)の両視点で整理されており、SIビジネスの「創造的破壊」を起こす側に向けたメッセージと言えよう。(この議論を発展させると、市場のIT利用者(ユーザー)の視点ももっと加えていく必要あり!)

このポストSIビジネスを成功させるためには以下の5つシフトが必要とのこと。(各論の感想は後述)

サービスビジネス

クラウドビジネス

OSS活用

グローバル対応

新しい存在意義・新しい役割

 

それぞれのテーマがとても深い話題であるが、SIビジネス全体を俯瞰して整理し「では、どうするか?」のきっかけになる良書であろう。次のSIビジネスにチャレンジしたいと思っている仲間や上司にも薦めたい。

 

 なお、1点だけ違和感を感じたのは、事例に出てきた方の言葉かもしれないが「受託開発が嫌い」「受託開発を止める」など、労働集約的工数積算モデルと受注開発を同義に書いてあった部分。従来多かった一点モノ(フルオーダーメイド)のシステム開発は無くなったとしても、企業の競争力の源泉(つまり他社との差別化)にITを有効活用することが今まで以上に求められているので。

※んー、まー、言葉の問題かなー

 

 

 5つのシフトについて

 

1.サービスビジネスの例が3つ紹介されている(月額定額モデルとしてソニックガーデン「納品のない受託開発」、レベニューシェア(成功報酬型)として日本ユニシス、取引量に応じた月額金額としてNTTデータANA基幹システム)。初期投資を押さえての月額支払(定額もしくは変動)は、発注側と受注側の関係性を変え、Win-Winに向かいやすいだろう。

 

クラウド利用への流れは止まらないことも、月額支払モデルを後押ししているため、クラウドが一括請負を淘汰していく流れと言えよう。クラウドサービスは層構造で成り立つので、SIerはどのレベルのサービスを誰に提供するか、が重要。

 

OSS活用も止まらない流れ。OSSに関連する技術者は会社を超えたコミュニティに積極的に出ていった方がよいし、実際にインターネット上で情報発信することを奨励している会社は増えてきている。とはいいつつ、Githubひとつとってもハードルに感じるところはまだまだ多いだろう。


グローバル化について、日本と欧米の文化の違いの話は外せない。ITサービス展開のグローバル化と組織や開発チームのグローバル化は分けて掘り下げる必要あり。後者については人材流動性(横のキャリアパス)のジレンマ・・・


SIビジネス事業者が、顧客のCIOになれ的発想は大賛成。アジャイル開発の本質は「全部を作らないこと」というのはソニックガーデン倉貫氏と同じ主張。また、アジャイルは開発手法ではなく「働き方」というのも、自分の中では納得できた言葉であった。

   アジャイル開発の本質 〜 アジャイルとウォーターフォールの違いとは | Social Change!

    

 

 まとめ

今現在、既存SIで人が足りない・足りないという話を身近でも聞く。従来型の労働集約的なSIを明日から捨てることはあり得ない。放っといてもSIビジネスはある程度緩やかに変わるだろう。でも、生き残るのは変化する市場に対応して変われた組織であり、変われた人たちだけであろう。今、自分は、そのことにチャレンジできる環境に居る。

 

8/27のイベントが更に楽しみになった。著者である斎藤昌義氏とはお会いしたことがないが、この「システム・インテグレーション」について、とても熱い想いをビジビジ感じ、読む前よりもいっそう、直接話をお聞きしてみたくなった!

受託開発ビジネスはどうなるのか、どうすべきか | Peatix

 

 

 

 

 

あ!

 

「納品をなくせばうまくいく」はまだブログに書いてなかった!(´・ω・`)

 

書いたつもりになってた自分・・・orz