2019年9月に読んだ本3行レビュー
持たない幸福論 働きたくない、家族を作らない、お金に縛られない (幻冬舎文庫)
- 作者: pha
- 出版社/メーカー: 幻冬舎
- 発売日: 2017/08/04
- メディア: 文庫
- この商品を含むブログ (1件) を見る
緩〜く繋がっていろいろ興味あることしながら生きましょうみたいな本
今も楽しいけど、もう一つ自分の幸福だけを考えて突き抜けるにはどうしたらいいのかなーなんてことを考えさせられる
これからもっと働き方も変わってくるので、柔軟に動けるよう準備はしておきたい
ビジネスモデルを説いた本はたくさんあるんだけど、ではそのビジネスモデルをどういう仕事の流れに落とし込めば良いかを説いた本は少ない
働き方改革を推進する経営層から、要件定義を行う上流エンジニアや業務効率化を目指すディレクターまで、幅広い方に読んでほしい良書
従属的な組織に属さない、プロフェッショナルとは何かを説いた本
今の会社員が見るとブラックでワーカホリックすぎるんじゃ、、、と思う内容も含まれるが、コンサルやレベルの高い問題解決が求められる仕事では持っておきたいマインドセットを醸成できるか
9月は3冊だけ
集中して読める本の割合が減っているのは、少しインプットに傾倒しているからかな?
もう少しアウトプットに寄せつつ、量に寄せていきたい
2019年8月に読んだ本3行レビュー
PMBOKを単語から読み解く一冊。単語からといってもランダムに並べられている訳ではなく、PMBOKの標準プロセスに沿って解説されているため試験対策にも。著者のPM論も盛り込まれた良書。
個人的2019年最大の衝撃であり問題作。自分が面白いと思ったものに触れて、そこに生じる心象を書けばいい。本業とするかは置いておいて、全ての書く人に読んでほしい名著。
転職と副業で有名なmotoさん初の著書。ブログやVoicy追ってる人からすると目新しい話は少ないか。個人の市場価値を重要視しており、これからの時代を生きる意味での最適解に近い。サラリーマンしか得られないメリットについては思うところがあるので、また書こうかな。
フロー情報の共有を同時にストック化する最適解
組織内での情報共有は、おそらくYammerが最適解
というのを結構前から思っているのだがまぁ刺さらないし伝わらないのでちょっと整理してみる。そもそも何で組織内での情報共有が必要かとか、そこからどういう形が望ましいのかとか。
面白い情報が入ってくること自体が一つの価値になる
転職が当たり前になってきた現代、単にお金ややりがいだけでは優秀な人材は入ってこないし、また留めることも難しくなってくるんじゃないかと思っている。
そういった時代にじゃあ何があれば人が集まるかを考えると、転職まで見据えたうえで自分が成長できるかとか、その会社にいないと得られないものがどれだけあるか、とかになってくるんじゃないかと思います。
ロケットを作ってますとか、事業自体が圧倒的に珍しく差別化されている場合はそれだけで有益な経験だと言えるんですが、だいたいの企業はそんなに大層なものではなく、類似企業もいっぱいあるわけです。
そうなった場合何が差別化になるかというと、その企業にいる人なんだと思う。どんな人がいて、その人たちから何を盗めるか。
面白い人がいて、コミュニケーションが活発な企業であればなんか有益な時間を過ごせそうな気がするし、働いてみたいなと思う。
業務を超えたコミュニケーションは少ない
で、いざ入ってみると、思った以上に皆忙しかったりする。そりゃそうだ。会社というのは無限に働かせて同じ給料を払っている方が利益になるに決まっている。そういう社風というか風土が染み付くと、業務を超えて何かを起こそうとする人は減ってくる。
それの何がいけないかと言うと、単純に面白くないし疲れてしまう。
苦行を価値にして、それを最大化するにはどうしたら良いか
忙しい仕事や残業が増える仕事とは何かというと、じっくり考える仕事や終わりの見えない膨大な資料作成とかが多い。しかし残業無しで帰る人を見ると、調べものについては詳しい人からポイントを聞き出してアタリを付けて進めたり、資料のテンプレートを作って流用したりしている。
そういったノウハウは、一人で構築するのは難しい。他人の作ったノウハウをタダで使わせてもらって早く帰る。これは会社員にしか無いメリットだ。
もちろん一人でどこまで戦えるか試行錯誤して、結果をあげていくことも面白い。でもそれをもっと拡張して、繰り返し使えるテンプレートを全社的に展開したり、自分だけが持つ知識をオープンにして誰かに感謝されたらもっと楽しくないですかね?
その感謝がまた別の知識としてそのうち帰ってくる。そんな循環が作れれば、強い組織ができるんじゃないかと考えている。
クローズドなコミュニケーションを減らす
そういう価値ある共有・協業は個人レベルでなされていることが多いんだけど、個人のやり取りはその人達が辞めると基本的に消える。
数年とか10年単位で見ると、そのコミュニケーションには何の価値も残らないことになる。減価償却、価値ゼロになるということだ。
そこで考える必要があることは、
- クローズドなコミュニケーションを減らして、オープンな場所でのコミュニケーションを増やすこと
- 一つ一つのコミュニケーションを後から他の誰かが参照しやすい状態で保存すること
- さらにそれを、追加負荷無く行うこと
あたりになると思う。
Yammerが最適解では?
1については別に何でも良くて、Slackでも全社メールでも、Microsoft Teamsでも良い。でも2と3を同時にできる仕組みは提供されていない。
2と3を実現するには何が必要かというと、多階層的な情報へのラベリングだと思う。これは一般的にタグと呼ばれる形で実装されていることが多く、複数付与できるという点でフォルダ分けとは大きく違う。
タグ付けができるコミュニケーションチャネル、かつ大規模な情報量に耐えられるもの、Yammerしか無くね?という話である。
もちろん中小企業とかなら、ScrapboxとかQiitaとかでも似たようなことができるんだとは思う。
小さく遊びの延長的に始めてみる
テキストベースでざっと書いてみたんだけど、本当の価値とか正解が何かというのは形を作らないとあまり見えてこない。特にこのケースの場合、タグの後ろにある膨大な情報をまずは作ってみないと価値は生まれてこないだろう。
それを一人でやっても苦行でしかないので、遊びの延長的に誰かを捕まえてやってみるとしよう。
別に上手くハマらなくても全然OKで、その際には今気付いてる3つの条件がまたアップデートされるだけだ。遊びだから、そのくらい緩くて良いだろう。
似たこと考えてる方、コメントください。
情報の置き場所について
組織に属していると、案件リーダーとして、業界人として、はたまた一社員として、多くの情報が日々入ってくる。
では誰に、どのように、共有するかということを考えるのだが、ここをあまり考えずにやっちゃっている人が多い気がする。
そういった情報フローを考える際のポイントについて。
誰に共有するのか?
まずその情報が、誰にとって価値があるものかを考える。これは大きく分けて3つくらいになると思っていて、それによって次のどのようにが概ね決まってくる。
- 世界:組織間の壁を超えたオープンな世界
- 組織:会社や部署など、クローズドなグループ
- プロジェクト:プロジェクトを完遂するうえで構成される、組織間をまたいだグループ
ここにフローかストックかを掛け算すると、6通りくらいの情報フローが形成される。
フローとストックの違いは下記のようなイメージ。
- フロー情報:即時性が高く、単体での情報資産価値としては持続性が薄いもの
- ストック情報:単体での情報資産価値の持続性が高く、長期的に誰かの役に立つもの
どのように共有するのか?
順番に見ていこう。
まず①の「世界」にフローをかけると、ニュースになる。新聞やテレビ、ネット上に溢れる記事などが当てはまり、どちらかというと速報性の高いものがここに分類される。
①にストックをかけると、Wikipediaや本、ドキュメンタリーのようなメディアがふさわしい。
最近だとQuoraとかQiitaとかが台頭してきていて、今後スピードや情報整理が加速する領域。
②の会社にフローをかけると、全体メールや全社Slackのようなものが想定される。
②にストックをかけると、社内ポータルや社内Wiki、OneNote、Confluenceのようなサービスが存在する。
ここはシステムが貧相だったり、まだまだ重要視されていない領域。
③のプロジェクトにフローをかけたものは、概ね②に等しい。大きく違うのは、より実直的にフロー情報自体の量が多いことだ。
ここで生まれる有益な情報を、②にも還元していく必要がある。
③のストックについてはOneNoteやConfluenceが有力だが、どちらかというとまだまだ重要視されているプロジェクトは少ないといえる。
これらによって概ね情報の置き場所は決まってくる。
では組織内のフロー情報はYammer使えば同時にストック化もできるよねとか、
プロジェクト内の普段のコミュニケーションを整理すればそのプロセス自体が後から参照できるフロー情報になるよねとかそういう話になってくるんですが、それはまた個別で別途。
ジェッ
PMBOKにおける変更プロセス:どうすれば要求は速やかに達成されるか?
特に日本でプロジェクトマネジメントというと、進行管理とかディレクションと同列に語られることが多い。(実際見積もり項目としても定義が曖昧なことが多い)
それらはプロジェクトマネジメントの中の個々のワークフローであったり、定義された個々のワークフローを進める仕事でしかない。
PMBOKはもう一つ上の概念で、プロジェクトの開始〜終了までの全プロセスが言語で定義されている。分かりやすいのは変更管理の項目。
特にWebの世界はなんか簡単に変えられそうだからしばしばプロジェクト途中での要件変更が発生するんですが、PMBOKでは変更の際のプロセスについても定義されている。
- 変更要求受付
- 検討
- 承認
- 実施
- 確認
そうなのだ。本来は要求(=依頼)がきたら検討して承認されて、はじめて実施できるものなのだ。それが実際には要求⇨実施へと飛んでしまう(間のプロセスはそもそも計算されていない)ことが多い。
全てに1営業日かかると換算しても、正しくプロセスを遂行すると変更依頼〜完了まで、短くても1週間くらいはどうしたってかかるのだ。
もう一点大事なポイントを付け加えておくと、変更要求の精度が高いほどこの時間は縮められる。検討段階での確認やり取りが減るからだ。
そこから導き出される、依頼する際のポイントは、どのように伝えれば素早く5W1Hを定義できるかということ。
変更ではない初期提案やプランニング業務の場合は違ってくるが、実施確定済みプロジェクトに対して変更を行う場合は、5W1Hに基づいてコストを算出し、追加プロジェクトとして承認され、はじめて動き出す。
そのため、まずはじめの段階で5W1Hの枠組みをどこまで書けるかがそのスピード感を左右する。
- When いつ達成するのか?
これはまず依頼側が理想を伝えたうえで、受託側が現実に落とすもの
- Where どこで実施するのか?
Webサイト上なのか外部なのか
Whyから導き出される部分なので、主に受託側がリードして考える領域か
- Who 誰が実施するのか?
Webでいうと、ドメイン管理者が違う場合商流含め変わってくる。それに応じてワークフローやスケジュールも変わってくる。これも見えているなら明確に伝えておいた方が速い。
- Why なぜ変更するのか?
これは依頼側が主に考える事項であると思う。
それを基に、受託側でも懐疑的に見たうえでなぜが正しいか、精査する必要がある。
- How どのように実現するのか?
ここが受託側が最も力を発揮できる部分である。逆にいうと、5Wがしっかり定義されてはじめてここが見えてくる。5Wが曖昧な場合ここの手法が無限通りでき、膨大な提案資料が出来上がり迷走することになる。
このように、5W1Hのうちほとんどは依頼主側の意向、特にWhyによって決まることが多い。
そのため、まずなぜそれをしたいのかを正確に伝え、その上で方法論を議論していく必要があるのだ。
ちなみに5W1Hは使い古された手法だが、未だにあらゆるものの整理に役立てることができる。この辺りの整理法はまたそのうち。