yuwji.hatenablog.jp

雑多に色々

2019/5/17 DevLove関西「アジャイル時代のチームやリーダーシップ」に参加して

2019/5/17 DevLove関西「アジャイル時代のチームやリーダーシップ」に行って来ました。

devlove-kansai.doorkeeper.jp

■セッション

永和システムマネジメント(ESM) Agile Studio Fukui の岡島幸男(@okajima_yukio)さんによるお話でした。

www.slideshare.net

■参加の動機など

相変わらず現職ではウォーターフォールのみで、アジャイルスクラムはコミュニティや書籍で触れる程度で、実践はない状況。なので、世界観が合うかなぁと思いつつ、クラウドアジャイルで受託開発を進めておられる話をお聞きしたくて参加しました。

■セッション内容と所感

以降、セッションでお話されていた内容や所感を纏めます。
※特に気になったところを書いていくので、スライドにあっても書いてないこともあります。

組織に横たわる透明な壁

10年前の第1回DevLOVE関西にて「開発者とマネージャの間にある透明な壁」というテーマでお話された際に触れられたという「カマスの実験」が興味深かった。 カマスは透明な壁があると認識すると、その内ぶつかりに行かなくなり、そうなると壁を取り払ってももう行かなくなってしまうそうです。 ググってみると、企業や組織の文脈でもよく出てくるそうで、実際にあるあるな話だなーと。
カマスの実験 | 今週の朝礼

信頼貯金も同じで、一回壁ができちゃうと戻すのが超辛い。 最初から壁を作らないようにすることが大事なんだろうなー。でも人間だからミスることもあるし、リカバリーするためにも素直に謝るとかも大事だよなぁ。

セッションに話を戻すと、そんな話をしたにも関わらず、数カ月後に部門を見る立場になると、「課長なんだからしっかりしろ」と言ってしまったり、同じようなことをしてしまったそうです。 私はマネージャーではないですが、ありがちなの分かる。

チームの形の変遷(例え)が秀逸

旧来の「桃太郎」型から、「特攻野郎Aチーム」型、そして現在ではアジャイルな「アベンジャーズ」型に移っている。 それぞれの説明はスライド20ページ目辺りを参照ください。

アベンジャーズ型に「それぞれがヒーロー」という記載がありますが、口頭で「それぞれが自分自身をヒーローとして自認し、行動している」と補足されていました。アベンジャーズには色んなヒーローがいて、強さの強弱やスキル属性的な違い、と差はあるけど、自分で自分をヒーローだと認められている状態なわけですよね。それって凄く大事なことですよね。

この辺りはTheTeamにあった内容とも似てるなぁと思いました。桃太郎型の頃は「きびだんごが欲しいなら鬼退治に行くぞ」という【金銭報酬】的なモチベーションだったんだけど、アベンジャーズ型になって価値観の合う仲間達と仕事をすることに一種の喜びを覚える【感情報酬】的なモチベーションに変わって来ている、ってことですよね。

メンタルモデルの変遷も面白い

昔ながらの受託と共創のメンタルモデルの違いも興味深かったです。 (スライド32ページ辺りに纏められています) この辺りは、自社サービスをやるときにPOの経験をしたことで変わっていったそうです。

業務SEからWEBエンジニアへのコンバート

ESMさんでもアジャイルで仕事をしている方は半分程度だそうです。 アジャイルなチームとウォーターフォールなチームが合併した時は、ウォーターフォールな人の方が多かった。 なので、ウォーターフォールで多い、コードを書かないエンジニア、所謂業務SEが多くいる。 彼らを如何にWEBエンジニアにコンバートして、アジャイルにしていっているか、お話頂きました。

www.slideshare.net www.slideshare.net
※48,54ページ目辺り

コレが今の自分には一番刺さりましたね。 現職では、「内製化しないと!」という話題は上がってるようですが、上層部の面々で、そのためには研修予算が必要だーとか色々議論している段階なので。

たった7ヶ月で概ねコンバートできてSPAも書けるぜ!な人材ができるとか何スかその裏技!

と、茶化しは程々にしておいて…
お話を聞いていて、弊社との大きな違いは…

  • ベテランでコードレビューをガリガリできる人がいない
  • スクラムマスターなど支援できる人がいない

の2点かなー。致命的。
とは言え社内にいないものは仕方ないので、コーチや強い人に来てもらうことが重要かなと思います。うーん、予算要るよなーやっぱり。

もしこの辺りをサービスとして提供して頂いたら、まだまだ多いであろうレガシーなSIerにも需要ありそう。弊社とか弊社とか。

あと、皆初心者でチームを構成していたので、分からないことだらけで雰囲気が悪くなったりしがちだった。これはふりかえりで改善したり。gitでコンフリクトしまくってたので、最後の方のスプリントはモブプロしたりして対応していったようです。
フォロー(支援)できる人がいることが重要かなーと。

他にも

  • 若手の育成
    • 自由課題のOJT
    • 2年目が1年目を教える
    • 3年目がコードレビュー
    • ベテランはWEBサービスの裏から支援して褒めたり
      • ベテランは稼げる人達なので、主案件にしちゃうと辛いので
    • 稼げない人同士で育てる仕組み
    • 大事なのは継続的なサポート
  • ユーザーと「2年かけて変えていく」方針で進めてたり。

■本筋とは別で面白かったこと

人生60年表

平鍋さんから推奨されたそうです。 職務経歴書を書く時とか、自分の経験やスキルの棚卸しをするのに良いですね。
前職では参画した案件や技術スタックを登録するシステムがあって、棚卸ししやすかったんですが、現職では特になくて、職務経歴書書くのに苦労してるので、この手の仕組みは欲しいので、とりあえずやってみようかな。

以上だす。