これからが本格的な活動

久しぶりの投稿になりました。

昨年の9月30日でブログが書けなくなってました。

前回の記事で、振り返りか大事、振り返りをしっかりしろと書いていたので、半年以上の期間を見返してみて、再発防止に努めてみたいと思う。

まず9月末といえば、10.01の組織変更

ところが、管理職である以上、よっぽど刺激的、またはショッキングでなければその内容を受容するくらい。

現に自分、周りを見渡しても何の変化もなかった。そもそもその時期は、、、プロジェクトがまだまだ落ち着いておらず、そんなことも気にしてられなかった。

だから、あんな記事を書いたんだと改めて思った。

また、昨年9月末くらいになると実は落ち着いていたわけだが、落ち着きすぎて大事な事を忘れてたって事なんだろう。

そのまま年末を迎え、1月の組織変更、勤務地変更があり、まずはミッション理解とチーム形成で手一杯になってた。

なにしろ、次から次へと決まってない事が出てくるし、かつ決めてもらえないというSIer泣かせの進行。

セオリーとか、これまでの経験とか、プロマネに関してはほぼ意味をなさなくて、業務知識が少ない状況では日々出てきた課題を片付ける事に費やした。

毎日仕事した感はあったが、振り返ると何も進んでないみたいな。

こうやって感覚が麻痺してる人になっていきそうだなぁ。

ところが2月に大どんでん返しがあった。

これまで進めてきた要件が、丸っと否定され方向転換。内容は書けないが、2ヶ月くらい調整した事が全て無効くらいなダメージ。

これくらい大きな話になってくると、お客さんも納期を気にし始めるので、調整が早くなってくる。

プロマネも立て直し策が有効になってくる。メンバーも迷わず動けてくる。

とはいえ、期間少ないなぁ。

人増やさないとタスク溢れてきたなぁ。

調整しなきゃいけない事もまたまだあるなぁ。

でも普通のプロジェクトっぽくなってきたし、自分自身がマネジメントに時間を避けられるようになってきた。

チームのタスク指示に集中し始めたので、そろそろ別のチームのメンバーフォローにも回っていこう。

本来のミッションはそこだから。

どうしたらチームが強くなるかな

何かの役に立つ、誰かの役に立つことが実感できれば、人は強く生きれる。

いきなり思いついたことを書いてしまったが、、、

それには、個々人のお役立ち事項をまずは引き出してやらないといけない。

引き出した後は、可能な限りそれを伸ばしてやらなければならない。

抵抗勢力に立ち向かう信念を持たさなければならないし、一緒に戦ってやらねばならない、仲間を増やしてやらなければならない。

それが監督というか、マネージャーの仕事なのかな。

チームを強くするには、メンバーに強くなってもらわなければならない。理想を言えば、要件定義、設計、製造、テストがそれなりの生産性と品質で実行できるメンバーで構成される状態。

マネージャーは、チームの仕事の進行状況を監視しつつ、お客様とチームに最適な仕事カードの調整だけをする、とか。

そんなにうまくいかないんですけど、

まずは自分のマネージャーとしての方向性を信じることから始める。

トップダウンの組織運営はダメ

合意形成で進めるんだ！

そういう思いは、もう4〜5年前からあって、自分なりに同僚達と進めて来た。

だぃぶ意識が高くなり、自分が所属しないチームでもどんどん進んでいるし、所属チームでも自分が牽引しなくても目標を高く設定してるにも関わらず、小さい成果を実感するような取り組みを勝手にしている。

明確に指示がなくても、

同僚達が最善な方法を学習し、なんとかしたいことを自ら行動に起こしているということになる。

これは、2年前からすると凄い変化になる。

強い組織、チーム

考え方は二つある。

1. トップのカリスマ性を持って、絶対信頼と服従による運営
   
2. 合意形成によるチームビルディング

前者は、火消しには大変有効。迷ってる時間がないから、百戦錬磨のPMが音頭とって進めるとどうにか火事が収まる。これはこれで必要だが、火事の原因を突き詰めないと、次も火事が起こるし、下手すると他にも引火する。人海戦術とかで、ね。

なので、後者を選択したい。

ぶっちゃけ、火消しで音頭取るようなカリスマ性はないからというのもあるが、火事にしないのが正しいマネジメントだと思う。

チームビルディングの開始早々で火事になったらどうする？

カリスマPMに助けてもらう。

メンバの信頼関係がちゃんとできてないうちに火事になったら、消火を得意としている人に助けてもらうしかない。

この手のPMとは、マネジメントスタイルが異なるために、進んで火消しには来てくれない。

でも、人は頼りにされることをそんなに嫌がらないので、その頼みが1回なり2回ならやってくれますよ。

その時は、懇願するのです。先輩後輩とか関係なく。

当然重なれば、そのPMが言うまでもなく、メンバからの信頼もなくなりますから、助けてもらった時は、全力で立て直しに協力です。

うまく行っていても、火事になっても振り返りが重要。

あの時の対応が最適か？という観点で、

• 続けていくこと
• やめた方がいいこと
• 次への改善

こんな感じで振り返る。

また、積み残したことの棚卸しもする。

最後にアクションと担当者とスケジュールを決める。

ここでのスケジュールは、そのアクションの実行スケジュールをいつまでに担当者が考えてくるかというもので、アクションの実施予定ではない。

まあ、特にタスクが溜まりまくってなければ、次週が期限になるわけ。

"何を優先にしますか？"

タスクが溜まってくると、こんな言葉をよく聞く。

溜まる前に予期して、しかるべきリソース分散させるのが理想だが、予期した直後にコピーロボットでも現れない限り無理。

また、余剰人員がいたとしても、余剰人員は大抵戦力外だし、戦力になるとしても緊迫した現場でコミュニケーションも最小限になりがちなところに入った経験がないときつい。

じゃあどうする？

まずは、タスクをカード化するんだろうな。バグ票とかは良くやるけど、それと同じ発想。

タスクを眺めて、取りに行く。

空いてるスペースにみんなが見れるようにポストイットで貼り付けておく。

朝会で、カードをみて誰がやるのか決めさせる。

この時、優先順位は決めておかないといけない。

どうせ、カードは全員分より多いから。

また、タスクの内容によっては、能力・経験値で消化可否が決まっていたりする。

でもカード化することで、消化困難なメンバに割り当てざるを得ないという事も全員が認識する。はずだ。

まとめ

私の薄目の経験を元に、マネジメントについて仮説してみました。

経験的に1番有効なのが、ゴールをチーム全員が同じ認識、価値観で進めること。

本日反省会のご案内がメンバーから来ました。

その他にもメンバーの成長が感じられる場面も多い。そういう出来事をエネルギーに頑張っていきましょう。

スクラムマスター

本日はヒカリエで、s'crum Master's Nightに参加してきました。

どんなマスター達がいるのか、どんな経験を持っているのか、簡単なのか、儲かるのか、そんな事を期待しながら。

アジェンダみるとディスカッションテーマもその場で募集して、投票の多いものを選択して行うという形式。

これなら、こちらの持つ懸念、疑問とかがマスター達と話しやすそうだと思い、参加してみた。

感想としては、この会合が三回目ということもあって、参加者がルールを良く理解してるのか、参加するからには何かもやもやをスッキリさせて帰ろうと思ってるのか、変な沈黙が少なくて、とても居心地が良かった。

テーマ募集

テーマがたくさん出て来るのかと思ってたが、意外に初動は遅く、1人が出してから、少しずつ出てきた。

自分もテーマ出してみた。投票がないとさみしいとか無かったし、選ばれなければ他のテーマで面白そうなところに参加すれば良かったので。

でも、選ばれた！

テーマは、「スクラムって儲かるの？」でした。

ディスカッションは、1時間

関係ないけど、テーマ的にピンと来なかった場合は、ファシリテーターのキャラで選ぶって楽しみもありますね。

なかなか個性的な人も居ましたし、完全に中立主義みたいな雰囲気の人もいました。

アジャイル開発推進は、ファシリテーションスキルが必要なので、そういう目線での参加でも何か持って帰れると思います。

特に、この1時間の使い方は、ファシリテーターに任せてるのがいいですね。最後にファシリテーターに対してのフィードバックも忘れずに。

今更ながら、

テーマは決めたが、ゴール決めとけば良かった

と思いました。

なので、私へのヒアリングから入ったわけですが、これから始めて見る価値を自分なりに理解したいということから、「お金」に着目してみた。

もちろん、お金以外のメリットはたくさんあるとは思うが、

ステークホルダー達への説明がしやすいのが「お金」なので。

スクラム導入支援は儲かるよ！

いわゆるコンサルタント。

まあ、これは最近になって急にもりあがって来たので、引き合いがあるんだろう。

でも、これってせいぜい1人しか儲からないじゃん？

それに

私のイメージでは、スクラムでソフトウェア開発、つまりチームの生産能力を上げるものみたいな話がしたかった。

コンサルの話では、

1度軌道に乗せても、離れると問題チームになったりするらしい

というのが気になった。

やはりコンサルタントってそういう仕事っぷりなんだよなぁ。

ゴール設定が無かったので

話が発散してしまったが、

人数が少なかったため、短時間ながらみなさんがちゃんとディスカッションに参加してくれたことが本当に良かった。

SIerのようなな受託開発領域に導入するなら、

保守、維持管理という固定費用の世界が向いてるかも？

という意見がありました。

スプリントのイメージが全くわかなかったけど、チーム維持が保証されてる中なら、まあやろうとすることは出来そう。

スクラムの最大の効果は、

人が育ちやすい

人が育つから生産性も品質も上がってく

そして、利益が出る、ということ。

チームのメンバが全員XPやTDDを短期間で経験するし、ウォーターフォールのように途中でサボれないから、凄く一生懸命スプリントを回して行くからねっ！

ウォーターフォールはサボれる？

確かに可能性はあるが、最後で

それ、ちげーよ！

みたいなどんでん返しあるから、サボってられない。リカバリ覚悟してれば、サボれるけど。

まあ、でも一旦要件が決まって、仕様も承認されると、受け入れまでは、

気が緩むのは否めない

多少新規技術要素とかで盛り上がるし、見えるものを作ってるとそうでもないが、Webポータルでないサーバアプリは見えないから設計工程、製造工程共に盛り上がりにかける。

そんな心理で作り込むから、試験工程で大変盛り上がる。バグが収束しない時なんかオールでお祭りですからね。

そもそもSIerは、開発プロセスがしっかりしてるから、信用されてる

そんなことは誰も言ってなかったが、最後にはちゃんとしたものを納めるためのチェック機構で歯止めがかかってる。

でも今は

そんな事は望まれてなくて、

早く安く

その代わり、SLAは相応のものにしてもいいよ！

なのである。

で、Scrumというかリーン

というのが注目されてる気がする。

スクラムは経験してないので、下手なことは言えないが、誕生から10年くらい経過してて、ツールはそれなりに揃ってる。

ただ、スクラムでやるか、ウォーターフォールでやるかのジャッジに正解がない。

おそらく、私のようなにわか知識でスクラムやるってのは、何回か失敗することが許容されてないと、ダメなんだろうな。

じゃあ、ウォーターフォールなら失敗しないの？

そんな事も言えない

だから、スクラムでやっちゃえばなのかもしれない。

自分がやるなら、スプリントをどのように回すかという仕組みの部分を構築して、メンバーにレクチャーしてから始めるかな。

で、この仕組みの構築だけを、しれっと導入支援してくれる人がいれば十分だと思った。

じゃあ、儲かると思うか？

ディスカッションではケース出しに終始したんだが、チームにいた方から、こんな本を紹介された。

ここには、ウォーターフォールからアジャイルにする時のノウハウが書いてあるらしい。

次回までに読んでおこう。

Fearless Change アジャイルに効く アイデアを組織に広めるための48のパターン

まとめ的な話

この会合での私の結露は、

PM経験がそれなりで、ファシリテーション力があれば、

先ほどの仕組みを使って、アジャイルで成功することができるんじゃないかな？

ってこと。

ちなみに、仕組みというかツールも見つけた。AlminiumというOSSパッケージ。これは、RedmineのBacklogプラグインやJenkinsを統合したもので、バックログアイテムの状況をカンバンのように表示できるようになってる。

これは、朝会と夕会で共有しやすい。

更にWebなので、AWSとかで作っちゃうという手もあり、開発拠点が離れてても共有しやすいわけです。

また、過去の会合の中で、似たような議論をされた方が居たようで、大変参考になりました。

「 Scrum Masters Night （スクラムマスターズナイト）」に参加してきました #smn - HOW TO GO

最後に

今回のチームの皆様、ファシリテーターしていただいた方、本当にありがとうございました。

そして、時間が本当に短く感じられて、楽しかったです。

また、お邪魔しようかな。

課題の処理方法を考えてみる

リーン開発の本を読んでいても、現在最強とも言えるWaterFall配下で仕事してる関係で、そっちがすごく気になる。

リーン開発の本を読みながら、思いついたことをブログにして、実践して見るという営みにしてみよう。

このブログは備忘録

なのでね。

今日は

課題表について

業界に限らないかもしれませんが、やたらと列がある課題表を使ってます。

まあ、いろんな情報がフィルタで絞り込めるメリットがあるんですが、

にしても、横に長すぎるよ

画面が横に伸びるか、マルチディスプレイでないと、、、

こんな表で管理するのは、利用者の立場によって見たり更新する場所が異なるというのが事情なのである。

1. 課題登録
2. 課題受付、対応者振り分け
3. 課題対応
4. 登録者と対応者間の認識合わせ
5. 課題のクロージング

この他にも、課題がどれくらい難航してるかというのも見ないといけないし、対応者がオーバーフローしてて着手すらできてないとか、課題がプロジェクト全体に関係する場合はちゃんと周知できてるかなど、マネジメントの問題を解決しなくてはならない。

これらは、発生確率の非常に高いリスクで、放置すると開発メンバー数の稼働に跳ねるので、インパクトが大きい。

なので、

リスク顕在化への予兆検知

ができるようにしておかないといけない。

こんなパラメータが課題表から自動的に集められれば、判断できそうだ。

• 課題登録日から、何営業日経過？
• 対応指示日から、何営業日経過？
• 対応完了日から、何営業日経過？
• 現在その課題(つまり、EXCELの行)は、誰のアクションか？

判断した後、適正な稼働指示になるかはわかりませんけど、無駄に止まって工数垂れ流しみたいなことにはならないと思いました。

もちろん、登録者、受付者、対応者の名前、それぞれの開始／終了日付が記録されてる必要がありますね。

本当にExcel課題表でいいの？

Excelには、ブックの共有というのがあり、複数人で同時に編集することができますが、編集に制限もありますし、結構デグレや破損の事故も発生します。

確かに、手軽に使えますけどねぇ。

いろんな情報を取り込んだ、一見完璧とも言える課題表は、

完璧に使える人が課題表作った人だけ

という問題もあり、

完全な形で運用されない

最悪

課題が放置される

何ヶ月も

でも何故か放置されてる課題は、メンバー内では解決してたりするわけですが、その決定経緯がわからず、大問題になったりもしますよね！

結論から言うと、

カンバン

のしくみ、チケット駆動の運営で、ステータスと稼働をメンバー全員で見えるようにしておくのが1番いいと思いました。

さあ、どうやって変えていこうかな。

リーン開発の解釈

これまた久しぶりの更新。

アジャイルが一時的に流行り出し、感覚的には言葉自体があまり使われなくなったかなあ、と思っていたんですが、最近になって近場で浮上。

というわけで、私自身が不勉強なので、読書して正しく理解はしておこうと思いました。

タイトルが「リーン」となってるのは、呼び方の問題。実際日本では、トヨタ生産方式「TPS」という方がメジャーなのかもしれません。

自動車生産方式をTPS、ソフトウエア開発方式をリーンと区別しますかね。

方式というより、精神・ポリシーというのが定まってますね。

概要

• 全体を最適化する
• ムダをなくす
• 品質を作り込む
• たゆまぬ学び
• 速く提供する
• 全員を巻き込む
• 改善を続ける

重要なのは、全員を巻き込むことでしょう。

次に開発フレームワークとして

スクラム

• 順番づけされたプロダクトバックログ
• 職能横断型チーム
• スプリント
• 継続的にリリース計画を調整する
• 継続的にプロセスを調整する

プロダクトオーナーとスクラムマスターという役割がポイントのようです。

後は、イテレーションという短いスパンで開発を進めて、こまめにリリースして、イテレーション後に都度振り返り、プロセスを調整する改善しながら進めるという感じです。

で、実際の開発は

XP(エクストリーム・プログラミング)

こいつは、いくつか方法があって、XPだけを使って、「アジャイル開発やってます」みたいなことを聞いたりもしましたが、今はさすがにないかな。

で、方法とは

• 継続的インテグレーション
• ペアプログラミング
• テスト駆動開発
• コードの共同所有
• インクリメンタルな設計の改善

で、製造工程を可視化するのが

カンバン

少し前だと、ホワイトボードにワークフローを列にした表を書いて、ポストイットにタスクを貼り付けて、そのポストイットに担当者の名前を書いて進めたことが思い出された。

違いは、下記のWIP、つまりワークフロー単位に作業制限を加えてないことだったのか。

制限無かったから、対流状況がいまいち共有されなかったんだと思われる。

ポイントを以下に示します。

• ワークフローを可視化する
• WIP(仕切り作業)を制限する
• サイクルタイムを測定し管理する

これらを見ると、OSSのRedmineというツールがマッチするように思いました。

実際カンバンを意識して構築することができれば、滞留状況やWIP制限なんかもRedmine側で検知・ガード・優先予約とかもできそう。

しかも、このかんばんという開発推進方式は、10年の歴史があるので、Redmineのプラグインにありそうですね。

概要としては、以上です。

実践的なところを、後日図で補強しますね。

リーン開発の現場 カンバンによる大規模プロジェクトの運営