5/17に仙台で開催されたDevLove仙台✕関西に参加してきた。久しぶりのITイベント参加。
当日にまとめてたnemorineさんblogの二番煎じの感はあるけど、出てた内容のまとめ。
今回は勉強会の写真と音声録音からまとめてみたけど、まとめるのに時間かかり過ぎ。次回はPC持って参加する。
炎上プロジェクトの経験を前向きに学ぶ(村上さん) #DevSen
村上さんは現在プロジェクトマネージャ(火元w)。
炎上あるある
- 要件が毎日変わる
- 終わらないレビュー 4回やったら元に戻る。メビウスレビューw
- 赤字覚悟の案件受注 仕様は前と同じでいいよ→前のシステム作られたの10年前→よく見ると新しい機能が追加されてる。。
炎上の対策として管理強化
- プロジェクトマネージメント強化
- PMO取ってみた
- ISO取ってみた
その結果は？
- 手続きが増えた
- 工数が増えた(管理作業のため)
- でも品質は上がらなかった...
何が問題なのか？
みんなの話を聞かない人がいると、そこで情報が止まって、先に進まなくなる。
現場の話が上に報告されず、適切な対応が取られない。
当人は問題意識はなし。
こういう人の特徴
- 積み重ねの概念がない。昨日の結果と今日の結果に連続性がないことが気にならない。
- 連続性がないので何が起きてもずっと正解。悪いのは自分以外のどこか。
- 認めないので反省する事もない。常に自信満々。
- よそから持ってきた対策ばかり。自分で考えてない。
「自信満々」な人への対策
- プロジェクトを進める仲間を増やして、進める話をする。
- 組織やチームの垣根を超えて、情報を伝播していく。
- 真ん中辺りの話は真ん中でやってもらって、実作業は周りで回す。
- 報告はするけど、要求されたところだけ報告する。
- 現場に影響を与えないように無力化する。
- うまくいったら周りに感謝する。
受託だからといって受け身である必要はない (大友さん) #DevKan
お客さんを満足させつつ、楽しく開発するためにやっていたこと。
大友さんは炊事、洗濯、育児をこなすフルスタックエンジニアを目指してるそうw
下請けからみて誰がお客さんか？
一番の発注元を満足させる必要がある。
「誰が何のために」をとことん聞く。本当に要求を持っている人(ドメインを理解している人)にしか答えられない。ここを確認しないまま進めると、ちゃぶ台をひっくり返される。ウォーターフォールでもアジャイルでも関係ない。
受け身じゃないポイント① 本当の要求を持っているユーザまでたどり着く
どうやってお客さんの要求を引き出すか？
質問が違えば当然答えも変わる。時間も掛けられない。
手っ取り早くお客さんの考えを知るにはどうすればよいか？
n次受けに話が来る時は、予算も納期も、問題の解決策も決まってることが多い。
これが弊害になる。「こうなっちゃてるんで...」と言われる。
「念のため教えてください。予算獲得時の資料はありますでしょうか？」と確認。
プロジェクトが発足した当時の資料を見れるように頑張る。
「念のため」は相手の事を思っていますよ、という謙虚な感じが出るので便利。
受け身じゃないポイント② ユーザのコンセプト資料を手に入れる
プロジェクト発足時のユーザの熱い想いが書かれている。
n次受けに来る数ヶ月の間には、ユーザが想いを忘れてることがある。
資料を元に要求分析を作成する。
「なぜなら～だからだ」は必須。
受け身じゃないポイント③ たとえ不要と言われても、要求には「なぜなら」を書く
これがないと言った言わないになる。
開発チームの認識合わせのためにも必須。
開発チームがプロジェクト内で意見を交わすとき、これがないと憶測になる。憶測でケンカまで始める。
「なぜなら」があると、プロジェクトの会話の質が上がる。
楽しく開発するためにやってきたこと
受け身じゃないポイント④ チームが形成される仕組みを積極的に組み入れる
いっぱい話せる仕組みを取り入れる。
朝ミ、夕ミ、ランチ、飲み会、お菓子など。
チーム形成は勝手にはできない。チーム形成のための仕組みを意図的に用意する必要がある。
ほっといてもチームが出来るのであれば、それは優秀な人ばかりだったということ。
普段からどうでもいい事を話していないのに、大事なことを話してくれる訳がない。
受け身じゃないポイント⑤ 良いプロダクトを作る機会では社外もチームととらえ積極的に会話する
社外のチームとも楽しく開発をするためには？
毎日数分のWeb会議を設定してチームの顔を見せる。
週一で直接会って話す。
「我々はチームなので何でも共有します」と宣言する。
これを言っておくと、状況が変わった時に連絡もらえたりする。
泥臭い場所(瑕疵対応とか)とそうでない場所は明確に分けて対応する。
言葉を選ぶことは、時としてコミュニケーションの量よりも重要。
会話の量は仕組みで増やせるが、会話の質は個人に依存するので要注意。
例えば、いつも否定から入る人が「何でも相談して」と言ったところで、そんな人には相談したくない。
「泥臭くない」受託開発なんてない。あるいはTDD/DDDのすすめ（井上さん）#DevSen
SIer勤務。3月に会社を辞めてフリーに。
泥臭い受託開発とは？
SIer辞めたら本当に泥臭くなくなるのか？そうであれば泥臭い受託開発って何だろう？
お客さんが求めるシステムはお客さん毎に全て異なる。
ある技術やプロセスを適用すれば必ずうまくいく、なんてことはない。正解はない。
Why,What,Howを常に探求し続ける必要がある。
レベルの違いはあっても、全ての現場で泥臭くやってるのではないか？
SIer時代について
課題に当たっても最初は力も技術力もない。
歯車感。病みそうになる。
プロジェクトを変わって楽しい仕事に。
テスト駆動開発、XPなど新しいことにチャレンジできた。
周りに意識高い人が多かった。
何よりも、お客さんに良い物を作る事に注力できた。
コードを重要視していた現場だったので、コードを書くのが楽しかった。
悩む日々
- プロセスはウォーターフォール。
- 中間管理職のような立ち位置で、パートナーの管理、書面書きに追われる日々。
- 「決定したことをいかにそのままやるか」という立場になり、コードが書けない！
- 低品質なコードに悩む。リファクタリングは井上さんが忙しくなると回らなくなる。
- システムのWhy、Whatに注意を払う人がいなかった
TDDの良さに改めて気づく。
自分が満足するシステム構築が出来たシステム、井上さん在籍期間バグ０！
問題山積みプロジェクトに...
- 仕様が伝言ゲーム Whyがない
- 終盤ではコストカットで出張禁止 顧客と会うのが年１回ペース
- 仕様が曖昧 ドキュメントとコードが一致しない
- 品質悪(コピペの嵐) リリース後の障害が日常茶飯事
- リファクタリングしても、修正量＜追加量で改善が追いつかない。
- スピード感がない
- チーム全体に覇気がない
まとめ
- 全ての「受託開発」は「泥臭い」
- 受託開発の本質は顧客の望むものを一緒に作り上げること
- 自分を変えるのと比較して、周り(チーム/組織/顧客)を変えるのは難しい
- (少なくとも)自分が変わらないと周りは変わらない
- 自分の強みを持ちましょう
- TDD/DDDがおすすめ
自分の力をつけないと、そもそも選択肢がありません！
「私がモテないのはどう考えても受託開発が悪い！」なんてことはない (横山さん) #DevKan
受託開発あるあるチェック
- 要件定義が長引き開発の費用や時間が大幅に減った
- 作ったものが期待するレスポンスで動かない (作り直し)
- 外注したら絶望的な品質の何かが届いた (やっぱり作り直し)
- そういえば今日はメールとExcelしか使っていない
- お客さんからモーニングコールがかかってきた (夜間バッチ障害)
終わらない開発
- 仕様が確定しない
- お客さんの要求が変わる
「こうして欲しいという」要求のなぜ？やそもそもを十分に把握せずに対処してたのが問題。
真意が分からないので、提案や交渉が出来ない。
チームのスキルを無視した技術の採用
- 背伸びしたツールやプロセスの導入
- 要求を実現する方法の調査コスト大
個人の力技で解決
- 技術力を磨く
- 生産性を上げる(ひたすら頑張る)
特定のキーマンがそのプロジェクトの命運を握る。
→いつまで経ってもその人は楽にならない。
受託から自社製品開発に
受託開発でなければ上手くいくかと思い、自社製品の開発を始めてみた。
仕様を自分たちで決められる 要件の認識違いは発生しない。
自分たちで考えた機能をお客さんに褒めてもらえる。
が、売れなかった...
売上に繋がらなくて焦る日々
→お客さんが欲しいものとのギャップが？
→ギャップを埋めるために製品をカスタマイズする
→要件を聞いて希望の納期までに…
どこかで聞いたような、、、
仕事のやり方見直し
知識やスキルは前提条件。
技術力は必要だが、上手く進めるための事前準備でしかない、と自覚する。
プロジェクトは未知への挑戦。
未知の領域に既知が通用するとは限らない。
やるべきことはやる
- 見積もりはしっかりする
- 顧客の真の要求(そもそも)を把握する
- 顧客と交渉する(逃げない)
- 進捗や課題の見える化
- チームのスキルに合わせた技術選定
- チームでの会話を重視する(雑談も)
- チームメンバーの適材適所な役割分担
チームがうまく機能すれば、プロジェクトは劇的によくなると実感。
受託開発の難しさって何だ？
- 複数の会社と連携することの難しさ
- 常に仕事を取るための営業と内部リソースの調整
- 技術スキルのマッチングと社員の育成
受託開発のいいところ
- 色んな技術を習得できるチャンスがある
- お客さんと直に接することが出来る
- お客さんの望んでるものに対して自分達の最高を届ける
どうすれば受託開発が上手く行くのか？
受託開発の難しさは進め方の問題よりも組織やビジネス的な課題の方が大きい。
- 経営上の課題を解決する
- お客さんとしっかり信頼関係を作る
- 現場が正しいと思うことを出来るようにする
サービス企業だけど結構色々あるんですよ (半谷さん) #DevSen
Hadoopで2PBのデータ分析やってます。
対立
本社と開発部隊で対立。各部門間で対立。本社vs地方、ビジネスvsプロデューサー、システムvsプロデューサー、プロデューサーvsエンジニア等。
本社のエンジニアは運用第一 止める/止めないが大事。
地方は新しい技術使いたい。
お互いに対立(3年くらい前)。あいつら全然分かってねぇ。
とは言え悔しいので成果を出そうと頑張った
老朽化したDWHを使ってとにかくSQLを書いた。
老朽化したDWHをHadoopに移行。
374本くらいのSQLをHadoopで動くようにガシガシ書き換え。
震災2ヶ月後にリリース。
こういう事を繰り返して成果を出していった
次第に本社に評価されるようになった。
転機
2011の年末に3ヶ月くらい本社にいて激論交わした。
飲みにも行った。毎週毎月。
本社サービス視点で色々な事を考えてるということが分かった。
本社への態度が軟化していった。
「こういう事をやりたい」と言うと「いいんじゃないの」と言われるようになった。
「心の友よ！」みたいな関係になった。(言われてはいないw)
まとめ
- Face To Faceでやりとりが出来ない環境では、お互いに対する信頼関係、愛が大事
- お互いに対する愛
- プロダクションに対する愛
- お客様、利用者に対する愛
- 嫌とか嫌いとか言うのではなく、受け入れて、やる
- 楽しくやることが重要。笑いながら仕事をする
- あとは酒。酒があれば大抵大丈夫w
ダイアログ
テーマ毎に4グループに分かれて討論。
自分が入ったのは、グループ3：チーム形成のコミュニケーション。
話しやすい場を作るには？という所をメインに話をした。
出た意見としては、
- 朝/夕ミーティング
- 飲み会
- ランチミーティング
- おみやげを取っ掛かりに話をする
- 自分のキャラを立てる(ツッコまれやすくする)
- 相手の良いところを探して褒める
- 接点になる趣味を見つける
- 雑談する(隠し事をしない・させない)
といったところ。
他にチーム作りをどうするか？ コミュニケーションが取れない人はどうするか？という話も少ししていたが、こっちはあまりまとまらず。
他チームの意見。前半のはメモし損ねたので、残ってたものだけ。
受け身にならないようにするには
- 「～でいいですか？」ではなく「～でいいですね？」と自分で咀嚼したものを確認する。自分もその決定に対して責任を持つ。
- 相手から言われたことをやるだけでなく、自分たちで受けた話に対して もっとこうすればどうか？ということを確認する。
自分たちが受け身にならないためには
- クオリティ感覚を持つ こうします、品質はこれくらいを保ちますという宣言をする。
- 残業することが受け身 仕事を自分でコントロール出来る人は受け身にならず、自分の時間もコントロール出来るのでは？
- 会社から言われて仕事をするのではなく、自分が会社をこう動かそうと考える。
相手が受け身にならないためには
- プロジェクトと見積りの情報を与える あなたにはこれくらいのお金が掛かってますよ
- 視野が狭いと受け身になる 情報を与えることで受け身にならない
ビアバッシュ
プロジェクトを進めるための方策、XX駆動開発などなど、文書に起こせない話題が色々と。。
感想
チーム、コミュニケーションについての内容で刺さるものが色々あった。
今の仕事で苦労しているが、チーム作りが出来ていなかったことがその一因だという事に気付かされた。
個人の忙しさにかまけて、チームに向き合う時間が取れていなかったので、時間の管理方法が自分の直近の課題。
毎日のミーティングやるようにしてもチームとしての一体感出る感じがなかったので、コミュニケーションの方法ももう少し改善を考える必要あるな。
あと、自分含めて後ろ向きな気持ちで作業してるチームをどうやって前向きにさせるかというのも個人的課題。
チーム作りって本当に難しい。
ヒントを色々貰ったのでまた考えてみる。
主催者の皆さん、会場を提供して頂いた楽天様、参加者の皆様、ありがとうございました。
会場を提供して頂いた楽天さんからもらったノベルティのシール。
