橋本：皆さん、こんにちは。パラダイスウェアの橋本です。
中島：中島です。
古長谷：古長谷です。
橋本：だれプロラジオ第29回は？
古長谷：「カンバンを使いこなすコツ」です。
カンバン方式とは
橋本：「カンバン」も今はかなり一般的…。
中島：一般的ですねー。「カンバン」知らないっていう人にはあまり、実は現場では会わないかもしれないですね、僕なんかは。
橋本：あとはこれから「カンバン」使っていくって、業界によってはよくあるかも。
中島：業界によってはね。僕らIT ガチガチだと大体あれですけど。
橋本：IT はそうですね。改めてカンバンって何かってご説明すると、元々はトヨタの管理方式と言うか、仕事の進め方で。カンバンっていうホワイトボードみたいなのがあって、誰が何するかというのを状態で管理するというのがカンバンなんですけど。これも正しいやり方や元々トヨタの生産方式がどうだったかっていうのは色々と本があり、ネットでも調べられるので、是非。
要するにタスクを、何を誰がやってるかを、その時のリアルタイムな状態で管理する事が出来るようにするというもので、結構革新的な管理方法です。マンモスプロジェクトにもカンバンはあります。カンバン自体は作るのそんなに難しくはないので、色んなツールで実装されてるのでかなり一般的になってきてはいるかなと思います。
ただ、シンプルなルーチンワークや、シンプルなプロジェクトとかだとワークするんですけど（有効である）。結構注意してマネジメントしないと、今何をやっているかは分かるけど、これから先に何をやるかが分からないケースが出てきちゃうので…。
中島：前後関係ですね。
橋本：そうですね。ここはノウハウが無いと、行方不明になるプロジェクトも結構あります。その辺りのコツが大事かなと思います。
カンバンが合うPJ かどうか
橋本：古長谷さん、カンバン使う？
古長谷：マンモスに出会う前はそれこそ付箋でやっていました。IT 業界じゃなかったので。
橋本：あのね、IT でも付箋の所いっぱいあって。
中島：ありますね。
古長谷：本当ですか？！
橋本：今ね、リモートワークのご時世なんで、付箋は基本使わないほうが良いんじゃないかなと僕は思いますね。付箋って何が良くないかって言うと、ログが残らないんですよ。僕昔から不思議なんですけど、なんでIT なのに皆同じ所に集まって、ホワイトボードに付箋貼っておくくんだろうって。
古長谷：付箋…。笑
中島：本当ですよね。
橋本：だって付箋って、小さなスペースに書くでしょ？情報そのサイズに収まる範囲で、そこだけしか残らないんですよ。
古長谷：確かに。
中島：そうですよね。
橋本：これだけで回せるタスクって、知れてるでしょ。
中島：そうですね。
橋本：やった感は出るんですよ。
古長谷：やっぱりToDo リスト止まりっていうの結構あると思います。
橋本：そう。一時期IT だとスクラムっていうのが流行って、今は割とスクラムスクラムって言う人は減ったんですけど、何故かって言うと、スクラム開発って前提条件があって、複雑なプロジェクトにはあまり向いていないんですよ。
その理由は、さっき中島さんが話した前後関係。何をまずやって、次何をやるかっていうのが言わなくても分かっているレベルの人達が集まったチームでないと機能しないんですよ。例えばソフトウェア作る時に、まず設計のここを固めないと、後でここの設計の部分が変わると凄く大変な事になる、やり直しになっちゃう。みたいなことが分かっていないと。先に例えば機能から作り始めたりするんですよね。
あるべきものが先に揃わないと、後で訳分かんない事になったりとかするんですけど、それで上手くいかないプロジェクトはいっぱいあるんです。だから前提条件をちゃんと把握した上で、自分のチームは本当にカンバンでいけるのかどうかっていうのをちゃんと確認しなきゃいけなくて。
カンバンとかスクラムが流行った時期って、アメリカのシリコンバレー、それこそマイクロソフトとかグーグルとか、物凄く給料の高い人達は、その前提、【言わなくても理解している人たちのチーム】になっているわけです。給料が年収何千万みたいなエンジニアのチームでやれば、彼らは当然「ソフトウェアっていうのはこういう風に作るもんだ」っていう前提で集まっている人達なので、カンバンで行けるかもしれない。
でも、日本の多分99.9% のプロジェクトはそうじゃないので、シンプルな管理しか出来なくなっちゃうんですよね。だから、マンモスプロジェクトの、プロジェクトマップとかを使って前後関係をちゃんと把握した上で使わないと、ぐちゃぐちゃになるケースが多いですね。
中島：そうですね、確かに。
カンバンを使いこなすコツ
古長谷：実践的に「カンバンを使いこなせる」コツみたいなものって何かありますか？
橋本：スクラム開発で「こういう事やりましょう」みたいなエッセンスみたいなのいっぱいあるんですけど、その中で必ず押さえといたほうが良い要素をお伝えすると、カンバンにまずタスク洗い出して、アサインして、誰が何やるか割り振っていきます。
割り振られた人は、自分がそのタスクを達成するまでにやらなきゃいけない事を自分で考えて、洗い出して、「今ここまで進んでます」ということを、逐次プロジェクトリーダーに、あるいはプロジェクトメンバーに共有するという心掛けが凄く大事です。
例えばマンモスだとタスクの中にコメントで書いておけば、誰が何やっているかっていうのは確認出来るので、報告がまず大事です。これをいちいちリーダーが聞き出さないといけないと、それだけでリーダーとの確認時間がボトルネックになっちゃう。メモ程度で良いので報告をちゃんとする事ですね。
あとは、カンバン使ってる時は、朝会をやりましょう。さっきもお話ししましたけど、カンバンで分かるのって「今」の状態だけなんですよ。今、誰が何をやっていて、どういう状況かしか分からないので、これから何をやるかみたいな話って、ちゃんとメンバーの中で認識を合わせる必要があるんですよね。
じゃないと、この人は全然プロジェクトの進捗に寄与しない仕事ずっとやっています、みたいな感じになっちゃう。だから、都度朝会のように、10-15分の短い定例をやって、今どうなっていて、これからどうするのかというのを相談する会を作るって事ですね。
あと、ポイントとしては、先ほど出たプロジェクトマップ。なぜプロジェクトマップを入れたかと言うと、複雑なプロジェクトだと手戻りや、「このタスクやっぱやらなくて良かった」みたいな話とかが出やすいので、そういうのが起きないように、前後関係をプロジェクト全体の中で把握しておくっていうところですね。
古長谷：日々変わる事をちゃんと全員に擦り合わせて、トップが分からなくならないように皆でちゃんとシェアしていく…。
橋本：そうそう。目標をちゃんと皆で共有する為に、朝会と、全体像の共有と、あともう1つやっておいたほうが良いのは「振り返り」。
古長谷：忘れがち。
中島：そうですねー。
橋本：振り返りはね、どうしても抜けがちなんですけど、忙しいプロジェクトの場合、皆自分のタスクの事だけに集中するんですよ。それはそれで良い事なんですけど、全体で改善したほうが良い事ってあるじゃないですか。
例えば、ビジネス的にはこういう風に動いてるんだけど、開発はこういう風に動いていて、その中でタスクが動いている場合に、ビジネス的な環境が変わりましたみたいな、条件が変わりましたみたいな話って、プロジェクトリーダーが話すタイミングが大事で、そういうのを定例で話したりとか。
あと、例えばソフトエンジニアの人がタスクやってる中で、会社のエアコンの温度が高過ぎて集中出来ないとか。
古長谷：ありますよね、大事。
橋本：大事だけど、それ単発で、例えばスラッグに「部屋が暑いです」って…書く人居るけど…。
中島：居る、居る。
古長谷：書けないです、なかなか。
橋本：普通は言いづらいじゃないですか。
中島：言いづらいですね。
橋本：だけど、その振り返りで、よくKPT っていう言い方をする振り返り。これもどこかの会でご説明したいと思うんですけど、Keep (良かった事・出来た事) と、Problem (課題) と、Try (新しく挑戦すること) みたいなのが毎週皆で出して、プロジェクト全体で改善しないといけない事みたいなの洗い出していくんですけど、そういう時に備品とか環境の話とかを言いやすい。Problem のところに、「気温が高過ぎて、エアコンの温度が高過ぎるんですけど」みたいな、ちょっと書いておくと「あ、じゃあ室温もうちょっと下げましょうか」みたいなね、話とかもしやすいし。
中島：そういう細かい事を解消していくのって、やっぱ生産性の向上に大事な事だから。
橋本：実は結構大きかったりするし、自分の仕事に関係無いんだけど気になる事って、積もっていくと離職の理由になったりもするので。話しやすい環境作りの為にも、振り返りやったほうが良いですね。
カンバンを使いこなすコツ：まとめ
橋本：では、「カンバンを使いこなすコツ」のまとめですね。朝会と振り返りと、カンバンが最適なのかどうかっていう確認が入っていれば凄く良いツールになると思います。という事で、だれプロラジオ第29回は…。
古長谷：「カンバンを使いこなすコツ」です。
中島：この動画が良かったと思ったら、グッドボタンとチャンネル登録、是非よろしくお願いします。
橋本：お願いします。
中島：それではまた次の動画でお会いしましょう。ご視聴ありがとうございました。
橋本：ありがとうございました。
