薄まる自分
PCやら育児やら、徒然についてメモります。
<< February 2012 | 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 >>
 
デル株式会社 ブログパーツ
RECOMMEND
RECENT COMMENT
RECENT TRACKBACK
カウンタ
ブログパーツUL5
JUGEM PLUS
MOBILE
qrcode
PROFILE
PR
無料ブログ作成サービス JUGEM
 
スポンサーサイト

一定期間更新がないため広告を表示しています

- | | - | - | - | - |
アジャイルサムライ読書会 in 横浜道場(2回目)に参加した。#agilesamurai #横浜道場
 読書会というのにも参加したことなかったのに、初めて参加した読書会で、開始10分後には
ワールドカフェという知らない形式で議論をしていた前回…。

今回は、前回、全く本に触れなかったことを反省として?輪読して、ディスカッションを行うのセッションを
同じチームで繰り返し4回行った。

チームを最初から最後まで固定することで、メンバの方々のキャラが分かってくるという面があるものの、
やはり、意見が多少似通ってしまうというところはあったかもしれない。

しかし、この輪読+ディスカッションという内容はよかった。
声に出して音読というのは本当に久しぶりにやったが、改めて1行ごとに内容を吟味することができた。

今回のチームはNo.4で、4名+スタッフ1名構成で、その中の3名が割とSIerに縁が深かったので、
SIer色の漂う議論内容となった。

例えば、「本当にドキュメントと予算をだけを求めている顧客もいる」

「顧客に本当に価値のあるソフトウェアを届けるんだ」の対偶だったり。

発注側と受注側って本当は対等の関係なのに、間違ったお客様は神様ですみたいに絶対的な序列のある関係になることが多いよね〜。
みたいな議論があった。

確かにそうだ。

3つの真実
1.プロジェクトの開始時点にすべての要求を集めることはできない
2.集めたところで、要求はどれも必ずといっていいほど変わる
3.やるべきことはいつだって、当たれられた時間と資金よりも多い

というのは、話を聞けばみんな納得するんだけど、会社の中や、お客様との間の関係においては、
真実なんか無視して、計画通り実施し完了するのが真。要求は見積もり時点に出ているものが
そのまま解決されていること。とか、みたいな事になってしまったりするのは今でも平気である。

それによる弊害はやはりソフトウェア開発がナチュラルなのもでなくなり、不自然なものになっていったりする。
そうすると、開発者にとっても不幸なことにしかならない。

アジャイルサムライを読んでアジャイル開発の話を聞くと、一般的な受託によるソフトウェア開発に比べて
大変だけど、顧客が得たいものに近いものをデリバリできるような気がする。

SIerによるウォーターフォール開発でもそれがきちんと回って、きちんと開発できていればよいんだろうけど、
世の中との軋轢が高まっていて、競争力がどんどん低下しているのが昨今だ。

今日の議論でも、プラクティスはあくまでもこれまでのノウハウであって、銀の弾丸ではない。
成功するたった一つの方法というのはなくて、自分たちで考えて、自分たちのプロセスをまわすしかない。
というのがあった。
自分の会社でもアジャイルな開発をできるような日が来るのかわからないけど、
勉強会に出つつ、いつきても対応できるように、プラクティスを徐々に今のウォーターフォール的な
開発に適応しつつ準備をしていきたい。

次回のアジャイルサムライ読書会 横浜道場は3/8であることが濃厚らしい。
3/8はすでに何かのイベントにエントリしているので出られるかどうかあやしいけど、
なるべく出るようにしたい。

今回、出席して思ったけど、横浜道場は、アジャイルをバリバリにやっている人というのは少ないけど、
それだけに一見さんお断りみたいな雰囲気がなく、アットホームな感じがよいと思う。

次回は第3回の読書会で、おそらく輪読+ディスカッションだろうけど、第1回、第2回に出ていない人でも、
すっと入ることができるだろう。

ということで、次回は会社のメンツを誘っていきたいと思う。(いけるかわからないけど)

最後に、スタッフの皆様、本当にありがとうございました!
お疲れ様でした〜。

2012/02/16 デブサミ2012【16-B-1】極上のSI戦略 講演メモ #devsumiB
 デブサミ2012 2/16【16-B-1】極上のSI戦略 の講演メモです。
まとまってなくて、長いです。

極上のSI戦略

発表者:ウルシステムズ 漆原 茂 氏

お客様のビジネスを動かすSIは格好いい!
エンタープライズ開発は格好いい!!
10年前と比べてユーザ企業も技術者を欲しがっている。

■SIの問題点
・SIは失敗する(ことがある)
・大規模SIは儲からない
・小規模もっと儲からない
・開発者のスキルにばらつきがある(オフショアは典型例)
・単金のデフレが起きている
・品質が低い。価値が低い。

■極上のSIを目指して
・極上のSIとは何か?
 ・大型案件?儲かれば?最新技術を使えれば?自社製品売れればよい?
   検収がもらえればよい?
 →そうではない

■エンタープライズ開発の醍醐味
 ・顧客企業の命運がかかる。
 ・多くを任される
 ・期待が大きい
 ・ステークホルダーが多い
 ・ハードルが高い。プロフェッショナル分野
 ・業務知らないと大変
 ・技術知っていることが前提
→企業の命運がかかり、業務に直結して難しいことを開発するのが
  エンタープライズ開発であり、それが醍醐味。簡単なWebサイト開発などではない
 
■嫌なこと
・顧客評価が低い/顔が見えない
・多重請負い構造/日雇い派遣
・大量の人月で薄めて丸投げ
・商社的物販/作為的コンサル(開発取ること前提のコンサル)
・質が低い。年収低い
・過剰労働。無責任、他責にしたがる

■何故、そうなるか?
・受注型のビジネスモデルがそうだから
 ・人月の膨張を成長と勘違い(案件がでかくなって売上あげればよい)
 ・受託開発のリスクヘッジのために
   ・下請けに丸投げ、顧客への責任の押しつけ
 ・多重請負い構造
 ・無理な受注

■これらの真逆をやれば、どうなるのか…。
・人月拡大を狙わない。売上は追わない
・顧客満足優先、売上は後からついてくる
・品質、技術に徹底的に拘る
・アサイン兼務なし(1案件に100%):難しいエンタープライズ分野の開発だから兼務なんか無理
・外注や初心者で薄めない
・単金は下げない

これらをやるには経営者として覚悟が必要(ウルシステムズでは2002,2003の時期)
大きくわけると次の3つになる。
(1) 案件の「取り方」を全面的に変える
(2)「やり方」を変える
(3)「人事評価」も変える

(1)案件の取り方
・プリセールスに十分時間をかける。
  1年とか平気でかける、業務をよく知っていないと難しい開発はできないから、お金は取らない。
・顧客をよく知るための時間を投資
 ・「営業」ではなく、自分たちでやる
・提案内容で妥協しない
 ・言われたとおりに提案しても勝てない。顧客の考えを超えるような提案をする

(1)続き
・取らないものを決める
・プライム以外断る。普通な(誰でもやれそうな)案件も断る。
・正しいメンバがアサインできなければ、涙をのんで断る
 属人性は当然出る。〜がアサインできないので受注できない。
・理不尽に値切られるなら、涙をのんで断る
・こちらからの条件があわなければ、大泣きして断る。
 ・無理してとってもうまくいかない

(2)やり方を変える
・少数、プロパ純血主義でやる
  技術力の高いメンバじゃないと仕事をまわせないから、新人はあまり採らない
  採用するときにも徹底的にフィルタリングする。社員を成長させる。
・品質、技術に拘る。
・案件に100%アサイン、兼務なし
・効率良いコード、しっかりテスト
・先端技術にどんどんチャレンジ(例は、とてもOracle などのRDBMSでは全く間に合わないような
  データ処理をDataGridをつかうとか)
・生産性に拘る
・顧客と一蓮托生となる

(2)(続き)やらない事を決める
・パートナーに丸投げしない
・プロパを3割以上薄めない。(Maxでプロパ:7人、パートナー:3人など)
・言われたとおり開発しない
・意味が無い開発は全力で阻止する(システム開発をしない提案もする)
・他責にしない
・知ったかぶりしない、どんどん偉い人、怖い人にも聞く(業務を知るために)

(3)人事評価を変える
・顧客からの評価優先
・技術スキルに加え人間力を重視
・優秀なPM、プログラマを同等に評価
・年収1200万円のアーキテクトを作る

(3)(続き)評価しないものを決める
・個別のスキルが高いだけなのはNG
・受け身な姿勢、言われたらやる姿勢もNG
・チームの足を引っ張るメンバもNG
・成長をしようとしないメンバもNG
・あきらめ、チャレンジしない人もNG
・保身の屁理屈がうまい人もNG

(3)(続き)案件で進化してもらう
・SV(スーパーバイザー)制度で現場を厳しく手厚くみる
・リストラしない。代わりに成長させる
・アサインをキャリアパスを考えて細かく調整する
・PM等、アーキテクト、開発など、同じ傾向の人を集めると話があって
  成長しやすい
・社内ナレッジ共有

(3)(続き)メンバを刺激する
・チャンスを与える
・メディア連載、書籍の執筆を薦める。会社が積極的にアプローチしてとってくる。
  会社が取りに行かないと執筆などの依頼は来ない
・グローバルなベンチャとの交流
・コミュニティ活動支援
・勉強会
・顧客との飲み会をすすめる

→社員の技術力、開発力などのスキルを徹底的に高める、研ぐ。

■少数精鋭メンバでどこまでやれるのか
生産性を高めれば
・要件定義:少数人数で十分可能、むしろ少数が良い。
 ・業務例外の暗黙知を理解する。
 (設計は含めていない)

・開発
 ・生産性を上げる。自動生成を駆使する。
 ・コードは極力書かない
 
 実績値(100人月規模)
  ・業界標準の生産性        1.4
  ・ウル社の生産性    下手したら3倍とか
 実績値(500人月規模)
  ・業界標準の生産性  1.4
  ・ウル社の生産性    下手したら6倍とか
  ・数億円規模の案件ならば、少数精鋭でも全然できる。
 
・PM
  ・少数がよい。人数よりメンバの質
  ・大規模案件の場合、発注側がボトルネックになるので、
    発注側を支援することで大きな貢献ができる。
  ・ゼネコン型開発は不要にできる

・運用、保守
  ・少数で行う
  ・インフラを外に出す。クラウドの利用で少数でも行えるように。
  ・保守案件は、追加開発をアジャイル開発で行うのに向く
  ・業務運用特化型になる。

■このようなやりかたで利益は出るのか?
・ウル社の経常利益の推移
 3%、-8%、 ?6%、14%
 一旦、やり方を変えて投資(上記のいろんな変更)をしたためにしゃがんだが、
 2年後に上場を果たし、その後も増益傾向
・会社の資金繰りが劇的に改善できた

■例えばこんな案件をやっている
・次世代クラウド
・グローバルリアルタイムSCM
・B2B情報提供システム
  …
(その他沢山)

営業が案件をとってこなくても、顧客からや顧客のつながりから
新しい話がどんどん来るようになった。
案件自体は特別に大きい物ではないが、他でやっていないような
技術が必要なものなどもきている。

■まとめ
・「極上のSI」への道は確かにある。
  ウルシステムズは、頂は見えていないが稜線が見えてきた段階。
  完成していない、これからも課題はある。
・必ずしも大きなSystem開発が来るわけではない
・Developerの現場が喜ぶ仕事

■SIモデルを変革しませんか
・顧客満足が高い
・皆がヒーローになれる
  (地味な〜くんが顧客にはすごく評価が高いなど)
・個々人がものすごく輝ける
・すべてのパート−なー企業が幸せ
・自分たちの誇りのために各メンバは利益を出すから、
  それらの集合が会社の利益になる

以上。 
デル株式会社

(C) 2024 ブログ JUGEM Some Rights Reserved.