『越境する受託開発』に参加してきました。
今年初の勉強会に参加してきました。20分ほど遅刻orz
越境する受託開発 〜サービス開発と受託開発の境界を、越えて〜 - DevLOVE
メモレベルだけど今年はアウトプットする年にするので熱いうちにさっさとｗ
「受託開発とサービス開発を同じメンバーが担うことへの挑戦」
・リスク感覚の一致。
とかタイミング。
これがあってるとチームがうまくまわる。
・問題解決のアプローチ
どんなに知識があっても解決に向かうアプローチを知ってなければ意味がない。
・モチベーションの維持
・ノーと言える勇気
立場に関係なく言えるように
実践の中で身につける機会を作ること。
技術力とか開発力じゃなく仕事をするチカラ
受託、自社両方をやることで成長する。
受託、自社それぞれの違い、身につくものが違う。
ひとりに、受託、自社8:2とか、3:7とか、バランスをとる。
自分の給料分くらいはそれぞれ受託で貢献。
お互い負い目がない。
各メンバの総合力の向上によってマネジメントコストが低下する
「プロフェッショナル・エンジニアリング〜受託開発とサービス開発の共通項」
受託
ただ言われたものを作るようになりがち
なんのための仕事かわからなくなる
よいところ
ゼロベースではじめられることがおおい
新しいものに取り組めることが多い
隣の芝は青く見える。
受託は受託、自社サービスは自社サービスなりのことがある。
プロフェッショナルとは何か？
専門職で生計を立ててたらプロか？
NHKプロフェッショナルの仕事の流儀
→現状に満足しない。
→どんな回をみてもみんな同じ事を言っている
→自己満足したらもうもう終わりだ
続けて行く姿勢を持ってる人がプロフェッショナルでは？
どのようにプロフェッショナルになっていけばいいか？
→心技体ではなく体技心ではないか。
健康に働ける体→技術力→マインド
プロジェクトを良くして行くための7つの突破口
1.プロジェクト思考。
成功させる事が自分の仕事。
プログラムを作ることが仕事じゃない。それによってどんな価値を生みだしてるか。
2.T字型の知識スキル
例えば商品ページ作るにもどうやったら購入されるのか、SEO対策、ページの作り方というような周辺知識があり、BなりCなり価値を届けられたら成功。
マクロの成功、総合的にうまくいって初めて成功
自分だけの成功はミクロの成功
3.要望、要求、要件、設計を導き出すスキル
整理見極め
4.IT専門家としての提案
時代によって出来ることが増えてくる。
昔はできなかったけど今は出来る、そこを知ってるのは専門家
5.顧客との信頼関係に興味を持つ
信頼関係がないことでやれドキュメントだエビデンスだ、と余計な作業がふえる
参考図書:スピード・オブ・トラスト―「信頼」がスピードを上げ、コストを下げ、組織の影響力を最大化する
6.価値、目的のために立場を超えて歩み寄る
自分の立場ばかりではなく。
7.自分の専門を作る
インプットとアウトプット
アウトプットは勉強会がいい。専門家になるスピードがあがる。
話すにはまとめる必要がありフィードバックも得られる。
自分がプロフェッショナルとして働くことで業界全体をよくして行こう
DevLove(20140124) from 治夫 佐藤
フリーディスカッション
Ｑ：納品に伴って必要のないドキュメントを書かなければいけなかったりする。
A：無駄なドキュメントは極力省く。
お客さんにやってもらうのもひとつ手。何か(機能追加要求とか)と交換というのもアリ。
wikiに全て書き客にも公開。→それでいいよね、ということになるのが多い。
契約の時なるべく最小限
参考図書本:コンサルタントの道具箱 ワインバーグ
Ｑ：メンバーに広い視野を持って貰うには？
A：お客さんとエンジニアが直接話す。
プロジェクトが始まるときにジャンルごとのリーダーを決める。サブリーダーも決める。
ドキュメントリーダー、品質リーダー、とか決めることでモチベーションをあげたり、全体を考えるようになる。かつその役割をローテーションする。
プロジェクトの価値、視野を広げることで意識があがる
Q：これからの受託開発で大事なことは
A：目的とか価値を意識する。メンバーにも意識してもらう。
あるサービスのここを作ってます、ではなく。
視野の広さ、全体を見れるところ。
任せること、場数を踏ませること。
Ｑ：かなりスキルがある人たちなのでは？
A：ごくごく普通のレベルのエンジニア。
いつも自分と一緒にいることでやり方が身についた。5年くらい。
一朝一夕にはいかない。長いスパンで考える必要がある。
Q：”要求開発”は具体的にどういった取組になるのか？
A：モデリングを使いながら客と合意してからプロジェクトを進める。
Ｑ：客先に都合で出せないメンバーへ視野が広くなような情報共有の仕方、アドバイスがあれば。（私の質問ｗ）
A：自分がお客さんになりかわり、客以上にワクワクを持って情報を伝える。
エンジニア出すメリット、デメリットはある。
時間が勿体無いという考え方もある。
方法論としてはスクラムのプロダクトオーナーとして動く。お客さんの立場として振る舞う。
プロダクトオーナーを勉強するとヒントが得られるかも。
感じたこと
ドキュメントがwiki
新しい！これは究極理にかなった管理だ。
各メンバの総合力の向上によってマネジメントコストが低下する
こればハッとさせられた。
その通りだ。
登壇者のお二方とも、社員の成長をすごく考えていてそのための機会や場を作ってる事が印象的だった。
自分の負荷を減らすためにもメンバーを育てなきゃだ。
自分がプロフェッショナルとして働くことで業界全体をよくして行こう
これはめちゃくちゃ響いた。いい言葉。ぐっときたーーーー！
だれでも『○○業界』にいるし、私も然り。
私の場合業界にいる同業者が数少ない。業界はでかいけど土俵に上がってる。
私も業界を端っこの方でも担ってるんだ、そしてもっと真ん中に行く気持ちを持って良いんだ、と思えた。
場数、経験が多い
登壇者の方を見ていていつもスゴイなと思うのは
フリーディスカッションで出たQにすぐAできること。
あれも一朝一夕では成らないものだ。
