アジャイルという言い方
既にこの言葉が世に出てから、10年以上も経過しており、ここ数年はもてはやされてる印象がある。
アジャイルプロフェッショナルという言葉もあったり、ユーザー企業向けのセミナーなんかもあって、正しく理解してる人が増えてるのかと思いきや、
全くそんなことはないですね。
いや、発注者、開発者のそれぞれの立場で解釈したかもしれない。
アジャイルソフトウェア開発宣言を見ると、
包括的なドキュメントよりも、動くソフトウェアを
契約交渉よりも顧客との協調を
計画に従うよりも変化への対応を
なんて書いてありますからね。
安くとは書いてません。
早くとも書いてません。
品質が良いとも書いてません。
動くソフトウェアってのも、極端に言えば、
でもいいんですね。
大事なのは、顧客との協調のところ。
動くソフトウェアの単位、というよりも要件といった方がわかりやすいか、、、を合意して、
その単位で動くソフトウェアを提供していけば、
そうは言っても、
期間は無限にありません。
お金も無限にありません。
出荷可能な品質でなければ、使えません。
アジャイル開発手法ってそもそもなんなんだろうってことになりますね。
決して、反復的な開発がアジャイルではありません。
もう一度重要なことを言いますけど、
大事なのは顧客との協調
です。
何が今までの開発と違うでしょうか？
顧客との協調がないから、不完全な製品が世に出たり、出ないまでもトラブルだらけになったりしてないですか？
もちろん、製品を作り上げる能力は必要です。それは技術者として飯を食ってるなら当たり前。
でも、作り上げるやり方は、自らの責任において、要求通りのものを、自分らのルールで作ればいい
というのがアジャイル
これはこれで、顧客参加型の開発手法なんで、請負開発を生業にしている企業では実行しにくいんでしょうね。
50歳からの学びについて
こんにちは
以前から、学びを開始するのに年齢は関係ないと思っていた。どちらかと言うと、自分に言い聞かせていたところもある。
ところが最近は、流行ってるみたいですね。
大学に入ったり、公文で学んだり、どちらかというと勉強が趣味みたいな印象です。
別に50歳という年齢に限らないが、子供たちが社会に出てしまえば、自分の趣味に時間が避けられるようになるので、それが勉強でも良いのだが、、、
どうせ大人が学ぶなら、人生経験とも合わせて、ちやんとアウトプットした方がいいと思う。
いろいろ失敗してきて、その原因はこの学問を正しく理解してなかったからだ、とか。
実際に起こったことを、少しドラマティックに伝えられるのが大人だし、だから学ぶことが大切なんだと、やはり自分の子供たちの世代に向けて伝えるのが良いだろう。
その子供たちの世代からのフィードバックがあれば、また新たな側面での経験となり、学ぶ活力、知識蓄積の助けにもなっていくだろう。
学ぶことは良いが、自分以外の人達に役に立つようにしましょうね、って事です。
自分が教える事で教わる事もあり、これがなかなか教科書ベースの勉強では学べない。本来の教育実習というのは、こういう狙いもあったのでは？とか考えてしまった。
自分を他者から頼りになるために、どんなインプットが良いのか、
その前に、頼りにされたい他者は誰か？を決めないとね。
これからが本格的な活動
久しぶりの投稿になりました。
昨年の9月30日でブログが書けなくなってました。
前回の記事で、振り返りか大事、振り返りをしっかりしろと書いていたので、半年以上の期間を見返してみて、再発防止に努めてみたいと思う。
まず9月末といえば、10.01の組織変更
ところが、管理職である以上、よっぽど刺激的、またはショッキングでなければその内容を受容するくらい。
現に自分、周りを見渡しても何の変化もなかった。そもそもその時期は、、、プロジェクトがまだまだ落ち着いておらず、そんなことも気にしてられなかった。
だから、あんな記事を書いたんだと改めて思った。
また、昨年9月末くらいになると実は落ち着いていたわけだが、落ち着きすぎて大事な事を忘れてたって事なんだろう。
そのまま年末を迎え、1月の組織変更、勤務地変更があり、まずはミッション理解とチーム形成で手一杯になってた。
なにしろ、次から次へと決まってない事が出てくるし、かつ決めてもらえないというSIer泣かせの進行。
セオリーとか、これまでの経験とか、プロマネに関してはほぼ意味をなさなくて、業務知識が少ない状況では日々出てきた課題を片付ける事に費やした。
毎日仕事した感はあったが、振り返ると何も進んでないみたいな。
こうやって感覚が麻痺してる人になっていきそうだなぁ。
ところが2月に大どんでん返しがあった。
これまで進めてきた要件が、丸っと否定され方向転換。内容は書けないが、2ヶ月くらい調整した事が全て無効くらいなダメージ。
これくらい大きな話になってくると、お客さんも納期を気にし始めるので、調整が早くなってくる。
プロマネも立て直し策が有効になってくる。メンバーも迷わず動けてくる。
とはいえ、期間少ないなぁ。
人増やさないとタスク溢れてきたなぁ。
調整しなきゃいけない事もまたまだあるなぁ。
でも普通のプロジェクトっぽくなってきたし、自分自身がマネジメントに時間を避けられるようになってきた。
チームのタスク指示に集中し始めたので、そろそろ別のチームのメンバーフォローにも回っていこう。
本来のミッションはそこだから。
どうしたらチームが強くなるかな
何かの役に立つ、誰かの役に立つことが実感できれば、人は強く生きれる。
いきなり思いついたことを書いてしまったが、、、
それには、個々人のお役立ち事項をまずは引き出してやらないといけない。
引き出した後は、可能な限りそれを伸ばしてやらなければならない。
抵抗勢力に立ち向かう信念を持たさなければならないし、一緒に戦ってやらねばならない、仲間を増やしてやらなければならない。
それが監督というか、マネージャーの仕事なのかな。
チームを強くするには、メンバーに強くなってもらわなければならない。理想を言えば、要件定義、設計、製造、テストがそれなりの生産性と品質で実行できるメンバーで構成される状態。
マネージャーは、チームの仕事の進行状況を監視しつつ、お客様とチームに最適な仕事カードの調整だけをする、とか。
そんなにうまくいかないんですけど、
まずは自分のマネージャーとしての方向性を信じることから始める。
トップダウンの組織運営はダメ
合意形成で進めるんだ！
そういう思いは、もう4〜5年前からあって、自分なりに同僚達と進めて来た。
だぃぶ意識が高くなり、自分が所属しないチームでもどんどん進んでいるし、所属チームでも自分が牽引しなくても目標を高く設定してるにも関わらず、小さい成果を実感するような取り組みを勝手にしている。
明確に指示がなくても、
同僚達が最善な方法を学習し、なんとかしたいことを自ら行動に起こしているということになる。
これは、2年前からすると凄い変化になる。
強い組織、チーム
考え方は二つある。
- トップのカリスマ性を持って、絶対信頼と服従による運営
- 合意形成によるチームビルディング
なので、後者を選択したい。
ぶっちゃけ、火消しで音頭取るようなカリスマ性はないからというのもあるが、火事にしないのが正しいマネジメントだと思う。
チームビルディングの開始早々で火事になったらどうする？
カリスマPMに助けてもらう。
メンバの信頼関係がちゃんとできてないうちに火事になったら、消火を得意としている人に助けてもらうしかない。
この手のPMとは、マネジメントスタイルが異なるために、進んで火消しには来てくれない。
でも、人は頼りにされることをそんなに嫌がらないので、その頼みが1回なり2回ならやってくれますよ。
その時は、懇願するのです。先輩後輩とか関係なく。
当然重なれば、そのPMが言うまでもなく、メンバからの信頼もなくなりますから、助けてもらった時は、全力で立て直しに協力です。
うまく行っていても、火事になっても振り返りが重要。
あの時の対応が最適か？という観点で、
- 続けていくこと
- やめた方がいいこと
- 次への改善
また、積み残したことの棚卸しもする。
最後にアクションと担当者とスケジュールを決める。
ここでのスケジュールは、そのアクションの実行スケジュールをいつまでに担当者が考えてくるかというもので、アクションの実施予定ではない。
まあ、特にタスクが溜まりまくってなければ、次週が期限になるわけ。
"何を優先にしますか？"
タスクが溜まってくると、こんな言葉をよく聞く。
溜まる前に予期して、しかるべきリソース分散させるのが理想だが、予期した直後にコピーロボットでも現れない限り無理。
また、余剰人員がいたとしても、余剰人員は大抵戦力外だし、戦力になるとしても緊迫した現場でコミュニケーションも最小限になりがちなところに入った経験がないときつい。
じゃあどうする？
まずは、タスクをカード化するんだろうな。バグ票とかは良くやるけど、それと同じ発想。
タスクを眺めて、取りに行く。
空いてるスペースにみんなが見れるようにポストイットで貼り付けておく。
朝会で、カードをみて誰がやるのか決めさせる。
この時、優先順位は決めておかないといけない。
どうせ、カードは全員分より多いから。
また、タスクの内容によっては、能力・経験値で消化可否が決まっていたりする。
でもカード化することで、消化困難なメンバに割り当てざるを得ないという事も全員が認識する。はずだ。
まとめ
私の薄目の経験を元に、マネジメントについて仮説してみました。
経験的に1番有効なのが、ゴールをチーム全員が同じ認識、価値観で進めること。
本日反省会のご案内がメンバーから来ました。
その他にもメンバーの成長が感じられる場面も多い。そういう出来事をエネルギーに頑張っていきましょう。
スクラムマスター
本日はヒカリエで、s'crum Master's Nightに参加してきました。
どんなマスター達がいるのか、どんな経験を持っているのか、簡単なのか、儲かるのか、そんな事を期待しながら。
アジェンダみるとディスカッションテーマもその場で募集して、投票の多いものを選択して行うという形式。
これなら、こちらの持つ懸念、疑問とかがマスター達と話しやすそうだと思い、参加してみた。
感想としては、この会合が三回目ということもあって、参加者がルールを良く理解してるのか、参加するからには何かもやもやをスッキリさせて帰ろうと思ってるのか、変な沈黙が少なくて、とても居心地が良かった。
テーマ募集
テーマがたくさん出て来るのかと思ってたが、意外に初動は遅く、1人が出してから、少しずつ出てきた。
自分もテーマ出してみた。投票がないとさみしいとか無かったし、選ばれなければ他のテーマで面白そうなところに参加すれば良かったので。
でも、選ばれた！
テーマは、「スクラムって儲かるの？」でした。
ディスカッションは、1時間
関係ないけど、テーマ的にピンと来なかった場合は、ファシリテーターのキャラで選ぶって楽しみもありますね。
なかなか個性的な人も居ましたし、完全に中立主義みたいな雰囲気の人もいました。
今更ながら、
テーマは決めたが、ゴール決めとけば良かった
と思いました。
なので、私へのヒアリングから入ったわけですが、これから始めて見る価値を自分なりに理解したいということから、「お金」に着目してみた。
もちろん、お金以外のメリットはたくさんあるとは思うが、
ステークホルダー達への説明がしやすいのが「お金」なので。
スクラム導入支援は儲かるよ！
いわゆるコンサルタント。
まあ、これは最近になって急にもりあがって来たので、引き合いがあるんだろう。
でも、これってせいぜい1人しか儲からないじゃん？
それに
私のイメージでは、スクラムでソフトウェア開発、つまりチームの生産能力を上げるものみたいな話がしたかった。
コンサルの話では、
1度軌道に乗せても、離れると問題チームになったりするらしい
というのが気になった。
やはりコンサルタントってそういう仕事っぷりなんだよなぁ。
ゴール設定が無かったので
話が発散してしまったが、
人数が少なかったため、短時間ながらみなさんがちゃんとディスカッションに参加してくれたことが本当に良かった。
SIerのようなな受託開発領域に導入するなら、
保守、維持管理という固定費用の世界が向いてるかも？
という意見がありました。
スプリントのイメージが全くわかなかったけど、チーム維持が保証されてる中なら、まあやろうとすることは出来そう。
スクラムの最大の効果は、
人が育ちやすい
人が育つから生産性も品質も上がってく
そして、利益が出る、ということ。
チームのメンバが全員XPやTDDを短期間で経験するし、ウォーターフォールのように途中でサボれないから、凄く一生懸命スプリントを回して行くからねっ！
ウォーターフォールはサボれる？
確かに可能性はあるが、最後で
それ、ちげーよ！
みたいなどんでん返しあるから、サボってられない。リカバリ覚悟してれば、サボれるけど。
まあ、でも一旦要件が決まって、仕様も承認されると、受け入れまでは、
気が緩むのは否めない
多少新規技術要素とかで盛り上がるし、見えるものを作ってるとそうでもないが、Webポータルでないサーバアプリは見えないから設計工程、製造工程共に盛り上がりにかける。
そんな心理で作り込むから、試験工程で大変盛り上がる。バグが収束しない時なんかオールでお祭りですからね。
そもそもSIerは、開発プロセスがしっかりしてるから、信用されてる
そんなことは誰も言ってなかったが、最後にはちゃんとしたものを納めるためのチェック機構で歯止めがかかってる。
でも今は
そんな事は望まれてなくて、
早く安く
その代わり、SLAは相応のものにしてもいいよ！
なのである。
で、Scrumというかリーン
というのが注目されてる気がする。
おそらく、私のようなにわか知識でスクラムやるってのは、何回か失敗することが許容されてないと、ダメなんだろうな。
じゃあ、ウォーターフォールなら失敗しないの？
そんな事も言えない
だから、スクラムでやっちゃえばなのかもしれない。
自分がやるなら、スプリントをどのように回すかという仕組みの部分を構築して、メンバーにレクチャーしてから始めるかな。
で、この仕組みの構築だけを、しれっと導入支援してくれる人がいれば十分だと思った。
じゃあ、儲かると思うか？
ディスカッションではケース出しに終始したんだが、チームにいた方から、こんな本を紹介された。
次回までに読んでおこう。
Fearless Change アジャイルに効く アイデアを組織に広めるための48のパターン
- 作者: Mary Lynn Manns,Linda Rising,川口恭伸,木村卓央,高江洲睦,高橋一貴,中込大祐,安井力,山口鉄平,角征典
- 出版社/メーカー: 丸善出版
- 発売日: 2014/01/30
- メディア: 単行本（ソフトカバー）
- この商品を含むブログ (11件) を見る
まとめ的な話
この会合での私の結露は、
PM経験がそれなりで、ファシリテーション力があれば、
先ほどの仕組みを使って、アジャイルで成功することができるんじゃないかな？
ってこと。
ちなみに、仕組みというかツールも見つけた。AlminiumというOSSパッケージ。これは、RedmineのBacklogプラグインやJenkinsを統合したもので、バックログアイテムの状況をカンバンのように表示できるようになってる。
これは、朝会と夕会で共有しやすい。
更にWebなので、AWSとかで作っちゃうという手もあり、開発拠点が離れてても共有しやすいわけです。
また、過去の会合の中で、似たような議論をされた方が居たようで、大変参考になりました。
最後に
今回のチームの皆様、ファシリテーターしていただいた方、本当にありがとうございました。
そして、時間が本当に短く感じられて、楽しかったです。
また、お邪魔しようかな。
