2024.10.01
自社の社内情報を未来の“ゴミ”にしないための備え 「情報量が多すぎる」時代がもたらす課題とは?
リンクをコピー
記事をブックマーク
渡会健氏(以下、渡会):あと、もう1つ次のヒントで、イテレーション0をやらないアジャイルは出だしでつまずくんじゃないかなというところで、よく、アジャイルをやるための準備としてイテレーション0、もしくはスプリント0というものをやりましょうという話をします。
その時によくアジャイルの本で書いてあるのは、こちらです。「インセプションデッキを作りましょう。ユーザーストーリーマッピングをやりましょう。それで初期プロダクトバックログを作りましょう」。
これ、大事です。作るものの準備のRebuildもしなきゃいけないんですが、意外に忘れがちなのは作り方の準備ですね。
ソフトウェア開発の場合、どんなことをするかというと、構成管理のルールを決めたり、コーディング規則を決めたり、やってみて、「あぁ、ここ違うな」と思った時にどんどん改善するのはいいんですが、初めから野放図で当てずっぽうで始めるんじゃなくて、最初からそういったものを決めていく。
イテレーション1が始まった時には、もう使える成果物が出せる準備を整えていく。この両輪が必要なんですが、だいたいこっち側(アジャイルプロセスのための準備)だけで終わっちゃうことが多いので、やるとしたら、作り方の準備をやっていただければなと思います。
作り方の準備をやらないで、結局作り始めてから「あれがうまくいっていない」「これがうまくいっていない」となると、実際のものづくりに集中できないということが生まれちゃったりもします。
あとは、イテレーション0する時にはスキルマップを作ります。このスキルも、アジャイルなのでやはりRebuildしていくよというかたちでやります。
例えば参画した当初、自分はこういったところに強みがありますよ。プロジェクトが終わった時にはこういったところを伸ばしたいですよ、みたいなことを見える化しておく。こういうことをしていくと、実際にタスクをやっていく中で、モブワークなりペアワークなりをする時に、誰と誰を組めば技術のトランスファーができるかね、みたいなことを考えながらやっていける。
スキルそのものをみんなでRebuildしていくことができる仕掛けがけっこうあったりします。
もう1つ、最後のヒントですが、「生産性の高いチームほどコミュニケーションを惜しまないようになるのはなぜか?」というところで、コミュニケーションの取り方のスタンスもだいぶ違っています。
例えばウォーターフォールの場合、できるだけ作業者の手を動かす時間を増やしましょうということに着目します。「そのために会議の時間を短くしましょう」とかね。「とにかく個人がワークできる時間、手を動かす時間をなるべく増やそう、そのために会議を減らしましょう、会話を減らしましょう」。そういったことをけっこうしていくことがあります。
アジャイルではどうするかというと、いかに能力の差を縮めるかというところで考えた時に、プランニングが結局、肝になっていくんですね。だいたい生産性に大きく差が出るのは、いわゆる従来型開発でいうところの設計フェーズですね。
要は、何をどうやって作るのかっていうところで、経験値とか、こういう関数があるとか、知らない使い方だったりとか、ベテランだったら知っているようなノウハウをプランニング会議で全員で共有する。そういうことをすると、あとは手を動かすだけになっていくんですね。
このタスクを振られました、そこから自分で一生懸命やり方を調べてやっていくのではなくて、モブワークじゃないけれど、みんなでモブ設計をしていって、こういうふうにしていくんだよというのをプランニングの中でやってしまえば、あとは新卒だろうがなんだろうが、手を動かすことができる。誰でも助けやすくなる。それはなんでかというと、モブワークの時にどういうものを作るかをみんなで共有しているから。
そういうことをすると何が起きるかというと、一生懸命コミュニケーションを取ろうとするんですよ。プランニングの会議だけじゃないです。実際にタスクを実行する時に、あちこちで話し合いが行われるんですよ。「ここ、どういうふうに作るんだっけ?」「あっ、こうだったよね」「あっ、じゃあ、こう作ろうね」みたいなのをどんどんどんどんやってコミュニケーションをどんどんどんどん高めていく。こういうことをして、実は効率を高めていくよというかたちをしているのがアジャイルの仕組みなんじゃないかなと思っています。
実はMSOL(株式会社マネジメントソリューションズの略称、エムソル)に来てから、研修のテキストみたいなかたちでノウハウを溜めていたのですが、それを今回、全部Rebuildして、ノウハウもRebuildをして、本のかたちにまとめています。もしご興味があれば見ていただければなと思います。
今、我々は、MSOLの中でデジタルを推進していくためには、アジャイルのNo.1カンパニーを目指していかなきゃいけないよねということでやっています。
最後に、今日は後ろのほうのスポンサーブースで、いろいろなものを配っています。今日の講演ではしゃべっていませんが、弊社の事例をまとめたパンフレットをお配りしていますし、抽選で本などが当たります。
あとは、先ほど経歴の中にあったとおり、私はIPAの回し者でもあるので(笑)、そこで出している冊子も置いてあります。IPAの冊子は無料で配っているので、ぜひ取りに来ていただければと思います。
それでは、本日の講演は以上とさせていただきます。どうもありがとうございました。
(会場拍手)
司会者:渡会さま、ありがとうございました。ここから5分間のAsk the Speakerに移ります。質問がある方は挙手をお願いします。いかがですか?
質問者1:お話、ありがとうございました。渡会さん、先ほど資料の中で、従来のプロジェクトマネージャーの役割の変化、ロールのRebuildについてお話しされたと思うんですけど。
クライアントさんにこういったご提案をする、ご紹介をする時に、クライアントの社内事情でどうしてもできない場合はありますか? もしそういうことがあった場合、どういったご提案やアプローチをされているのかをちょっとお聞きしたいです。例えば、適切な人がいないとか、いろいろあると思うんですけども。
渡会:一番、ここに気をつけてくださいというところで、「従来のプロジェクトマネージャーの意識、役割のままでアジャイルチームにどっかりと入らないでください」と言います。
もし、その立場の人たちが入るのであれば、どの役割かを自分で絞って、その役割に専念してくださいという話をすることで、1人の人に責任の集中するリスクを下げています。
ただ、やはりスクラムマスターという役割は、従来型のことをやっている人たちにはなかなかなじまないので、こういったところは、我々がサポートしたり、スクラムマスター代行を出したりとか。スクラムマスターが育つまで、我々が人を出して支えますよ、みたいなことはやっていたりします。
質問者1:ありがとうございました。
司会者:(質問を見て)「年単位でアジャイル、スクラムで開発をしている場合、どの程度の頻度でイテレーション0を行えればいいでしょうか?」とあります。
渡会:年単位でアジャイル、スクラムの開発……年単位であろうがなんだろうが、我々は、そのチームの成熟度だったり、そのプロジェクトの特性で考えています。
例えば、チームがよちよち歩きでこれからアジャイルを学んでいかなきゃいけないという状況の時には、学びの機会とやり直しをする機会をできるだけ増やしたいので、1週間スプリントのような短いスプリントを提案することが多いです。
アジャイルに慣れていないから長い期間でやりたいというのは逆効果で、アジャイルに慣れていないからこそ短い期間でやっていかないとなかなかうまくいかない。
我々が新卒を教育する時には、1dayスプリントをしてアジャイルを教育したりしています。短いほうが教育効果は高まります。
逆に、ある程度アジャイルを何度もやっているメンバーでやっている時は、アジャイルにいちいち慣れる必要はありません。そうなるとタスクを作る時間のほうを増やしたほうがいいよねということで、1ヶ月スプリントみたいなことをしたり、普通に2週間スプリントでやったりしています。プロジェクトの期間が長い短いは関係なく、そういったリズムで選ぶことが多いです。
司会者:ほかに会場から、いかがでしょうか? 前のほうにいらっしゃいますね。
質問者2:ウォーターフォールとアジャイルのどちらを選択するかといった部分で、将来の予想がしやすいものがわりとウォーターフォールで、市場などの変化の影響を受けるものがアジャイルなのかなと認識してるんですけど。
数年単位の長期的な開発を前提にした場合、計画を出せるウォーターフォールのほうが適している気もしているのですが、数年単位だともちろん影響をいろいろ受けるのでアジャイルのほうがいいような気もしていて。
もう少し前提条件は増えるかもしれませんが、そういった部分だとどちらが適しているのか、もしくは、それぞれどういったメリットがあるのか聞きたいですね。
渡会:私の私見ですが、プロジェクトが長ければ長いほどアジャイルのほうが適していると思います。何が起こるかわからない世の中なので、計画を1回で立ててそこからもう動かせなくなってしまうというのは、非常に危険だと思います。
むしろ、半年とかで、「もうここまでの期間だったら状況も変わらないよね、一気に作ろうね」というプロジェクトこそ、ウォーターフォールでがっちり作ってしまったほうがいいんじゃないかなというのが私の感覚です。
質問者2:ありがとうございます。その場合、長期的な開発の最終的なゴールとして、わりとざっくりしたものを置くことになるんですかね。
渡会:それこそイテレーションが終わるたびに目標そのものを見直しています。要は、この目標で正しいのかを毎回毎回スプリントが終わるごとに確認している。
質問者2:ありがとうございます。そういうことですね。ゴールもそのたびに(設定する)ということですね。
渡会:はい。
質問者2:ありがとうございます。
司会者:そのほか、いかがですか?
質問者3:講演ありがとうございました。最小限の機能でリリースして、ROIを最短で向上することを判断するとうかがっていますが、競合他社もいる場合、これを出せば勝ち筋があるなとか判断するのは、開発メンバー、アジャイルメンバーだけだと厳しいとは思います。役員や部長など入って、どのように判断されるのか。MVP(Minimum Viable Product)と言われるところの決め方を教えていただけないでしょうか?
渡会:ありがとうございます。理想論でいくと、その人の立場はあまり関係ないです。現実論として偉い人が入ってくることがありますが、その偉い人ってだいたい忙しいんですよ。忙しくて意思決定をする暇がない人から決定権をもらえる、自由に考えられる人がプロダクトオーナーに座るというのが、肝かなと思います。
本当の責任者、最終的に責任を取る人がそのままプロダクトオーナーをやると、だいたいほかのことで忙しくてあまりやってくれないんですね。であれば、それに対しては「あなたたちに権限を渡しますよ」というところを出してやったほうが機敏な企業戦略には対応しやすいんじゃないかなと思います。
質問者3:では、MVPは、権限をもらったプロダクトオーナーが決めるということでよろしいですかね?
渡会:そうです、そうです。
質問者3:はい、ありがとうございます。
司会者:以上でお時間となりましたので、講演を終了させていただきます。渡会さま、ありがとうございました。
渡会:はい、ありがとうございました。ぜひブースにお越しください。
(会場拍手)
2024.10.29
5〜10万円の低単価案件の受注をやめたら労働生産性が劇的に向上 相見積もり案件には提案書を出さないことで見えた“意外な効果”
2024.10.24
パワポ資料の「手戻り」が多すぎる問題の解消法 資料作成のプロが語る、修正の無限ループから抜け出す4つのコツ
2024.10.28
スキル重視の採用を続けた結果、早期離職が増え社員が1人に… 下半期の退職者ゼロを達成した「関係の質」向上の取り組み
2024.10.22
気づかぬうちに評価を下げる「ダメな口癖」3選 デキる人はやっている、上司の指摘に対する上手な返し方
2024.10.24
リスクを取らない人が多い日本は、むしろ稼ぐチャンス? 日本のGDP4位転落の今、個人に必要なマインドとは
2024.10.23
「初任給40万円時代」が、比較的早いうちにやってくる? これから淘汰される会社・生き残る会社の分かれ目
2024.10.23
「どうしてもあなたから買いたい」と言われる営業になるには 『無敗営業』著者が教える、納得感を高める商談の進め方
2024.10.28
“力を抜くこと”がリーダーにとって重要な理由 「人間の達人」タモリさんから学んだ自然体の大切さ
2024.10.29
「テスラの何がすごいのか」がわからない学生たち 起業率2年連続日本一の大学で「Appleのフレームワーク」を教えるわけ
2024.10.30
職場にいる「困った部下」への対処法 上司・部下間で生まれる“常識のズレ”を解消するには