2012年10月31日水曜日

『スクラム道 EXPO 2012 - 午後のセッション』ノート - 1 / 2

2012/10/28に開催された『スクラム道 EXPO 2012』午後のセッションのノートのパート1です。

パート2はこちら


◆高橋 一貴氏「スクラムマスター思い出語り」

◇アジャイルコーチをやっている
・自分は推進係
 →知らないところで好きにやっていたりする
・昔は壁に張り物がなかった
 →今は場所取りが必要なくらいになっている

◇スクラムマスターって?
"スクラムマスターは、スクラムチームとのやり取りで役に立つこと/立たないことをスクラムチームの外部の人たちに理解してもらうようにする。
スクラムマスターは、みんなのやり取りを変えてもらうことで、スクラムチームの作る価値を最大化するのである。"
 - (Ken Schwaber and Jeff Sutherland、 Scrum Guide)
 →みんなのやり取りを変えてもらうことでスクラムチームの作る価値を最大化する

◇最初はわからないことだらけ
・スクラムマスターについて
 →どこまで理解しておけば?
 →チームとの関わり方のコツは?
・どこから始めれば?
 →『塹壕より Scrum と XP』を読んだ
 →→今だと若干古いところがあるので注意

◇失敗
・Excelでスプリントバックログとプロダクトバックログを一元管理
 →プロダクトバックログのアイテムの下にインデントでタスクを並べる
・個人別にバーンダウンチャート
 →個人の遅れもばっちり把握
・フロントエンドとバックエンドでチームをわける
 →効率的な分業
・スクラムマスターがタスクをアサインした
 →抜け盛れを防ぐ
・レビュー完了はスクラムマスターが判断
 →確実な品質確保を
・詳細仕様をプロダクトオーナーに承認してもらう
 →外部仕様より先の話
・ミーティングはスクラムマスターがどんどん発言
 →進行も決定も効率的に
 →自分の意見もどんどん言う

◇こういうことをしているといろいろ変になる
・タスクの残量が把握できない
 →並べてあるから見える化
 →→全体量が分からない
 →→メンテナンスが大変
・遅れている人を問いたださないといけない
 →いつも遅れている人に余計なプレッシャー
・堂々巡り
 →「バックエンドが終わってないから画面作れない」
 →「いやいやフロントエンドが終わってないから見せられない」
・追加タスクが申告されない
 →バーンダウンチャートが増えるだけだから隠してしまう
・自分のところでレビューが溜まりすぎる
・POと話がかみ合わない
・チームから活気が消えた

◇どうなったか
・葬式のような振り返り
 →ミーティング全てお葬式に
 →→こんなはずではなかった

◇もう一度定義をよく見直した
・スクラムの理解と成立のために
 →皆のやり取りを変えてもらう
 →→スクラムチームの外側ステークホルダーに理解と行動を促す
 →→→個々の作業に関与しすぎるからうまくいかない?

◇やり方を変えた
・手法や環境へ働きかける形へ
 →作ったものや個人ではなく、全体的な視点で
・スプリントバックログは付箋とペンで
 →『塹壕より Scrum と XP』どおりにやってみた
 →→一覧性がぜんぜん違う。何が起こったかすぐわかる
・チーム全体のバーンダウンチャートのみに
 →チームを解散させたいなら個人別バーンダウンチャートがオススメ
・チームはクロスファンクションで組成し直し
・放置・滞留しているタスクに気付いてもらうように
 →「しばらく貼りっぱなしだけどどうしたの?」
 →→意外と話してくれる
 →→→フィードバックすれば自主的にやってくれる
・レビューはチームで完結
 →実施有無とレビュー観点のみ見る
 →後はチームに任せる
・詳細仕様は求められた場合のみ説明
 →プロダクトオーナーはデータベースとかに興味ない
・ミーティングへの貢献の仕方を変える
 →ゴールとアジェンダを必ず用意
 →→参加者に手伝ってもらうつもりで
 →進行のコントロールに徹する
 →→内容には干渉しない
 →→→"誰が喋るか"を決めては駄目。"誰から喋るか"を決めるのはよい

◇大事だと思うこと
・いっぱい勉強してやってみる
 →今はいろいろなところで話を聞ける
・『自分が信頼している人に見せる態度』でみんなに接する
 →ノーガードで飛び込んでしまう
 →→ガチで殴ってくる人はいない
 →チームの少々の混乱は覚悟しておく
・Be Nice
 →いい人のいいところを容赦なく真似る

◇変えられないものを受け入れる
・変えられるものは変える
 →そこはあきらめない
・判断できる力をつける







高橋 一貴様、スクラム道様、ありがとうございました。

2012年10月29日月曜日

『スクラム道 EXPO 2012 - 午前のセッション』ノート


2012/10/28に開催された『スクラム道 EXPO 2012』午前のセッションのノートです。


◆和田 卓人氏「ペアプログラミング ホントのところ」

◇質問「ペアプロすべきか?」
・答え「状況による」
 →それはずるい
 →→経験者としてそういう結論になるのはわかるが…
・ペアプロは議論を巻き起こす
・見た目も派手

◇ペアプログラミングって何?
・書籍「プログラマが知るべき97のこと」
 →「いかに周りの人とお客と仕事をするか」という中身が詰まっている
 →→プログラマは技術が優れいてるだけでは充分ではない
 →→他人との連携でより大きな成果が上げられるようでなければならない
・2人で1つのマシン、1つのキーボード
 →ドライバとナビゲータ
 →2人でコラボレーション
・いろいろなイベントではモヒカンが切りあう形になっている
 →それも面白いが…
 →チーム(ペア)でプログラミングするもの

◇ペアプロをやっている人の結論
・外国でやっている人も国内でやっている人(自分)同じような結論に至る
・やっている人とそうでない人ではイメージがだいぶ違う

◇ペアプロの利点
・規律の強化
 →1人だとサボったり、コーディング規約が億劫になったりする
 →→1人だと悪魔のささやきに負けやすい
 →→2人でコードを書いているときは天使の方が勝る
 →ペアプロ中ってtwitterやネットサーフィンをしない
 →→仕事モードになっている
 →→→仕事と休みのメリハリが付きやすい
・より良いコード
 →品質は上がっていく
 →→すぐ隣にそのコード使う人がいる
 →→フィードバックが非常に早い
 →→→それが良い効果をもたらす
 →ペアは最小のチーム
 →→シンプルさはチームが決めるもの
 →→→複雑なコードは書かなくなる
 →力技でこなす「動けばよい」みたいなコードも書かなくなる
・快活なフロー状態
 →1人と2人とでは深く集中した状態(フロー)が異なる
 →→ペアならではでのフローがある
 →→→1人のときとは異なるフローの状態に入れる
・チームの士気向上
 →ペアプロをすると部屋が無言ではなくなる
 →会話をしていくことがチームの仲の良さ
 →→情報が伝わりやすくなる
 →→→チームがよりよい方向に行く
・コードの共同所有
 →プロダクトコードに持ち主がいない状態
 →→少なくとも2人は知っている状態
 →「ある個人しか知らない」というのはない
 →→保守性が高まる
・学習効果
 →ペアプロはばらつきを一番早く吸収できる
 →→エディタ・開発環境・ネーミングなどなど
 →教える側は知識の整理などが必要
 →→教える側にも学びがある
・チームの一体化
 →チームが同じ方向に進むという方向付けがやりやすい
・割り込み削減
 →ペアプロ中の人には割り込みにくいという調査結果
・つまり…
 →教わる側は当然学べる
 →教える側は滅多なことは言えなくなる
 →→実は教える側の方が学べる

◇1人でプログラミングするのと、2人でするのとの違い
・最大の違いは"喋るか喋らないか"
 →この差は非常に大きい
 →→1人の場合、考えてコードに落として …というのをグルグル回す
 →→2人の場合、声に出すので頭の中をもう一段整理しないといけない
 →Rubber Duckingという手法もある

◇機能しないとき
・管理者はハードウェアに投資したくない
・現場がペアプロに最適化されていない
 →机の並び方など
・現場では従来型の雇用方法を採用している
 →覚悟や適正など、ペアプロに向いたプログラマーを雇っていない
・現場では反社会的な行動を大目に見る
 →コーディング規約に従わない
 →ペアプロやらなくても「プログラマはそういうものだから」で看過されてしまう
・ペア作業の生産性が理解されていない
 →「生産性が半分になるじゃないか」という管理者の意見
 →→生産性は2割増しくらいになる
 →→仕様・スキルの伝達・Better Codeなどの生産性がある
 →ペアプロにはペアプロの生産性がある
 →→なかなか理解されない
・現場では的確でない開発者を雇っている
・現場は過労と人員不足に陥っている
 →「この期に及んで二人でコードを書くなんて」
・開発者は一緒に仕事をしている人達全員を好いているわけではない
・開発者はそのような面倒なことをしたいとは思わない
・たいていのソフトウェアの現場では、優秀さのことを本当は気にかけていない

◇ペアプログラミングをエゴの問題
・角谷さんとKent Beckさんとのやりとり
 →ペアプロするとき自分のキー配列とかの好みはどうする?
 「おまえの好みとチームの成功とで大事なのはどっち?」
・ワインバーグによるエゴレスプログラミングの十戒

◇ペアプロを入れるかどうか
・結局はIt depends.
 →気に入らない人という人も一度やってみると即座に気に入る(塹壕とScrum本)
 →→(結局)8割は気に入る
 →→それでも2割には通じない

◇ペアプロは楽しい
・楽しいのが一番
 →「楽しい」はものごとを前に進めるためのプリミティブな原動力



◆吉羽 龍太郎氏「Doneの定義 虎の巻(再演)」

◇出荷可能な製品とは?
・Doneの定義
 →実施しなければいけないことの一覧
 →→プロジェクトとして定めた『出荷可能な製品』を作るため

◇(個人的には)次の単位でDoneを定義したりする
・バックログ単位
・スプリント単位
・リリース単位

◇何が出来たら完了なのかを決めるもの
・どこまでやったら終わりかが分からずにやると…
 →悲惨なことになる
 →→だからゴールを決めてからやる

◇手戻り
・本人だけできていないつもりで延々と作りこむ
 →時間の無駄が発生
 →→(ex. 誰が見るのか分からないのに、一生懸命レイアウトを整える)
・本来やっていないといけないことをやり忘れる
 →セキュリティとか考えずにとりあえず作る
 →→後でセキュリティホールが見つかったりする

◇アジャイルな進捗の判断は0 or 1
・ウォーターフォールは80%などあるが、アジャイルにはない
 →アジャイルでは、できたか、できていないか
 →アジャイルは判断が必要ということ
 →→その基準がDoneの定義
・バーンダウンチャートの数字が信用できる理由は?
 →Doneの定義に従って進めているから
 →Doneの定義がないと見せかけの進捗でごまかせてしまう

◇プロダクトバックログの受け入れ基準との違い
・受け入れ基準とは
 →どこまでできたら終わりか?を書くもの
 →→機能要件適合性の判定のためのもの

◇体験談
・悪い受け入れ基準
 →『ソースコードが綺麗なこと』
 →→あやふや
・良い受け入れ基準
 →ソースコードをCheckStyleで検証し、重要度N以上の違反がないこと
 →→全員が合意できる
・変な基準を強制される
 →品質はコンテキストに寄る
 →→金融・医療・ウェブでは異なる
 →→→社内品質基準は顧客の期待と関係ない
 →そもそもゴージャスすぎる
・守っているかどうか判断できない
・そもそも定義の中身を知らない

◇Doneの定義を守れない理由
・なぜの分析が足りない
・別の圧力に負けれる(スコープの圧力など)
・チームがオーバーコミット
・そもそもDoneの定義が曖昧

◇どうやって改善するか?
・振り返りで改善
 →プロセスが改善されることでDoneの定義が変わっていく
 →1スプリント目と10スプリント目で同じなのは逆にやばい
 →→それは、従来のウォーターフォールの書き方を変えただけ
 →プロセスは自分達で変えることができないといけない

◇Doneの定義の更新
・自明のDoneは外す
 →チームが成熟するとでてくる
 →→もっと進むと『リリースのDoneの定義』をスプリント内でやれたりする
 →→→でもやりすぎには注意

◇Doneの定義の縮小
・気をつけなければいけないこと
 →明確に守れていないものを外すのはまずい
 →→本当に顧客の期待に応えられているかを考える

◇Doneの定義充足の検証
・Doneの定義を見ればチームの技術力がわかる
 →自動化できるものは自動で
 →→より本質的なものに時間が使えるようになる

◇Doneの定義をいつ決めるか?
・見積もりや契約の前に大枠が決まっているべき
 →そうでないと工数がぜんぜん異なる
・誰が決める
 →プロダクトオーナー + スクラムマスター + チーム
 →→プロダクトオーナーは外部のステークホルダーの声も聞く
・決め方
 →必要な作業を付箋に書き出す
 →実施タイミング(Release, Sprint, etc.)でグループ分け
 →リスト化して印刷して、皆が持つ

◇荒ぶる四天王
・品質は固定パラメータ
 →スコープ達成の圧力に負けない

◇大事だと思うこと
・プロジェクト開始時点で決める
・スプリントで全部やろうとしない(最初は無理)
・チームが成熟したら拡張
・品質は固定パラメータ
・途中で縮小しない
・自動で検証
・定義をみんな知っている


◆市谷 聡啓氏「Your Mind is the Scene of Development」

◇なぜインセプションデッキ?
・プロジェクトに然るべき人が集まっているかを確認
 →いないと後で話が変わる
・プロジェクトがしかるべき方向を向いているかを確認
・「チームメンバーが誰もいないところで合意したことを前提にしているからプロジェクトがダメになる(The Agile Samurai)」

◇インセプションデッキとは
・10個の問いから構成されている

◇いつデッキを作るか?
・プロジェクトキックオフ? 最初のイテレーション?
 →それでは遅すぎる
・契約前、予算取り前
 →検討する段階で作る
 →正しい制約を作るために

◇予算が確定した後にデッキを作るにしても、プロジェクトの前提は後からは動かしにくい
・だからステルスデッキ(受注前のインセプションデッキ)
 →前提を作る
 →目的に適した制約を作り、プロジェクトを開始する

◇プロジェクト開始前・開始後で進め方が違う
・開始前(ステルスデッキ)
 →ステークホルダーにはインセプションデッキとあえて言わない
 →→相手の期待値が上がる
 →あくまで制約をあぶりだすための仕掛け
・開始後(インセプションデッキ)
 →目的を明らかにして作る
 →→プロジェクトの方向を明らかにするために

◇インセプションデッキのCRUD
・Create
 →プロジェクト開始前と後
・Read
 →最初はデッキの内容のチームへの定着を図る
 →→週一回全員で点検するなど
・Update
 →デッキの更新はプロジェクトの方向が変わるということ
 →→その認識を併せる
・Delete
 →デッキが用を成さなくなったとき

◇ゴールデンサークル
・why, how, whatの順で考える
 →インセプションデッキの前半5枚がwhy
 →後半5枚がhow
 →ユーザストーリがwhat
・howが変わる
 →インセプションデッキに影響が及んでくる
・whyが変わる
 →プロジェクトの方向が変わる
 →→ステークホルダーが認識しているかを確認
 →→→プロジェクト全体で判断し合意する

◇インセプションデッキの弱点
・whoが弱い
 →エレベータピッチの「対象顧客向け」しかない
・whyを考えるためにはwhoは必要

◇エレベータピッチ
・whoの分だけエレベータピッチを考え、作る
 →ターゲットが複数
 →→ニーズが複数ということ
・複数ニーズに対してプロダクトは1個でよいのか?
 →そういう疑問をステークホルダーと話し合う

◇やることやらないことリスト
・いきなりやらないことを出すのは難しい
・目的
 →スコープを明らかにする
 →加えて、開発への期待を明らかにするためにも使える
 →→開発の苦い経験を明らかにしてもらう
 →→ここを見誤ると、この後の開発での相手の期待がわからなくなる

◇プロジェクトコミュニティ
・誰がどういう理由でソフトウェア開発に関与するのか、気付くのは案外難しい
 →顧客には顧客組織が分かる
 →開発は開発の人しかわからない
 →→コミュニティを明らかにする必要がある
・開発のよくある役割を確認する
 →顧客に過去の開発であった役割を思い出してもらう

◇重要なこと
・練習重要
 →本番は本番の結果を出さないといけない
・質問力重要
 →良質な問いかけがプロジェクトの行く末を左右する
 →→アクションラーニングオススメ





和田 卓人様, 吉羽 龍太郎様, 市谷 聡啓様, スクラム道様、ありがとうございました。

2012年10月21日日曜日

" はてな匿名ダイアリー - 『地方の雑誌メディアの終焉が近い件について』まとめ"を作った

初まとめ。
概要やタウン誌の説明と併せて日記を時系列で並べた。

http://matome.naver.jp/odai/2135081868451032001


概要は次のとおり。

タウン誌(地域密着型の情報誌)のビジネスモデルが立ち行かなくなっていくまでの顛末を述べた『はてな匿名ダイアリー』の一連の日記をまとめました。

(中略)

強力なライバルの出現や、コアバリューを手放したことによる求心力の急速な低下など、さまざまな外的・内的要因によって、タウン誌の存在理由が脅かされていく様はとても生々しいです。

2012年10月20日土曜日

【建設予定地】『Rakuten Technology Conference 2012 - System Development, Culture and "Shikatanai" By Masa Nakamura』ノート

2012/10/20に開催されたRakuten Technology Conference 2012での、Masa Nakamura氏の講演『System Development, Culture and "Shikatanai"』のノートです。


※開催一ヵ月後を目処に公開致します。

【建設予定地】『Rakuten Technology Conference 2012 - Exploring User Wish Through Mindmapping By Kenji Hiranabe』ノート

2012/10/20に開催されたRakuten Technology Conference 2012での、平鍋健児氏の講演『Exploring User Wish Through Mindmapping』のノートです。

※開催一ヵ月後を目処に公開致します。

【建設予定地】『Rakuten Technology Conference 2012 - Design Thinking By Jeff Patton』ノート

2012/10/20に開催されたRakuten Technology Conference 2012での、Jeff Patton氏の講演『Design Thinking』のノートです。

※開催一ヵ月後を目処に公開致します。

『Jeff Pattonと平鍋健児が語る、価値創出のプロセス「ユーザーストーリーマッピング」』ノート

2012/10/17に開催された『Jeff Pattonと平鍋健児が語る、価値創出のプロセス「ユーザーストーリーマッピング」』のノートです。



◆開催概要

◇登壇者
・Jeff Patton氏
・平鍋健児氏

◇会場提供
・楽天

◇共催
・アギレルゴコンサルティング

◇提供
・永和システムマネジメント

◇本日のアジェンダ
・Jeff Patton Lecture(50min)
・Conversation! Jeff & Kenji(60min)


◆はじめに

◇Jeff Patton氏
・デザインとソフトウェアにはただ1つ正しい道は存在しないと思っていて、活動している。
 →20年以上にわたって活動
・ユーザーストーリーマッピングの考案者
 →2001年から12年以上やっている

◇平鍋健児氏
・20年以上オブジェクト指向ソフトウェア開発の経験
・10年以上アジャイルソフトウェア開発の経験
・チェンジビジョンでastahを開発して提供
・「Jeffとは長い付き合い。今日は楽しみにしている」

◇Jeff Patton氏の経歴と今日の話について
・アジャイル界ではアジャイルユーザエクスペリエンスの人だと認識されている
・80年代、美術学校に通っていたことがあった
 →ソフトウェア開発業界にいったらユーザインタフェースのデザインの仕事を任された
・ストーリーマッピングの実践について話をしている
 →12年前(2001年)から
・ソフトウェアを理解するための有意なやり方 = ストーリー
・ストーリーマップの話をする為には、まずユーザストーリーを理解してもらう必要がある


◆ユーザーストーリーの話

◇導入
・2000年、サンフランシスコでKent Beckとプロジェクト
 →xpを教えてもらった
・xpでは伝統的な要求は使わない
 →ストーリーを使う
・Kentは伝統的なソフトウェア開発の大きな問題に対してストーリーを使おうとした
 →うまく書かれていない仕様はソフトウェア開発を阻害する
 →→ストーリーは効果的にコミュニケーションするためのもの

◇ケーキの話
・cakeWrecksというウェブサイト
 →ケーキに書かれた文字を写真にしたもの
・間違った指示がどれだけ面白いケーキを作るか、というサイト
・ケーキに書いてある文字の例
 →best wishes suzanne / under neat that / we will miss you
  (underneath = 下線を引いてという指示)
 →Congraturations / Three Times
  (3回繰り返して)
 →I want Sprinkles
  (カラフルなトッピングをかけて)
→Nuts Allergy / Happy Birthday Peter
  (ナッツアレルギーです)
→Leave Blank
  (何も書かないで)
・ケーキの間違いは面白い

◇面白いではすまないものもある
・Mars Climate Orbiterという火星探査機
 →火星の軌道にのらずに爆発
・ポンドとメートルの単位換算をしなかったという失敗
 →コミュニケーションミスが原因で起こった

◇このような問題についてKent Beckは考えた
・解決策はシンプル
 →「さあ、ドキュメントを書くことはやめて、話すことから始めよう」

◇ストーリーのアイデアはシンプル
・欲しいソフトウェアのことを何かカードに書く
 →何を書いてもよい
・それを見て話しあう(conversation)
 →どんなソフトウェアが必要か正確に決められる
・"We should get together and I want to hear your story"
・ストーリーをカードに書く
 →互いに言い合うため
・書くのではなく語ろう
・アイデアはシンプル
 →だからといって簡単なわけではない

◇ストーリーのフローはシンプル
・カードには何が書いてあってもいい
1. 会話する
2. 何か気がついたら書く
3. それを説明する
4. 聞いた人は相手が欲しいものをイメージする
5. そして質問する
 →会話は質問すること
6. ユーザーとデベロッパーは理解を共有する
・"何を作るか?"を共有するということ
 →開発者が独自に想像してものを作るのとは全く異なる
・共通の理解を通じて、何が欲しいのかの理解に達する
 →ユーザー「何を作るかについて詳細に話すことはできない。でも何が欲しいのかはある」
 →デベロッパー「何が欲しいかは分からない。でも作り方を詳細に話すことはできる」

◇ストーリーのシンプルなアイデア
・動かないものを書いたり描いたりすることはしない
→Conversationする
・アジャイルプロセスでは少ないドキュメントで行う
 →Conversationして少しの絵や単語を書く
 →→そうして「何を作るのか?」という理解を促進する

◇プロセスの始まり
1. カードによるConversation
2. Confirmation
3. そしてカードを書く
 →作るものの詳細について沢山ディスカッションする
・Ron Jeffriesの3C
 →『XPエクストリーム・プログラミング導入編』に書いてある
 →→Card
 →→Conversation
 →→Confirmation

◇開発の流れはこんな感じ
1. ソフトを作り始める
2. 話しあった2人以外も見る
3. それを見てもっと話し合いこと・疑問や答えがでてくる
4. 完全じゃないことや変えたいことが出てくる
5. それをカードに書く

◇アリスター・コーバーンが言っていたこと
・「ストーリーは3枚書け」
 1枚目 : 必要なもの
 2枚目 : 1枚目をFIX(直す)するもの
 3枚目 : もう一回FIXするためのもの
 →3回書かないとストーリーにはならないということ

◇今までのソフトウェア開発とアジャイルなソフトウェア開発の違い
1. ソフトウェアを作る
2. 後から変更の必要がわかる
 →今まで:悪い要求で失敗とされる
 →アジャイル:学びとされる

◇Kent Beckが書いたこと
・「ソフトウェア開発にもっとも大きなダメージを与える最悪の単語は"requirement"である」
 ・だから話をして学び、作るべきソフトウェアについて書く、というサイクルを行う
 →問題に対するパーソナル(?)な解決策である

◇ストーリーの壁
・Conversationは2人で話しをするもの
 →「私が必要なもの」
 →「私が作れるもの」
・でも周りにはたくさんのステークホルダーがいる
 →それぞれの観点から話しをする
 →→「リターンはどのくらい?」
 →→「ビジネスの何を改善する?」
 →→「進捗はどうなっている?」
・実際にはたくさんのステークホルダーがいる

◇カードの最初のアイデア
・「カードは会話のきっかけ」
 →詳しく書くのではなく、会話を発生させるもの
 →話して出てきた詳細はカードの裏に書く
 →→でもステークホルダーがたくさんいると裏側ではすまない

◇カードは「何について話すか?」のためのもの
・図書館にある"カード目録"を考える
 →本自体は別のところにある
・カードは会話を引き出すためのもの
・沢山の人との会話の結果はカードに書けない
 →wiki, sharepointでもオンラインのドキュメンテーションに書く
 →→少し複雑。当初のものよりちょっと悪くなってしまった

◇ストーリーの大きさ
・「大きさ」はいつでも大切
・ユーザーは気に入ったものを書く
 →ユーザーに大きさは関係ない
 →開発者は正確な大きさを知りたがる
 →→イテレーションに収まるよう細かくする
・ビジネスリーダーは、ビジネスの効果が分かるものを好む
 →ロードアップにフィットするサイズになる
・ストーリーは1つのサイズで書けるものではない
 →それぞれのステークホルダーにナチュラルなサイズがある
 →それぞれに必要なサイズが違うということ

◇みんなストーリーが嫌い
・開発者なら開発できる、QAならテストなど、それぞれ自分の欲しがる形がある
 →専門家にはそれぞれのやり方があるということ
 →それぞれ必要なサイズが違う
・ストーリーの登場によって皆が同じ話しができるようになった
 →ストーリーは、誰から見ても『自分が欲しいものとはちょっと異なる』ということ
 →→皆に対して不完全になっている

◇ストーリーの大きさと価値
・ストーリーはそれぞれ価値がないといけない
 →でも1つ1つは出荷可能ではないし完全でもない
・集まって1つになって、デリバリ可能となる
・ユーザーストーリーはより小さいストーリーに分割される
 →全体になってはじめて1つの価値があるということ
・より上位の視点からユーザストーリーを見る手法が必要だということ
 
◇ストーリーと開発サイクル
1. 最初は大きな機能の話
2. 沢山の会話をして小さいパーツとしてのストーリに分解する
 →ユーザストーリをパイプライン(sprint)を通れるくらいにシュリンクさせる
3. 優先順位をつける「これは最初のリリース」「これは次」
 →ここでUIや受け入れテストなどの細かい話がでてくる
4. ここから開発者が出てきて「まだ大きい。イテレーションに入らない」
 →もっと細かくする
5. 小さいストーリーが完了する
 →価値のあるパーツ(ユーザに見せて正しさを検証できるくらいのもの)ができる
 →→でも、チェックボックスが付いた、なんてものをユーザは見たくない
6. ユーザの目からみて価値のある大きさにまとめてから、見てもらう
 →それを一つ一つ検証(validate)
7. 最後の大きな1つのソフトウェアになる

◇ストーリー = 岩みたいなもの
・割ると沢山の岩になる
→でも頻繁には砕かない

◇ゲーム : アステロイド
・ルール
0. 宇宙を岩が飛んでいる
1. 岩を打つと砕けてあちこちに飛んでいく
2. 砕けた岩を打つと、それもくだけて飛んでいく
3. 何回か細かくすると石は消滅する
4. そうやって全ての石(岩)を消滅させればおk
5. 岩にぶつかるとゲームオーバー
・このゲームでは、大きい石を何回も打つのは悪いやり方
 →小さい石がたくさんでてきてすぐゲームオーバー
 →大きなストーリを早いうちに細かくくだくのも同じ

◇ストーリーは素晴らしい発明
・Conversationで共通の理解をするためのもの
・書類は間違いがち

◇ソフトウェア開発でもっとも難しいもの
・「そもそも何が作りたいのか」ということを理解すること
 →フレデリック・ブルックス(人月の神話の人)が言っていた
・コミュニケーションは難しいがそれ以上
・「何を作るか」と言うことは「人が欲しいもの」「作るものが何なのか」を理解すること
 →それが一番難しいこと


◆ユーザーストーリーマッピングの話

◇ユーザーストーリーマップとは何か

左右:Workflow ワークフロー
上下:Details 詳細やオプションとなるストーリー



・構造上の特徴は2つ
1. 左右はユーザの視点からみた物語
2. 上下はバリエーションやオプション
・一番上が一番大きな岩
 →話の背骨になっている
 →細かいものはその石に紐付けられて下にいる
・上(ユーザのアクティビティ)
 →タスク(背骨)をいくつかまとめたもの
・書いて動かしているうちに会話が生まれる
 →それが重要
・マップができるということは会話ができたということ
 →マップは会話の足跡
・マップにシールでタグ付けすることもできる
 →リスクに対する評価や、やる/やらないなど

◇ユーザーがストーリーマップから見るもの
・「この機能は2日」とかそんなものは見ない
・ユーザーはもっと大きなストーリーの流れを見る
 →使っている様子が分かるように書く
 →→そこから会話が生まれ、Detailsに新たなカードが加わっていく

◇ストーリマップはシンプルさを保っている
・ストーリマップはとてもシンプル
 →そこに何を書いてもいい
・「UMLにして他の情報かけるようにしろ」という人もいる
 →そうはしない。そうしてシンプルさを保っている

◇ストーリーのスライス
・基準となる線を用意し、ストーリーを上下にスライスする
 →スライスにカードを割り当てその中でカードを動かし、各スライスのゴールを決める
1. 機能単位で分割線を引き(スライスの作成)、ストーリーを各スライスに割り当てていく
2. 重要な機能のスライスからこなす
(3. スライスが完了すれば、ユーザに価値のある大きさで提供ができる)

青い線がスライス


◇ユーザーストーリーマッピングとは何か?
・ストーリーはバラバラになるので、以下の難しいことをやる必要が生じる
 →全体を考える
 →小さいものを組み合わせて1つにする
 →→これは難しい
・これも難しい
 →全体としてどういう機能があるか
 →細かいアイテムってどういう価値があるものなの?
 →→バックログアイテムを細かく見ていくときにここで苦労する
・解決策としてストーリマッピングを提唱している

◇世界中から写真を送ってもらっている
・いろいろな世界から「クールだろ」と写真が送られてくる
・本どおりではなく、それぞれにあったやり方でやっている

◇平鍋さんの気付き
・ケントベックが提唱していたストーリーとは
 →話すこと
 →「As a xxx In order to...」というフォーマットのことではない(それが悪いわけではない)
・アジャイルに見せるときに、ビジュアルが持っている強さ 






Jeff Patton様, 平鍋健児様, 永和システムマネジメント様, ・アギレルゴコンサルティング様, 楽天様、ありがとうございました。

2012年10月19日金曜日

【チラシの裏】【201203】勉強会に参加するようになって1ヵ月後に書いたメモ

 過去メモを掘り返したら出てきた。2012/03辺りのもの。書いた細かい日時は残ってない。

 メモなのでまとまりがなく、全体としてふわっとした仕上がりになっている。「勉強会からどのように/何について影響を受けるか?」という点について思ったことを表現すべく言葉を繋いでいるのは自分でもなんとなく分かる。

 いろいろと思うところや、突っ込みを入れたい箇所などあるが、「半年前の自分というのは、半分くらいは他人みたいなもの」と考えれば、まあ別にいいか…


~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

 いろいろと考える概念や方法論などがあり、それらを学んだりしているわけだが …自分の中の大局感がなくなってる感じがしない?

 何かについて考えているとき、1つ粒度を上げて考えて見ると、 物事ってもっと自由に …というか、1つ下の粒度で見てるときより明らかに手札が沢山あることに気が付いたりするんだけど、今の自分って見てる粒度が若干小さすぎるんじゃない?

 「こういう技法があって、それはこういう考え方で、こういう手順で」 …というのをただただ積み重ねても、よいソフトウェアにはならないような気がする。もっと根底にある大きな価値観みたいなものを常に意識して、何か判断に迷うようなことがあった場合にそこに立ち返ることができなければ本当の意味でよいソフトウェアを作るところには至らないというか。

 ただただ良い方法論のかたまりだけ、見たいな人間になっても、それでできあがるエンジニアっていうのは哲学的ゾンビ的な何かにすぎないような気がする。

 …なんでこんなこと思ったかというと、大まかに2点あるような気がする。ここ一ヶ月で20個いかないくらいの勉強会に参加したのだが、だんだんメモを取る理由が判らなくなってきたのだ。

 というか、「言ってることは大まかに同じじゃない?」という気がしてきている。勿論テーマやそこで学んでいる内容は全然違うのだが、勉強会が持っている(そしてそこから私が受ける)影響っていうのは、源泉を辿っていくとすべからく同じところに繋がっているような気がするのだ。そこさえぶれなければ、後で好みの問題でしかないっていう。

 あと、Jonathan Rasmussonの話を聞いたのは大きい。彼の書いたアジャイルサムライは読みやすいし、人を鼓舞するような何かがあって、あの本はそういうものでできあがっている。そんな本を書いた彼の話を聞いていて思ったのは …本の背景(彼の頭の中や考え方)には、あの本に記載されていることの何倍も複雑な考え方や人間性があり、それは一冊の本(その中には一貫性があるようにという縛りがある)の持っているコンテキストに即する形で、ほんの一部だけが文面に織り込まれているのだということ。

 彼の話を聞いていると、本に書いてあることについての意図や、ベースになる考え方など、本当に奥行きがあることがわかる。まず、そういうものが彼の中にある。で、それを踏まえて、読み手に適切な印象を与えるために、彼の中の引き出し(本人が知っている知識だけではなくて、感情に働きかけるための書き方なども含めて)を選んでいるのだな、というか。

 だとしたら、本の内容っていうのはただ鵜呑みにするのではなくて、その背景にある著者の人間性や、その本が参照している源泉(さっき言ったよね?)が、何なのかっていうことを意識して知るように努めなければ、読む意義って実はあんまりないんじゃないですか? っていう。

 「知識を集めるのが目的で、カタログ的に読めばいいよね?」っていう読み方は勿論あるけど、「もっと深いところまで感化されるっていうのが本質じゃない?」っていうのが上の考えから導かれた、私なりの本の読み方ということになる。

 で、技術書って読み方に慣れてくると、そこにある考え方や方法のエッセンスを抜くのがうまくなったりするんだけど、もっと源泉のところも同じように読み取るコツがあるのではないかな?とも思う。

 今回は"Agile Japan", "Agile do it!", "Agile Samurai Dojo Gathering"という3つイベントに参加でき、また一ヶ月みっちり勉強会に参加し、それだけの時間を通して学び続けた。その中で、上記のような認識に至るくらいの影響を受けた。

 この、私が影響を受けたところっていうところに関して、もっと私の認識が見るかされていて、「自分が何について影響を受ける感じになっているのか」という点、私自身が自覚的であれば、もっと効率よく影響されることができるというか。

 こういう言葉にならないようなところを、影響受けるようにはどうすればいいのか? っていう。よくよく考えると無理なような気もするけど、突破口になるような概念はあるんじゃない? っていう気もしている。



~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~


また半年後くらいに見返すと、いろいろと思うことなどあるのだろうなー。

2012年10月9日火曜日

『SIエンジニアの自分戦略 -急がば回れ、選ぶなら近道-』ノート



2012/10/09に開催された『SIエンジニアの自分戦略 -急がば回れ、選ぶなら近道-』のノートです。

SIをやっている人には是非読んでほしいです。私のノート作成スキルを割り引いてもさておいても …です。

※(2012/10/10追記)上の文について、言葉の選び方が不適切だったので修正致しました。「私の資料作成能力の限界で、okachimachiorz1様の伝えたいことの半分も伝わっていないかもしれない。だけど、それでも読む価値がある内容です」ということが、上の文で私が言いたかったことです。申し訳ないです。


◆今日の勉強会について

◇今日の構成
・最初にokachimachiorz1様の話を40分くらい
・その後休憩を挟んで来ている人達で感想、深く聞きたいということを皆で話合う
・Q&A

◇この回をやろうと思った経緯
・okachimachiorz1様のブログを一生懸命呼んでいるうち、その内容が自分の仕事の話になっていた
・自分が危機感を持てる内容になっていた
・そういう文を書く人の話を聞きたいと思ってお願いした


◆本編

◇はじめに
・どちらかというとAsakusaやHadoopの人
・SIの話ははじめて

◇自己紹介
・元々はITの人ではない
・ハゲタカファンドの人だった
 →バブル崩壊後、日本が買い叩かれたときに買い叩く側の仕事をした
・次に上場している流通企業でCIO, CTOをやった
 →ユーザ企業のインハウス
・その後ウルシステムズ
 →コンサル・SIでは食べられないので業務系のミドルウェアを作って売っていた
・キャリアとしてはマネジメントの方が長い
 →働いている人の給与・コストを考えざるを得ない立場である
 →自分も手は動かしているが、どこでも人件費の問題に突き当たる

◇エンジニアのキャリアは難しい
・前の会社では優秀なSEをコンサルにしていた
 →前の会社にはエンドとしてのエンジニアのキャリアがないということ
 →→NAUTILUSの設立にはエンジニアのエンドのことも考えている

◇日本の現状
・年寄りが増える
 →勉強していくことが必要だがそういう人も少ない
 →年を取るとアウトプットが減っていく(手を抜かないと体が持たない)
・社会的コストが増大する
 →公共事業で景気維持というスタイルを20年続けている
 →公共事業には立法が必要。単年度単位で行う
 2~3年後のことは誰も考えない(ランニングのコストは考慮されない
・結果とつじつまが合わない
 →ランニングのコストが考慮されていない社会インフラ(情報システム)が残り続ける
 →橋などは壊れるが社会インフラ(情報システム)は壊れない
・人口が減る
 →総生産が減るので売り上げが減る
 →→利益の確保に走る
 →→コスト削減
・これらが社会全体の流れ

◇年金問題
・スキームとして成立していない
 →払っても戻ってこない
 →若者には遠慮しない
・消費税の増税
 →5%には直間比率を変えるという名目が合った
 →8%, 10%の増税にはそれがない
 →所得がそのまま減少する
・「都内で一家を構えて、嫁さんと子供を食べさせるには …額面年収1000万+貯蓄5000万ないと厳しい」

◇ITサービス産業について
・ユーザ企業におけるITエンジニアの就業人口について
 →米国は他国と比べて圧倒的に多い
 →日本はベトナムやロシアと比べると多い
・しかし給与は相対的に低い
 →IT業界は人が多すぎ
 →IT業界は給与が安い
 →→これが世界と比較した場合の現状

◇プログラマの生産性は低い人と高い人で10倍以上違うという
・これは本当だと思っている。実際にある
 →だからできる奴の給与をあげろ、と言われる
 →そうしないと携帯ゲーム業界に行ってしまう

◇本当にそんなに生産性が違うのか?
・他の業界ではそう言われない
 →会計士
 →流通
 →→SIと同じ労働集約型の産業
 →→あっても生産性の差は3倍くらい
 →→→そんなに差はない
・そもそも労働集約産業で10倍もずれたら商売にならない
 →これは異常
 →でもIT業界では散見されている
 →→COBOLでは10倍もなかった
 →→そして今はもっと開いている

◇なぜそんな差が?
・能力が高い = 生産性が高いのは事実
 →できる人の設計やコードは別格
・そもそもばらつきが酷い
 →言葉がでないくらい
 →→それは参入障壁がないから
 →→その辺の人を連れてきて書かせたりすることが普通にある
 →→「なんでこんな人連れてきたの?」「10人月で計算しているんで…」
・優秀な人の生産性が高いというより低い人が多すぎるのでは?
 →「これはないよね」という(酷い)コードを見たことがない人はこの中にはいないと思う
 →→差が非常に激しい

◇これはよろしくない
・いい人の足を引っ張ると言う話ではない

◇では、この状態を経営者層はどう考えるか?
・経営者層はできる奴の給与を上げたりはしない
・経営者層はできない奴に合わせる
 →下の給与を下げるか首を切る
 →できる奴の給与も適当に据え置く
 →→人間の給与はモチベーションでは上がらない。むしろ劣る
 →→ライバルが上がるとモチベーションが落ちるが、自分が上がってもこの程度か…としか思わない
 →→マネジメントは一斉に上げるしかない
 →→→できない奴を入れると全体が上がらなくなるということ

◇SIは基本的には成り立たない
・人が多すぎて給与が安い
 →人力の大規模SIに頼る現実はなかなかなくならない
・だが若年層人口が減っている
 →労働集約的産業は行き詰っている
・人件費の扱いを考える
 →一人当たりの賃金が上がる要素はゼロに近い
 →経営者はできるSEの給与を上げたいと思っている
 →でもできない。現実にはそうせざるを得ない
 →→大規模SIを商売にしているところはそうなってしまう
・NAUTILUSが小規模なのは給与を上げやすいから
 →積極的にそういう選択をせざるを得ない時代になっている

◇SIの現実。マーケットの現状
・単純な売り上げ増をSIで稼ごうとする
 →一度こちらに振ると脱却が難しい
 →特に上場会社
 →→右肩上がりの成長圧力がある会社で顕著
・ユーザ層は内製したいというが…
 →結局は丸投げ
 →→ITは彼らの本業ではない
 →→外部から調達すればよいという考えがある
 →だからといって無くてよいわけではない
 →→だが、そういった社内の声があっても実際には入れられない
 →→ITは間接部門なので真っ先に切られる立場
・需要と供給がこの中途半端な状態で成立している
 →どちらもお互いのことを考えてない
 →市場をよくしようというモチベーションが薄い
 →お互いのビジネスモデルを理解していない
 →→結果として成立しているだけ
 →→この市場は、なくなるときには簡単になくなる
・マーケットを維持しようとするインセンティブなプレイヤーにない
 →崩れても持ち直そうとする人がいない
・かなり厳しい

◇参入障壁を上げて、できる人でやろうとすればよかった
・でも、人でスケールアウトするモデルをとってしまった
 →にっちもさっちもいかなくなった
・どうすべきか真剣に考えないといけない
 →SIが行き詰った後どうするのか?
 →そのとき何をかけるか?
 →そもそもかけるものがあるか?
 →手持ちの札をどうふやすか?
・↑がSI系のエンジニアには必要になってくる

◇私は何をやったか?
・いいエンジニアの受け皿を作ろうと思った
 →こういう会社がもっとできるべきだと思っている

◇マーケットはどう変化していくか?
"SIは終わコン"という説がある
 →同意する
 →だが0にはならない
 →現状は覆らない
 →だが縮小する
・単純な投資の先送り
 →中規模・小規模SIの増加
 →→投資余力の減少から規模の縮小が始まる
 →見積もりをミスると赤字がどんとでる
 →市場だけで決めてしまうので不経済が発生している
・先送り案件が増えると
 →投資自体がシュリンクする
・運用や追加補修の増加

◇少ない人数でどう回すかを真剣に考えるべき
・100人月を80人月でとか
 →アジャイルは答えではない
 →どうムダなくやるかをユーザと話をして、説得できないといけない
 →→ミスなく効率よくできないと駄目
 →そのためには個々人のレベルが高くないと駄目
 →→1人1.5役くらいやらないと厳しい

◇私が関わったプロジェクトの9割は失敗していた
・でも、できるPMが複数入ってサポートすると成功する
・エラーを摘出して修正するスピードが速いプロジェクト
 →そういうのはリスク管理ができる
 →excelの表に書いてリスク管理とか本当に意味ない
 →報告書を書けばリスク挙がってくるの?
・実質的なリスク管理は1人ではできない
 →その人よりレベルが高い人が見ないと分からない
 →そういう人が見て気付くだけでも全然違う
 →→だから、皆でやって壁に貼ってというアジャイルのスタイルは良い

◇業務系のニッチな仕事が増える
・ユーザが丸投げできなくなっていく
 →仕事を切り分けて出すようになる
・ちょっと間違えると大変なことになる
・流通は死亡率が高い
 →一見簡単に見える
 →でもそのとおりやっても業務は回らない
 →→それは例外処理の塊だから
 →→その取り決めのルールが非常に多い
・知らずに入ると大変なことになる
 →業務知識が必要になる
 →エンタープライズの例外系を知っている人がいないと厳しい
 →→厳しいけど、そこできっちり回るならエキサイティングで楽しい仕事ができる

◇手持ちのチップは充分か?何が必要か?
・1枚の最強のカードは「複数の"最強-1"のカード」には勝てない
 →最強のカードには沢山のコストがかかるが"最強-1"は実は真面目にやればいける。
 →最強の手前を目指す
 →スーパースターになる必要はないが、複数の組み合わせでいけば強い

◇チップ
・この中で複数あったら強い
→設計
→アーキテクチャ
→アプリ
→インフラ
→運用
→基礎技術
→業務系ノウハウ
そういう人がいたら欲しいでしょ?

◇エンジニアとしてのキャリアパス
・日本だけで最強を目指しても仕方がない
 →それはガラパゴスになってしまう
・90点を100点にするのではなく、30点を90点にする
 →50点では妥協しないが、100点は目指さない
・それができなかったら?
 →給与も上がらないし、SIの現状がこんなもの
 →→転職したほうがよい

◇経験知として
・歴史は繰り返す
 →汎用機->オープン->クラウド
・繰り返すたび、車輪の作り直しになる
 →作り直す必要はあるか?
 →でも作り方は知っておいた方がよい
 →知らなくて作るのは最悪
・流行に飲まれるな
 →Hadoop. HTML5, 関数型…
 →1回退いた上で自分なりに咀嚼し、「目的を持って」取り組むこと
 →何のために必要? 何のために使う?

◇何もしないとどうなるか
・実質的所得が下がる
 →税率とかで
 →これは決定的
・SIビジネスが縮小する
 →「モチベーションが上がらない」とか言ってられなくなる
 →あと5年以内に、「食べていけるのか?」というレベルになる
 →→消費税の5%は半端じゃない。手取りがざっくり減る

◇今までと何が違うのか
・座っていても大丈夫と言う時代が本当になくなりつつある
 →大企業でも倒産や合併の憂き目にある
・SNSなどのつながりで情報の流れが早い
 →自分の状況がわかる
 →選択肢が広がる
 →競争相手が日本全体になっている
 →→今までは会社だったけど、そうではない
・企業の壁が薄くなっている
 →個人を守れなくなっている
・個人は
 →モチベーションをどうするか
 →自分の能力をどう評価するのかが非常に重要になる


「自分で作らないと、夢も希望もない」


◆何をカードにするか

◇設計
・普通の設計ができるようにしておく
・画面・データモデル・バッチ
・正常系は馬鹿でもできる
・例外系が重要
 →やりすぎるときりがない
 →やらなくても死ぬ
 →程度を抑える
・きちんとした設計なら設計時点でパフォーマンスがわかる
・適度にやる感覚を理解する

◇アーキテクチャ
・全ての基本はI/O
 →どうすれば限界まで出せるか
 →どこがボトルネックか?
・障害のことを考えていないI/Oが多い
 →ここは性能とトレードオフになる
・今は(一般的に)複雑すぎる
 →どこで何をしているかがわかるアーキテクチャが作れると強い

◇アプリ
・ただ書くだけではない
 →wfで設計・実装・テストできる。こういう基本的なことが大事
 →書く量をコントロールしないといけない
・みんな書きすぎる
 →書かない技術を極めたほうがよい
 →リファクタリングしている暇なんか普通はないよ?
 →→最初から少なく書く
・コードから手をどう放すか、ということを常に意識する

◇インフラ
・とにかく情報収集
 →すごい勢いで変わる
 →仕様、マニュアルが変わる
・基礎技術を押さえる
 →物理階層
 →プロトコル
 →設計
 →障害
 →パフォーマンス
 →セキュリティ
・最後はI/O
 →パフォーマンス
 →対障害
 →→追えるように

◇運用
・できると強い
 →一度は経験すること
 →今まで見えなかったものが見える
・継続的なインテグレーションのマスター
 →システムは使われてなんぼ
 →生きているシステムはどんどん変わる
・コスト意識を持つこと
 →運用コストは馬鹿にならない
 →分かると非常に強い

◇基礎技術
・計算は絶対
 →計算量の計算ができないとか…
 →確率・統計を知らないとか…
 →→高校生~大学生レベルでいいので抑えておく
・品質
 →昔よりは言われるようになっている
 →品質 = テストではない
 →→もっとトータルなもの
 →出来上がるものではなく作りこむもの
 →→「予見可能性が高いもの(どういう挙動か分かりやすいもの)」が品質が高いと考える
 →→バグの量は関係ない。バグがあることが明確ならそれは品質が高い
・論文
 →すらすらじゃなくても読めるようにしたほうがよい
 →我々は巨人の肩に乗るべき

◇業務系
最終的にはエンドユーザには絶対に勝てない
でも(業務知識を)盗むことはできる
・考えることが大事
 →なんでこういう仕様に?
 →→何か理由がある
 →前提の基礎知識は知っておく
 →→会計なら簿記
 →→最適化ならORとか
・聞く
 →とにかく聞く
 →捕まえて聞く
 →→「こうなってるはずだと思うんですけど?」と聞くこと
 →→「どうなってるんですか?」ではない
・応用する
 →業務知識は仕様ではなく考え方。文化
 →"アカウンティングのセンス"みたいなものがある
 →→そのセンスがある人が見たときに、どう考えても直感的におかしいものとか
 →→会計のマインドがあれば全員が分かる。「これは筋が悪い」
 →そのセンスを何とかつかむ
 →→なんでそうなっているかが分かるようにする
 →その根底にある考え方を常識にとらわれず転用する
・これをやるだけでお客様の信頼が全く違う
・そうすれば、ヘルプで入っても見た瞬間に「これがおかしい」と分かる


◆質疑応答

Q.
非常に大きなユーザ企業の仕事は、少数精鋭の規模では請けられない場合があると思う。
そういうものを受けられるようにし、成長していくためにはどういうことをやっていけばいいのか?

A.
・原則からいくと受けないほうがよい
・少数精鋭がそういう仕事を受けに行くのは自殺行為になる
・どういう形態なら受けられるかということを話し合うべき
 →ユーザが「そういう発注はできない」というなら受けない
・「大規模SIが成り立つか?」と言うこと自体をユーザが考えないといけない
 →だってほとんどが失敗している
・大手ですら、ユーザからの内示が出た後に拒否するケースが出てきている
・そもそもユーザが大規模の案件を発注するのか?というのもある
 →インクリメンタル
 →パーティション
 →サービス
で発注するとか


Q.
大手だからまっとうな経験が積めないわけではないし、そこでしかできないこともある。
でも、配属によってはまともな経験ができないことがあって、そういう人はSIが無くなると死んでしまう。
そういうことを考えたときに大企業の中にいる人は何をすべきなのか?

A.
・中でちゃんと提案すること
・喧嘩別れは簡単
・「このままでは具合が悪い」ということを、個人ではなく部の意見としてきちんと話をする
 →1人の意見で話をもっていっても「お前が言っているだけ」で終わる
・部の意見なら、経営層も話合う力量がある
 →話し合えないなら全員辞めればよい


Q.
「マクロで見たとき日本でSIやるのは厳しい」というのがここでのコンセンサスだと思う。
生き残りの作戦として、エンドユーザに入ってITを軸としたイノベーションを起こすというのはアリだと思うがどうか?

A.
・そうだと思う
・でも、ユーザサイドから見るとそういう人のモチベーションを維持するのは難しい
 →ITの投資は景気が悪くなると真っ先に削られる
 →努力が簡単に否定される
 →→それでもモチベーションが維持できるか?という問題
 →→→それでも頑張れるのであればエンドユーザに行くのはありだと思う


Q.
(上の質問の続き)現場上がりの人がCIO, CTOになっているような会社を探せばあるのではないか?

A.
・ユーザにはR&D部隊があるようなところにいけばあるのでは?
・でも「まずは現場に行け」という話になる
・ある例
 →技術のある人間をまず現場に送った
 →彼は棚卸しをさせられた
 →結局2日で辞めてしまった
・中の人間とある程度コンタクトをとって、中の情報を取って行く
 →オーナーやトップがきちんと見ているということがカルチャーとしてあるか。
 →それから現場としてどうなっているか。
 →→そういうことを調べてから行くならよいのでは?

Q.
アメリカはユーザ企業の比率が高いと言う話があった。
でも、それは解雇が簡単だから開発フェーズごとに人数が変えられるという話。
日本では、開発のフェーズごとに人数が変わるところをSIがバッファしているというのがある。
ここの問題を解決しないと、シュリンクするSI業界に人材が取り残されて給与だけが下がっていくと言う状態になるのでは?

A.
・USがインハウスであれだけ人を取れるのは人材の流動性が高いから
・では日本ではどうなるか?
 →別の業務をさせる(製造業なら現場とか)
・ただ、IT系で優秀な人は違ってくる
 →会計・流通と比べてIT系で違うのは、どこでもプロジェクトマネジメントをやっているということ
 →ユーザは驚くほど線を引かない
 →→それをやるだけでもかなりプラスになる
 →IT企業にはそれがあるが、それをユーザに提供していないのが現状
 →ITできちんとやれる人は企画系(スタッフ)なら力を発揮できる
 →→きちんとしたマネジメントならそう考える
・でもそういう枠が沢山あるわけではない


Q.
SIがシュリンクしたときに取り残されたユーザも困る。そのときのユーザの出口は?
SIが倒産したときにユーザはどうすればよいのか?

A.
・エンドユーザがそういうときどうするか?
 →引き抜きにかかる
 →人ごと受ける
・それは今まで払ってこなかったコスト
 →「これだけかかる」「もうどうにもならない」ということを社長に話す
・こういうときに外部不経済が発生してしまう
・『基幹系で先遅りしてベンダとべったり』だと、それが原因で倒産することもありえる
・お互い打つ手なしと言う感じ


Q.
そもそも情報工学に人気がなく、内定がない人がSIに入ってきている。
SIとして質を上げるためには何をすればよいか?

A.
・まずはそういう人を取らない
・きちんとテストをやるとか
 →三角形のテストとか、だいたい書けない
 →→書ける人からとっていけばよい
・論理的に考えられ、日本語が書けて、でたらめでないコードが書ける
 →それでよい
 →後は2年間教育に放り込めばなんとかなる
・テストして適当な人がいなければ取るべきではない


Q.
ユーザ自体にお金がない。でもシステムを構築したい。
こういう場合、結果的にダンピングされる。
ユーザ「来年の予算は決まりました」
会社「受ければこれだけの利益になります。だからやれ」
で、いくつかのプロジェクトで赤字になったりして会社からいろいろ言われる。
どうすれば?

A.
・やるべきではない
 →お金がないけどやってくれというのをやるのがそもそもの問題
 →上が「やれ」というなら「赤になるぞ」ということをきちんと言わないといけない
・赤字は赤字
 →自分の手足を食べているというだけの話
 →それを下に投げている時点で経営層失格
・お客様との付き合いとして取らないといけない場合
 →それは投資
 →どこで回収するかをきちんと決めてもらわないといけない
・赤字だからダンピングでも受けてしまう
 →そうやってきたのがSIがこうなっている原因でもある
「赤字になってどうするかを考えるのは自分の仕事ではない。俺はその分の給与を貰っていない」と言ってよい





okachimachiorz1様, DevLove様, 日本マイクロソフト様、ありがとうございました。