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

DevLOVE仙台 泥臭い受託開発を語る

時間が取れたので、急遽参加!
そして、参加して良かった!!超楽しかった!!
今回は話聞きながら少しまとめれたので、ブログが楽チン♪
次回もこのスタイルで行きたいなぁ…

DevSen 炎上プロジェクトの経験を前向きに学ぶ(村上さん)

炎上あるある

  • 要件がコロコロ変わる
  • メビウスレビュー
  • 赤字覚悟の案件受注

できる人に仕事が集中して人がおかしくなってしまう。 できない人はおかしくならないw

炎上の原因

  • コスト度外視で納期だけ

対策は?

  • プロジェクトマネージメントの強化
  • PMP
  • ISO

でもダメだった。。。
結局、工数が増える/品質が劣る/管理作業も増える

自分たちの問題点を直視しないで、借りてきた解決策を導入するとこうなるよね。。。

やっと気づいた思考パータン

  • 積み重ねの概念がない > 昨日と今日に連続性がない
  • 悪いのは自分以外の何か > だから謝らないし、自信満々
  • 対策は他から持ってきたものばかり > 自分では考えてない

話せば分かると思ってたけど、分かり合えない。。。
ただし、ジャイアン(=自身満々の人)の数は少ない

真の対策は?

  • 仲間を増やす
  • コネクションを使って、情報を通していく
  • 情報は聞かれたものだけ報告していく
  • そしてジャイアンを無力化する
  • 上手く行ったらチームみんなに感謝をする
以前、村上さんとお話したときの情報を少し…
「情報はプロジェクトの血と同じ。滞っていると死んでしまう。
そのために、キーマンを飲みに誘い情報を引き出す。
そして、小さくてもいいのでやってみる。
楽しそうにやっていると人が集まってくる。そうやって仲間を増やしていく。」

DevKan 受託だからと言って受け身である必要はない(大友さん)

スライド

SlideShare

下請けから見て誰がお客さんか?

  • 元請けのA社が満足する必要がある
  • 誰が何のために必要なのか
    →これは本当にドメインを知ってる人じゃないと答えられない

受け身じゃないポイント① 本当の要求を持っているユーザーまで自ら辿り着く

「念のため」という言葉を上手く使い確認を行う

受け身じゃないポイント② ユーザーが予算獲得などで作成したコンセプト資料を必ず手に入れる

コンセプト資料を手に入れたら要求仕様書を作成する。

受け身じゃないポイント③ たとえ不要と言われても、要求には「なぜなら〜」を書く

なぜなら〜、〜だからだを書くことでチームの意識が揃ってくる。
これがないと、メンバー同士が憶測で喧嘩を始めることもある。

派生開発でいう理由に当たるところだと思う。
レビュー時も要求だけよりも「なぜ」という理由が書いてあった方が納得しやすい。

受け身じゃないポイント④ チームが形成される仕組みを積極的に組み入れる

いっぱい話せる仕組みを取り入れる。朝ミ、夕ミ、ランチミーティング、飲み会など。

受け身じゃないポイント⑤ 良いプロダクトを作る機会では社外もチームととらえ積極的に会話する

普段からどうでもいいことを話してないのに、大事なときだけ話せるわけがない。
お金と瑕疵以外で話して、チームとしての一体感を持つ。

要注意

会話の量は仕組みで増やすことができるが、 会話の質は個人に依存するので、要注意。

最後の会話の質は個人に依存するっていうのは本当に分かる。
お互いに尊敬の念がないとダメになることが多い。
ただどうやって尊敬の念を作っていくかは… まだ答えがない。
半谷さんの発表のように、激論をすることでお互いを強敵(とも)と
呼べるようになればいいのかな…

DevSen 「泥臭くない」受託開発なんてない。あるいはTDD/DDDのすすめ(井上さん)

泥臭い受託開発とは?

受託開発で顧客が求めているシステムは全て異なる!
Why / What / Howを常に探求し続ける必要がある。
レベルの違いはあるかも知れないけど、全ての現場が泥臭いことをしているはず。

SIer時代で楽しかったこと

かなり早い時代からのXP。 顧客にとっていいものを作れたことが楽しかった。

2001年からテストファーストをやっていたとは…
時代がやっと井上さんに追いつきましたね(笑

悩み

  • ほとんど中間管理職
  • システムのWhyとWhatに注意を払う人が居なかった
  • 決定したことをそのままやることが重要
  • 技術力が評価されない
  • 周りを変えるのは難しい
  • 誰のための仕事か分からない。
  • ドキュメントとコードが一致しない。
  • チーム全体に覇気がない

TDD/DDD

自分が良いと思っているTDDでプログラミングしたプロジェクトはバグ0。
1サイクル目は捨てる前提!!

1サイクル目は捨てるっていうのがグッと来た。
そもそもソフトウェアに試作とかという工程がないのがおかしい。
DDD勉強会in仙台参加しなきゃ!

DevKan 「私がモテないのはどう考えても受託開発が悪い!」なんてことはない(横田さん)

よこたまさた @mesodash

最近はSonicGardenやGildWorksのビジネスモデルのように情熱系受託開発が多い

受託開発あるあるチェック

  • 要件定義が長引き開発の費用や時間が大幅に減った
  • 作ったものが期待するレスポンスで動かない(作り直し)
  • 外注したら絶望的な品質の何かが届いた(作り直し)
  • そういえば今日はメールとExcelのみ
  • お客さんからモーニングコールがかかってきた

終わらない開発

  • なぜやそもそもを十分に把握せずに対処してしまった。
  • チームのスキルを無視した技術の採用
  • 個人の力技で解決

受託から自社製品へ

  • 仕様を自分たちで決められる
  • 自分たちが考えた機能をお客さんにイイネしてもらえる

でも売れなかった…
中途半端な状態で逃げられなどしない。

どうすればプロジェクトが上手くいくか

  • プロジェクトは未知の領域
  • 技術は前提

やるべきことはしっかりやらないといけない

  • 見積もりはしっかり
  • 真の要求をとる

チームが上手く機能すれば、プロジェクトは劇的に良くなると実感する。
上手く機能させるためには仕組み作りも必要である。

受託開発のいいところ

  • 色んな技術を取得できるチャンスがある
  • お客さんと直に接することが出来る
  • お客さんの望んでいるものに対して、自分たちの最高を届ける
横田さんはどれくらいモテないのか、気になって仕方なかった…

まとめ

  • 経営上の課題を解決する
  • お客さんとしっかり向き合って、信頼関係を作る
  • 現場が正しいと思うことを出来るような組織にする
開発者の良い面を引き出すのが、良いマネージメントなのかもしれない…

サービス企業も結構色々あるんですよ(半谷さん)

日々の仕事

Hadooop Cluster(2PB)使って、本社からの仕事を仙台、大阪で受けている。

今の問題

  • ビジネス側と開発側に隔たりがある
  • 東京と地方との隔たり

地方で成果を出すべく、ガシガシ頑張った結果、東京から見直された。
転機は東京チームと激論を交わしたこと。そして飲みにいくようになった。お互いに理解が深まって態度が軟化して来た。

心の友よ!状態になった!!(向こうが本当に思っているかどうかは分からないw)

楽しくやることが重要。あと酒。酒があれば大抵大丈夫。

楽しくやることって重要だよね。自分もそれを一番に心がけている。
同じことをやるにしても楽しくやってるかやっていないかで伸びに雲泥の差がある。

ダイアログ

自分が入ったのはチーム4:要求を引き出す工夫

要求を引き出す工夫

  • 趣味を一緒にやって、時間を共有する
  • 情報を独自に集めて提案する
  • キワキワのところを質問する
  • 実際に形のあるものを見せると意見が出てくる
  • 要求よりも問題を明確にするように意識する

困った人対策

  • なるべくその人をたてながら、最後は仲間に居れる
  • 周りを巻き込んで動かざるを得ない状況にする

チーム形成のコミュニケーション

  • アニメの話
  • 朝会
  • 飲み会
  • お土産作戦
  • 趣味の話 > 人を知る
  • 自分のキャラを立てる(メンバー)
  • 褒める(サスガっすw ← 大阪で大流行?)

受け身にならないようにやっていること

  • 〜でいいですか?より〜でいいですよね?という話し方
  • 興味がないことには興味を持っていくこと
  • クオリティ感覚を持つ
  • 定時になったら自分の時間として使う
  • 自分が会社を動かしていく視点を持つ
  • プロジェクトとビジネスの情報を公開する > 視野が狭いと受け身になる

自分のまとめ

やっぱり困っているところは結構同じだよな〜って再認識した。
Whyをキチンと取っていくのが重要であるということ。
そしてチームメンバーには感謝の念で接することですね。
ビアバッシュもここに書けない楽しい話が沢山あって良かったです♪