めっちゃ効率的な会議を目指そう ～3S会議
私は、会議の生産性については極めてこだわりがあります。
普段から行われている会議の生産性が、組織の生産性、成果に直結するといっても過言ではありません。
その会議のフレームワークに３S会議というものがあります。「Small Numbers」「Short Time」「Standing」の３つの「S」です。
この３つが実践できると、かなり会議のレベルがあがるでしょう。
Small Numbers
少人数での開催が大前提。その議論に必要なメンバーだけを招集しましょう。 立場上～～～、という人は不要です。
人がいればいるほど、不要な発言が増え、議論が発散してしまいます。
参加することに意義がある、というのはやめてしまいましょう。
Short Time
会議はせいぜい30分が理想です。クイックにやろうと思えば15分でできます。 長いのは悪です。
1時間と設定してしまえば、一時間かかってしまいます。 30分と設定すれば、30分で終わらせようと努力します。
半分か倍か、その差は大きいです。日々の積み重ねでより大きくなります。
Standing
立って行う会議は、上記の２つをより効率的にできます。
最近の私の流行りは、トラブったプロジェクトほど、スタンディング会議ができるテーブルを購入することです。
それだけでも、プロジェクト内の議論と意思決定が速くなります。
会議に関する過去記事
会議に関してこちらにも記事を書いていますので、興味あるものをご参照ください。
クリティカルパス上のボトルネックにプロアクティブに手を打とう
「タイムマネジメント」ということを考えるときに大切な考え方が2つあります。
それはクリティカルパスとボトルネックです。
クリティカルパスとは、プロジェクトマネジメントの考え方のうちの1つで、様々な多くのタスクが平行する中で、順序・依存関係を考えて最も長くなるタスクのつながりの経路をいいます。家を出てバスに乗って駅について、電車に乗って降りてオフィスに到着する。これがクリティカルパスです。この移動中にスマホでメールチェックするとか、午前中の会議の資料確認する、というのは、これらの作業が遅れてもオフィスに着く時間は遅れないのでクリティカルパスになりません。つまり、このクリティカルパスにある作業を遅れさせないことが重要になります。
ボトルネックとは、ボトル（ビン）のネック（首）にあたる部分で、ビンに入った飲み物を逆さまにして出そうとしても、ネック部分の太さ以上には出ていかないことからきています。つまり、ボトルネックを解消することが作業効率を上げることにつながります。
この２つを考えると、クリティカルパス上にあるボトルネックを解消することが仕事のスピードを上げるために重要となります。クリティカルパスを見極めて、そのパス上にあるボトルネックを解消する、ということになります。
そして、この上でさらに差をつけるポイントがあります。それはプロアクティブに手を打つ、ということです。ボトルネックがボトルネックになる前に手を打つのです。クリティカルパスがどのルートであるか、そしてパス上のボトルネックがどこになるかを思考を未来に先送りして先読みして、今から手を打つのです。
これはプロアクティブとリアクティブという表現もできます。ボトルネックが顕在化してからリアクティブにアクションを起こすか、顕在化する前に検知してプロアクティブに手当をするか、当然、後者の方が望ましいです。
ショートカットキーを使おう ～考える時間を増やすためになんの時間を減らすか
ビジネスパーソンにとって一番大切な仕事は「考えること」です。
考えることが人と差をつける大きな要素になります。そして考える時間が増えると、いずれか考えるという行為はそれほどの時間は必要なく、少しの時間でたくさんのことを考えることが可能になるのです。
考える時間を増やすために、いちばん効果的に仕事を短縮しやすいパソコンのショートカットキーです。全くショートカットキーを使わないという人はあまりいないと思いますが、［Ctrl］+［C］や［V］、［S］だけでなく、どれくらいのショートカットキーを使いこなすことができるかどうかが大きな差となります。
ショートカットは非常にたくさんありますので、全てを知っている必要はありません。ショートカットを使いこなすためのコツと知っておくと便利なショートカットキーのテクニックを紹介します。
マウスを使用禁止にする
ショートカットキーを使おうという意識が働かないとなかなかマウスから脱却できません。そのためにまずはマウスを使用禁止にします。パソコンの操作はキーボードだけでも操作デキるようになっていますので１週間ほどマウスを使うのを禁止します。若手が私のチームに来たときは、最初はマウス禁止にしていました。
そうするとキーボードでパソコンの操作することができるようになり、多くの場合マウスを使うよりもキーボードで操作するほうが速いということを実感します。
ショートカットキーは探して使うもの
ショートカットキーをたくさん知っていて使えるに越したことはありませんが、すべての機能のショートカットを覚えることができません。では、どうするかというと、ショートカットキーを探して使えるようにしていきます。
方法は３つあります。
① 本やインターネットから探す
ショートカットキーだけをまとめたハンドブック的なものもありますし、何よりもググればすぐに出てきます。ざっとまとめて知りたいときは本の方が便利ですし、特定の機能のときはググっても充分に調べられます。
② 機能のアイコンにカーソルを当てて探す
すべての機能で使える技ではありませんが、機能のアイコンにカーソルを当てるとその機能のショートカットキーが表示されることがあります。
私は普段あまりWordを使わないのですが、書籍の原稿はWordで書いています。あまり使わないWordなのでショートカットキーはあまり知らないので、探しながら使うようにしています。例えば、章・節の区切りに「改ページ」という機能をたくさん使います。:
何度も使う機能なので、マウスで操作するのが非効率なので図のようにマウスをアイコンに当てると「Ctrl + Enter」と表示されます。手っ取り早く調べられるので、ググる前にこの方法で調べるといいです。
③ 人の技を盗む
人と仕事をしていると、時おり自分の知らない奇妙な指の動きをする人がいます。または、自分ならマウスで操作する、というタイミングでキーボードだけで操作することもあります。そんなときは、自分の知らないショートカットを使っているときです。目で見て盗むチャンスですが、指の動きを見てもわからないことも多々ありますので、勇気を出して聞いてみましょう。
Altを使えばなんでもできる
ショートカットキーを知らなくても、調べなくてもショートカットキーを使える技があります。それは「Alt」キーを使うことです。Altキーを使うとほとんどの操作をキーボードでできるようになります。
Altキーを押すと、ソフトウェアのプルダウンメニューがアクティブになります。そしてそのメニューにアルファベットが振らて表示されます。その表示されているアルファベットをキーボードで押すとその機能が使えるようになります。 先ほどの改ページを例にすると、「Alt」→「N」→「B」で改ページの機能となります。
トラブルリカバリ日記－００５ ～プロジェクトのキーパーソンを探そう
トラブルリカバリで最も重要なことのひとつは、「プロジェクトのキーパーソン」を探して見つけることです。
プロジェクトのメンバーを全員入れ替えることはもちろんなく、たいていのケースはほぼそのままのメンバー維持で継続していきます。
そのような中で誰をプロジェクトリカバリの中核にそえるかがポイントです。
これを探るのに３つのアプローチがあります。
【①自分でみつける】
ヒアリングや会話の中から自分でコアメンバーを見つけていきます。 これは、そのつもりでコミュニケーションを取っておかないと見つけられません。
【②プロジェクトメンバーからの評価】
メンバーとのヒアリングや会話を通して、核となるメンバーが浮かび上がってきます。これをピックアップしましょう。
【③お客さんからの評価】
当然、お客さんからの評価もキーとなります。
探り方はふたつあります。ひとつは直接評価をいってくれるケース、これは問題ないでしょう。もうひとつは、お客さんとの会話の中で何度も名前が上がってくる人です。
ただし、お客さんからの評価で気をつけなければいけないポイントがあります。それは、お客さんからみて「便利・都合のいい人」でないか、です。
お客さんの言うことを、「はい、はい」と聞くのが、必ずしもいいとは限らないからです。この見極めは重要かつ、難易度が高いです。
そして、このようなコアメンバーがこれまでなぜ埋もれていたのか、です。
パターンは２つです。
【①仕事の忙殺されすぎていた】
トラブルになればなるほど、コアとなるメンバーに仕事や問い合わせが集中してしまいます。 そして、ボトルネックとなってしまいプロジェクト全体視点でみるとボトルネックになってしまっているのです。
【②リーダーの影に隠れていた】
あまり発言をしない、控えめタイプに多いパターンです。 なので、これまでのリーダーの２番手、３番手にいて、目立たなかったケースです。
これはこれで発掘が難しいケースです。
このように、プロジェクトのキーパーソンを見つけることが重要です。
そして、何のために見つけるのか、それはこの先のリカバリを達成するためです。そのために、この先のコアとなるメンバーを見つけるのです。
トラブルリカバリ日記としてこちらに書きしたためています。
過去の記事はこちらからご参照ください。
デスマーチ 第2版 ソフトウエア開発プロジェクトはなぜ混乱するのか
- 作者: エドワード・ヨードン,松原友夫,山浦恒央
- 出版社/メーカー: 日経BP社
- 発売日: 2006/05/03
- メディア: 単行本
- 購入: 9人 クリック: 355回
- この商品を含むブログ (119件) を見る
- 作者: トム・デマルコ,ティモシー・リスター,伊豆原弓
- 出版社/メーカー: 日経BP社
- 発売日: 2003/12/23
- メディア: 単行本
- 購入: 7人 クリック: 110回
- この商品を含むブログ (149件) を見る
トラブルシューティングから学ぶプロジェクトマネジメントの基本
- 作者: Ryoji Tanaka
- 出版社/メーカー: Ryoji Tanaka
- 発売日: 2013/07/26
- メディア: Kindle版
- この商品を含むブログを見る
時間は誰にでも平等なもの ～速く質の高い仕事が差を生み出す
周りをみると、膨大な仕事をこなし、大きな成果を出してしまう人がいます。
ですが、そんな人たちに人よりもたくさんの時間があるわけではありません。時間は誰にでも等しく１日２４時間、そして３６５日あります。
仕事が「できる人」と「できない人」の時間は同じなのでしょうか。１時間という時間は同じですが、中身は全く違います。
あなたの身近にいる「できる人」を想像してみてください。仕事は多忙なイメージがありますが、どこか余裕を感じます。懐が広く時間に追われていない、といってもいいでしょう。一方で、ずっとポジションが上がらない人は、自分の目の前の仕事に精いっぱいで「忙しい」「時間が足りない」といっています。
毎日毎日、時間に追われて仕事が片付かない人。余裕に見えながらも結果を出している人。何が違うのでしょうか。
【速さがものをいう ～ 仕事量＝速さ×時間】
まず、仕事の速さが差になります。１時間に２０ページの資料を作れるAさん、１０ページしか作れないBさん。１日に７時間資料作成をしたら、７０ページの差になります。１ヶ月、２０営業日では、１４００ページの差が生まれます。これが１年であれば、１６,８００ページもの違いになります。この差は年数とともに開き続けます。仕事は速いに越したことはありません。
速さには、３つの種類があります。
・ 動く速さ
・ 考える速さ
・ 決断する速さ
動く速さとは、実際の手作業であったり、駆けずり回って人に聞きまわる初動の速さだったりがあります。そして、思考自体が速くあること、その結果、決断を速くすることです。考えるのを速くするには、フレームワークを使うフレームワーク思考が最適で、その思考の結果を最短で決断することです。
【仕事の速さは考える時間を生み出すため】
なぜ仕事が速いといいのか、というと。余った時間を「考える」時間に使うことができるからです。仕事が速いからって、余った時間を何にも生かさず飲み会などに費やしてしまったら、「うさぎとカメ」のうさぎさんになってしまいます。早く終わった分、考える時間に使いましょう。
そして、その考える時間こそが大きな差を生む糧となります。
【質を伴うとさらに差が広がる ～ 成果 ＝ 質×速さ×時間】
考えて仕事をすればするほど、仕事の質があがります。質を伴ってこそ意味のある仕事の速さになります。質を、資料の質として考えてみたときに、１日で仕上げてレビューを受けて、ダメ出しをもらってさらに１日を費やす場合。２日で仕上げて、一発でレビューOKとなるケース。どちらも完成までに費やす時間は同じです。これでは意味がありません。 質の高い仕事を速くこなすことでより大きな成果の差を生み出します。普通の人の質を７０％としたときに自分の質は１００％を目指しましょう。
そうすると、さらに３０％大きな成果を生み出すことになります。
【参考】
ビル・ゲイツはたくさん本を読むことで有名です。いまでは第一線を退いていますが、あれほどの企業のトップを勤めていながら本を読む時間を確保していたというのはすごいことだと思います。 むしろ、自分の限られた時間を何に使うかをしっかりと分類し、適切に判断していたのでしょう。しっかりとインプットをする時間を確保すること、こればビル・ゲイツにとってとても重要な投資の時間だったのでしょう。だからこそ、しっかりと読書の時間を撮っていたのだと思います。 ビル・ゲイツだけでなく、ビジネスの世界で有名な人の多くはびっくりするくらい時間の使い方がうまいと思います。 仕事や読書だけでなく、ちゃんとオフの時間をとって有意義な時間を過ごしています。
参考図書
仕事を速くするにもいろいろなスキル・テクニックがあります。我流で追い求めるのではなく、書籍などから学びましょう。参考になった本を紹介します。
なぜ、あなたの仕事は終わらないのか スピードは最強の武器である
- 作者: 中島聡
- 出版社/メーカー: 文響社
- 発売日: 2016/06/01
- メディア: 単行本（ソフトカバー）
- この商品を含むブログ (9件) を見る
- 作者: 岡田充弘
- 出版社/メーカー: かんき出版
- 発売日: 2016/05/18
- メディア: ?
- この商品を含むブログ (3件) を見る
- 作者: 松本利明
- 出版社/メーカー: ダイヤモンド社
- 発売日: 2018/01/18
- メディア: 単行本（ソフトカバー）
- この商品を含むブログ (2件) を見る
SIMPLE RULES 「仕事が速い人」はここまでシンプルに考える (単行本)
- 作者: ドナルドサル,キャスリーンアイゼンハート,Donald Sull,Kathleen M. Eisenhardt,戸塚隆将
- 出版社/メーカー: 三笠書房
- 発売日: 2017/08/21
- メディア: 単行本
- この商品を含むブログを見る
- 作者: 岡田充弘
- 出版社/メーカー: かんき出版
- 発売日: 2017/08/07
- メディア: 単行本（ソフトカバー）
- この商品を含むブログを見る
- 作者: 寺下薫
- 出版社/メーカー: SBクリエイティブ
- 発売日: 2018/09/05
- メディア: 単行本
- この商品を含むブログを見る
- 作者: 岩田松雄
- 出版社/メーカー: サンマーク出版
- 発売日: 2012/10/09
- メディア: 単行本（ソフトカバー）
- 購入: 5人 クリック: 77回
- この商品を含むブログ (16件) を見る
トラブルリカバリ日記－００４ ～現場に入る前にヒアリングシートを作る
トラブルプロジェクトの現状を把握するために、まずはドキュメントを集めて読み込み、そして何が、なぜ悪いのかと仮説を立てよう、ということをこちらの２つの記事で書きました。
さて、次は何をするかというとヒアリングシートを作ります。
ここまでのステップで、どのようなプロジェクトで、何を作っていて、どこに問題がありそうか、根本原因はどこにありそうか、というアタリがついている状況まで来ています。
ここまででも、一定の準備はできていると言えますが、もう一歩準備をすすめます。
ヒアリングシートを作るのです。
仮説を立てたなら、その次のステップは仮説の検証なので、プロジェクトメンバーにヒアリングをしないといけません。 そのヒアリングを効率的に行うためのヒアリングシートです。
誰に何を聞くのか。体制図を見ながら誰が何の担当であるか、なども考えながらヒアリングシートを作っていきます。
このヒアリングシートを作るときに意識をしておきたいことは、ヒアリング項目をカテゴリごとに整理する、ということです。
例えば、QCDであれば、品質（Q）、コスト（C）、スケジュール（D）というカテゴリです。QCDであれば、ざっくりしすぎているのでPMBOKの知識エリアをフレームワークにしたり、プロジェクト体制のチームをフレームワークにしてもいいです。
ポイントは、何かしらのカテゴリで整理するということです。そして、そのカテゴリレベルでMECEにしておくことです。
カテゴリレベルでMECEにしておけば、ヒアリングのときに新しい話がでてきたときに、それが該当するカテゴリに項目を追加していきます。そうすることで、漏れのない仮説検証を進めることができるのです。
もし、ヒアリングシートをつくる、といってExcelでノベタンで質問項目を書き出すようなイメージを持たれたとしたら、カテゴリ分類するワンステップを入れてみてください。
トラブルリカバリ日記としてこちらに書きしたためています。
過去の記事はこちらからご参照ください。
トラブルリカバリ日記－００３ ～現場に入る前に仮説を作る
最初の一歩の現状把握のために、資料などを集めましょう、とこちらの記事で書きました。
では、資料を読み込んだならば、次に何をすべきでしょう。
仮説を作りましょう。
仮説の観点はいくつかあります。
開発する機能がいくつかあるのであれば、 A機能、B機能、C機能、～～～～といったように機能ごとに品質や設計上の課題があるかないか、と考えます。
考えるといっても、適当に考えればよいのではなく、手元に集まった資料から読み解いていきます。
例えば、障害一覧があります。 トラブっている状態ですと、だいたい障害が多く発生している機能があります。
ただ、気をつけないといけないのは、障害数が多いからといって品質が悪いとは限りません。障害が修正されているならば、その時点では品質が確保されている可能性があります。
また、テストケースが少なければ発生障害数は少なくなるので、ケース密度も指標として見たほうがいいです。
これらは定量データからの仮説立てになりますが、実際の障害の中身もサンプリングで見るようにしましょう。その実の障害内容にトラブルとなった要因が転がっていたりします。
また、設計書を見てもわかることもあります。設計として書くべきことが書かれているか、メンテナンスされているか、機能ごとに記載レベル、内容は統一されているか、など。
体制図からも仮説だてをします。例えば、プロジェクト体制に会社組織の論理が持ち込まれていないか。プロジェクトへは会社組織の論理を持ち込んではいけませんが、往々にして持ち込まれるケースがあります。そしてそのような場合は、プロジェクトはうまくいかず、設計されたものは組織間で整合が取れていないケースがあります。
マスタースケジュールからは、どこかにスケジュールの歪みはないか、と見てみます。
プロジェクトのもともとのスケジュールはきれいなスケジュールが書かれているはずです。それがどこかから、進捗が遅れ、スケジュールに無理が生じてしまいます。そのタイミングがどこなのか、そこで歪が発生した原因は何なのだろうか、と考えます。
このように、まずは仮説を立ててからプロジェクト現場の中身に入っていくようにしましょう。現場に入ってからは仮説に対して検証をしていく、ということになります。
そして、仮説は外れているものもあります。外れていたならば、それを早く軌道修正して新しい仮説を立てましょう。いつまでも元の仮説に縛られてしまっては、いいトラブルシュートはできません。
トラブルリカバリ日記としてこちらに書きしたためています。
トラブルリカバリ日記－００２ ～最初の一歩は現状把握から
トラブルリカバリに突っ込まれたら、最初にやるべきことは何でしょう。
それは現状把握です。
まったくもって、何も知らない状況から入るのであれば、
- プロジェクトの要件・開発対象がわかる資料
- プロジェクトのマスタースケジュール
- 体制
- 設計書
等の収集から始めます。プロジェクトの内容がわからなければ何も始まらないので、スタートするにあたり必要な情報です。
そして次は、
- 課題票
- 障害一覧
- 週次報告書
などの資料を集めます。これはプロジェクトの要件・設計が分かっていても現状把握に必要なものです。 何がどうなっていて、どうトラブっているか、かをわかるために必要な情報です。
これらの情報・ドキュメントをできるだけ早く入手し、現場に行く前に読み込んでおきます。
現場に行く前に読み込んでおく、というのがとても重要なポイントです。
ひとたび現場にいってしまうと、メンバーとのコミュニケーションやお客さんとのコミュニケーションに追われることとなり、後手後手に回ってしまいますし、何よりも現状を把握していないとコミュニケーションが成り立ちません。
また、要件・仕様をまったく理解していないとお客様からの信用も得られません。
詳細までは把握・理解していないまでも基本的・概要的には理解し、最低限の専門用語を使いながら会話できるように準備しておきます。
今回の場合は、トラブルリカバリに入ることが決まってから、スケジュール的に実際に現場に入れるまでの日程が５日あったので、まずはドキュメントの送付を依頼し、実際に現場に入るまでの間に資料を読み込んでおきました。
お客様との会話も成り立たせることができたので、あらためて重要だと思いました。
トラブルリカバリ日記としてこちらに書きしたためています。
トラブルリカバリ日記－００１
ちょっとトラブってる案件があるんだけど、人出せないかな、という一言がきっかけでした。
「どういうスキルセットの人が必要ですか？」
と聞いたところ、
「・・・・」
、、、怪しい、、、
「とりあえず、何人でもいいから」
と。怪しい、、、、。
経験上の直感でわかりました。「これはやばい」と。
と、いうことがきっかけでトラブルリカバリに入ることになりました。
トラブルリカバリに入り始めて１週間ちょっとが過ぎてきていて、リカバリをすすめつつあります。
私のこれまでの経験やスキルを駆使してすすめています。
せっかくなので、そのトラブルリカバリーをここにしたためていこうと思いました。
実は、トラブルリカバリーにはセオリーがあります。 ですが、その期間中は忙し過ぎて、なかなか教科書的にまとめられたりしません。
ということで、今回の件を記録していくことで、教科書的にきれいにまとまらないとしても、参考書的になれば、と思います。
今後、リカバリ日記はこちらのカテゴリで書いていきますので、ざっと読みたいときはこちらからどうぞ。
リーダーが前向きでいることがチーム力を高めることになる
後ろ向きな、ネガティブなリーダーのチームはチーム全体もネガティブになり、チーム全体の力が発揮されません。なによりも雰囲気が暗いチームとなってしまいます。
一方で、リーダーが前向きでポジティブなチームは常に明るくチャレンジを続けます。
小さなことと思うかもしれませんが、この差はとても大きな差となります。 チーム人数✕日数という差が生まれ続けます。
難しい、厳しい状況となったときでも、
「絶好のチャレンジのチャンスだね！」
「こんなときこそ楽しんでやろう！」
など、前向きでいることでチームが大きく前に進みます。
逆に
「こんな状況、打開できるわけない」
「こんな仕事やりたくない」
とリーダーがいってはいけません。
自分がそのチームのメンバーになったと想像すればわかるでしょう。
リーダーが前向きでいること、とても重要です。
