なぜPMがGTDを学ぶ必要があるか
最近プロジェクトマネジメントをする上でも、GTDの基礎が役に立っていると感じる。
GTDとは個人のタスクを管理する上での基礎概念で、詳細は他に委ねる。
ざっくり言うとタスクの「整理」と「処理」を切り分ける手法で、自分が持つ全タスクを外部に預けることで、最終的には完全なストレスフリーになれると謳っている。
PMの仕事は確実に目標が達成されるよう、あらゆる情報からタスクを洗い出して、それをチームに実行させること、とも言える。
そのように考えた時に、個人のタスクを管理できない人にチームのタスクを管理できる訳が無い。
また「チームに実行させること」と言ったが、PM自身は軽微な細かいルーチンワークに忙殺されてはならない。しっかりとSOPを敷いて、他メンバーに任せるか、自分でやるにしてもかなりのレベルで時間を圧縮しないと務まらない。もっと重要な仕事に集中する必要があるのだ。
最近はPMBOKを勉強しているが、GTDと通ずる箇所が多分にある。
GTDでいうタスクの洗い出しはWBSに相当するし、洗い出しが完了していれば、後はレビューしながら監視するだけという考え方も非常に似通っている。
そういう意味では、GTDは自分のみを対象としたセルフタスクマネジメント、PMBOKはチームタスクマネジメントのようにも捉えられる。
実際にはPMBOKで規定されているように、プロジェクトマネジメントはもっと広範囲に渡るもである。
しかし、究極的にはメンバー個々のタスクを定義し遂行させることが役割である。
チームビルディングやモチベーションマネジメント、その他の考え方はその役割を遂行するに必要なスキルという位置付けで、タスクは細分化しなきゃいけないとか、プロジェクトとは有期的なものでタスクの集合体であるとか、そういった基本事項は押さえておかないと話にならない。
GTDの基本を理解したうえで大量のタスクを捌いていけば、自ずとPMとしてしなきゃいけないことは見えてくる。
情報量の多いプロジェクトではいわゆるプロジェクト管理ツールみたいなものを使うことになる訳だが、優れたツールの開発思想にはGTDが組み込まれていることが多い。
そのうえでもGTDの基礎理解は必須であるし、逆にツールを使い倒すことでGTDやPMBOKといった考え方を自身に染み込ませることにもなるのだ。
もう少し順序立てると、
・情報量の多いプロジェクトを網羅的マネジメントをするには、AsanaやJIRAといったプロジェクト管理ツールの活用は必須である
・しかし、「網羅的にプロジェクトマネジメントができているか」を確認するには、全体マップとしてのGTDやPMBOKの基礎概念が必要である
・逆に全体マップとしての基礎概念を持ったうえで活用すると、できていること/いないことが可視化され、より高度なプロジェクトマネジメントを追求できる
ということです。
目の前のタスクをこなすだけから脱却して、全体マップの中で今自分がチームがどういう状況かを冷静に見つめる
その前提として、GTDはチームで仕事をする際にも土台であり基軸となります。
[用語理解] MFAとは
引き続き語句の整理・理解から。
WebでいうMFAとはMulti-Factor Authenticationの略で、日本語では多要素認証と訳される。
ユーザー認証においてアカウントとパスワードに加え、6桁の数字を入力する方法をそう呼ぶということらしい。今はかなり広く使われていますね。
より正確な定義としては、
- ユーザー自身が知っている情報
- ユーザー自身は知らない情報
を掛け算して認証する仕組みを指すらしい。
知らない情報を認証プロセスに入れることにより、アカウント情報やパスワードが盗まれた場合でも本人認証を成立させることができる、といったところだろうか。
別の定義を見ると3つの認証要素のうち2つ以上を使うもの、とあるので
広義では2段階認証と同じような認証で問題無いだろう。
もう少し掘り下げた内容が出てきたら、また書きます。
［用語理解] プロダクト・バックログとは
最近はバックエンド寄りのプロジェクトに関わることが多く、まずあらゆる言葉の概念を掴んでいく必要があり大変です。
本日はプロダクト・バックログについて。
英語でいうところのバックログとは、未完了タスクや解決しなければならない事項を集めたもの、といったイメージ。
これをプロダクトと掛け合わせると、最終アウトプット=ITシステムを構築するための機能要件や優先度を洗い出したもの、といった定義になるのかな?
実際にはExcelで個々の機能とそれに伴う要件を整理し、優先度やその他必要な情報をプロットしていく。
詳細記述書を作成する基となるため、抜け漏れなく洗い出されているかと、階層関係が綺麗に整理されているか、辺りがプロダクト・バックログの必要条件になるのではと思う。
必要条件を超えて良いプロダクト・バックログとは何か?を語るには、上にある概念のスクラムやアジャイルとは何か?考える必要がありそう。
構造的に整理するという意味では、Smartsheetやマインドマップなんかとも相性が良いかもしれない。
用語理解の域を出た知見が溜まってくれば、また書きます。
Webサービスを多用する人にオススメの”Biscuit”
Wえbライフハッカーで紹介されているBiscuitを使っているが、すごく良い。
Stationは試してみたがイマイチ合わず断念。
Biscuitはとにかくシンプルな作りになっていて、たくさんのツールやWebサービスを使う人にはぴったりだと思う。
まず違う点はアプリをグループ分けできること。
これは仕事とプライベートみたいな括りで分けても良いし、職場のPCに入れるなら案件ごとのグループ階層に使うサービスを全てまとめてしまえば、あれこれ探す時間がグッと減る。
私用のPCならブログ書く時に参照するものをまとめたり、メッセンジャー系をまとめたり、暇つぶし系のサイトをまとめたりとか。
登録されているアプリに制限はあるものの、ブラウザで使えるサービスならURLで登録すれば大体いけそう。
グループごと開いたり閉じたりもできるため、コンテキスト毎に分けておけば集中力を維持できると思う。
集中したい時に便利な一括通知オフ機能も。
これでChromeは調べ物する時と、外部リンクとして開く時くらいしか使わなくなった。
大量の固定タブにさようなら。
これはほんとに、あれこれ使う人にはおすすめです。
台風10号は、拍子抜けでした。
【書評】『読みたいことを、書けばいい。』
面白い本を買った。
最近は図書館で借りて乱読する「数」のスタイルが主流だったのだが、この本は見た瞬間手に取ってしまった。
著者は元電通のコピーライター。まんまと掴まされた。電通ほど大きな会社になればいろんな人がいるが、すごい人はかなり凄い。
メッセージは至極シンプルだが、これはWeb上にいる大量の「書く人」を救う本になるのでは無いか。そんな気がしている。
メッセージさながら構成も非常にシンプルで、①なにを②誰に③どう④なぜ書くのか、章ごとに核心を言語化していくという試みを持った本である。
全体を通じて言えることだが、24年間もコピーライターをやっていた方とだけあって、とにかく言葉の扱いを心得ているように感じた。
随筆とは、事象と心象が交わるところに生まれる文章である
これは主にWeb上に書かれる文章の9割、つまり我々が書くものの大半は随筆であるとしたうえで、随筆とはなにかの定義である。
事象、つまり事実や体験と、そこに触れることによって起きる心の揺らぎ、それを言語化したものが随筆であると述べている。
これだけでも書く人の「では私は何を書けば良いのか?」という問いに対する一つのヒントとして十分ではなかろうか。
各章でビシッとはまる言葉を匠に使用し、書き手の心象が強い部分を読者に押し付けてくる。
そんな文章は読むというより聞くに近いコミュニケーションとなり、またあらたな心の揺らぎを起こすのだろう。
そういった小手先ではない、書くという行為の最も奥にある部分を、著者自身が具体化しながら書かれた、そんな本である。
もちろん「価値のある文章を書こう」とか、「伝わりやすい文章を書こう」とか、技術論に傾倒してしまうことはあるだろう。文章に限ったことではなく、あらゆる局面において人は、そういった柱に寄りかかりたくなるものだ。
そんな時に原点回帰できる「書道」を示すような、大変貴重な著作である。
自分が読みたいことを書けば、自分が楽しい
すべての文章は、自分のために書かれるものである
自分にしか書けない文章じゃないと、意味無いからなぁ。
