参加してみて先ず思ったこと
アジャイルというよりは、組織や人の課題の話が多かった印象。
トークも質問も。
上司とのコミュニケーションとか、技術的スキルが不足しているとか。
チャレンジングじゃないとか。
なんか組織内での分断が起きているのかなと。
そして、ITベンダーさんが大分ヤバそうな感じを受けた。
平鍋さんが｢これからは、ユーザー企業との協同(働?)開発の流れが増えてくるのでは?｣
ベンダーさんが組織一丸となって、更にはユーザー企業とも一緒となっていくみたいな垣根ない状態を築いていかないと大変そうだなと。
そこで、垣根なさすぎても問題だろうから、ある種の階層構造は持ちつつ。
というところでは、大規模アジャイルって向いてそうですね。
業界を少しでも変えられたらなぁと、改めて思った。
アジャイルの先ってなんだろう?
より優れた手法はあるのか?的な疑問。
でも、アジャイルはアジャイル。
いろいろなプロセスやフレームワークは繋がり合っているモノ。
どっちが優れているとか、先とか後とかではなくて状況による。
そして、状況に合わせた経験や知識を持ってているかどうか次第。
｢先進導坑｣って言葉カッコいい。
エンジニアの性?なのか作ったら｢現場ですぐ使える｣みたいな感じになったりする。
けど、デプロイ(サービスリリース)や運用のこと考えると、いろいろ必要なものが隠れてる。
機能開発以外なんかは特に大変。
なので小さく作って運用まで想定できたら機能拡張していくとよい。
それを｢先進導坑｣って言っていてなるほどカッコいい。
アジャイルは、不確実性(複雑性)への立ち向かい方
なのかなと。
副次的に、早い、安い、うまいみたいな感じになることもあるだろうけれど。
それを主目的にすると軸がズレてしまわないかな。
ステホマネジメントしやすさもあるだろうけれど、逆に失敗することもあるかな。
とふと感じた。今後意識してみよう。
開発の現場の幸福度と事業成果は結びつかない?
幸福度は高いにこしたことはないけれども、事業成果を出す為に幸福度をあげましょう。
というのはちょと違うのかな。と。
幸福度が高く、自律的に動ける組織が事業成果に結びつきやすいのはあるだろう。
しかし、事業成果を先ず考えた上で話を展開しないと、そこを忘れがちになる。
お金周りを見ない業務をしていると特になりがち。
｢いいチームだったよ!!｣とか言ってお酒飲んで終わる。
良いチームは事業成果を残し、チームとして存続し、次のチームのお手本にならな。
そして、良いチームが時代に合わなくなってきたら、新しいチームが次へ繋ぐ。
大規模アジャイルの部分最適にならないようにしていること
大規模アジャイルは、IFを決めてチーム分割、チームごとにインテグレーション。
部分最適を危惧するようなものは上のレイヤーへ持っていく、無理に下のレイヤーで解決しない。
朝会15分をレイヤーごとに実施、1時間内(今回のお話では)で共有。
解消は時間が必要なものもあるけれど、今の所対処できているとのこと。
素晴らしい。
大規模アジャイルの組織構造
フィーチャーチーム、CoP(コミュニティ･オン･プロセス)、ギルドの3つ。
フィーチャーチームは、いわずもがな。
CoPは、職能、横軸組織。
ギルド、興味の合う集まり。
CoPとギルドは、似た者同士の知識共有を促す。
フィーチャーチームで発生しそうな、知識のアンバランスを解消する。
アジャイルでステホとコミュニケーションとるのは向いていない場面がある。
見通しの立てづらさであったり、指揮命令みたいなことを考えると、
投資だったり組織のスケールとかやりづらいところもあるだろうね。
軸を持ちつつ、状況に合わせて、相手に合わせて適切に動かないとね。
でも、ハンター社さんは、アジャイルな感じしてそう。
Learning Agility
コロンブスは、まだ見ぬ新大陸に向けて航海で何をしていたか。
不安を取り除いていた。
大航海同様、不確実性の高い時代に立ち向かうには、
Learning Agilityを高め自律したメンバー、チームで立ち向かう。
自律が強くなると発散してしまうので、そこは注意を払い整えながら。
日本人は不安がちなので、不安を取り除きながらチームマネジメントをする。
大規模な改革
組織サイズが単純に凄い。
戦略と指標(メトリクスや評価軸)。
メンバー評価と査定は別。
評価軸の見える化、自律的になり結果、査定も変わってくることだろう。
人材育成大切。
開発力はチームの総合力
エンジニアリング的な技能だけでない。
デザインやマネジメントもだし、顧客価値の探求など総合的なもの。
どこを伸ばすべきかは改善すべきかは状況にあわせて戦略的に行うこと。
ポイントとしては、話が広がる前の根っこの部分を抑えることがよいのかなと。
要求だったり、開発プロセスだったり。
アジャイルコーチのコーナーで質問できたらしたかったこと
チーム内において技術領域が分断されている場合のポイントの管理をどうすべきか。
スプリント内でのデリバリを意識すると、デリバリまでに結合させなければいけないことに課題感をもっている。
例、チーム内でバックエンドとフロントエンドで分かれているような場合。
画像リソースなどは、前スプリントまでに事前準備していたりする。
なんでもかんでも事前準備するのもデリバリまでの時間が長くなる。
分けないように技術領域を越えて作業ができるようになるといいかもしれない。とは思う。
質問を整理したりして、なんか自分なりの答えは出そうな気がする。
チームの開発力をあげる為にしていることは?
仕組みだったり、ペア･モブ、ジョブロなど。
また顧客価値の最大化を考えるときに気をつけること。
