Tuesday, June 15, 2021
 

技術者の手を止めないプロジェクトマネジメントのコツと役割

ここ数年にはなりますが、個人的な環境の変化としてフロントエンド系エンジニア、サーバー側の管理者の方など、技術寄りの方々と一緒にお仕事をする機会が増えております。

しかし一般的なウォータフォールの制作環境に於いて、”下流”に位置づけされやすいエンジニアのポジション。

どことなく軽んじられやすく、上が決めた無理難題をパワーと根性で解決するいわゆる『IT土方』と自虐的な言い回しも聞こえる次第なのですが、プロジェクトマネジメントとして全体を俯瞰で見るうちに、いかにエンジニアの方が苦労されているのか、また、その問題解決の糸口が見えつつあるので、個人的備忘として。

エンジニアが技術を振るえる環境作り

ディレクターないしクライアントからのメールによる作業指示。
漠然とした内容が多く「これやっといて」的なニュアンスで投げといて「後で電話/席まで行って説明すればいいや」とお考えの方も多いかとは思いますが、
そのメール内容を読み解く時間、作業モードのエンジニアの手を止めてる時間のコストを考慮された事はありますでしょうか。

後者の場合、「詳しく説明するからこの時間空けといて」と事前にアポを取り、内容を整理した上でお話されるのならまだしも、エンジニアの席に行くまでのわずか数歩の間に考え、挙句の果てに「あれ何しに来たんだっけ?」と言われも「知らんがな」ってシーン。わりと多く見る機会があります。

言わずもがな、ウォータフォールと聞こえは良くても伝言ゲームの言い回し変えただけみたいなところは、正直あるところではあります。
しかし、伝えるだけでも時間は消費しており、その間の作業時間はロスしていることを考慮し、いかにエンジニアへ端的にかつ整理した内容を伝えるのか。一緒に思案する事項なら何を考えて欲しいのかをオファーする姿勢は持っていたいところです。

コミュニケーションツール運用時の工夫

上記にも軽く挙げましたが、メール/口頭でのやりとりはリスクが大きいもの。できることなら避けるか必要最低限に留めたいところです。
最近は、社内チャットやプロジェクト管理ツールの利用も当然のことになりつつあります。
しかしそれら便利と思われるツールもエンジニアにとっては絶対的な便利さとは言えないようで。注意すべきは通知機能の使いドコロ。

どうしてもアテンション/アラートを伝えたく、些細なことでも@をつけてエンジニアに連絡するケースが多く、都度でエンジニアの意識がそちらに削がれるため「あー、またなんか来てるな。まぁいいや」と本当に緊急度の高い通知などはスルーされてしまう可能性があります。

チャット=即時会話ではなく、あくまで”ログを残しておけるツール”という意識での運用がエンジニアにとっては好ましいようです。@を入れての通知はプロジェクト管理ツールとの併用を念頭に適材適所に留めたいところ。

技術者がプロジェクトマネジメントすることのメリット/デメリット

該当の方の社内ないしプロジェクト内での立場や個人的な性格にもよるかとは思いますが、
チームリーダー的な役割の方がプロジェクトマネジメントを担うケースがあります。
個人的にはツールなどを活用しエンジニアにとって、手を動かしやすい環境が作れれば問題はないのですが、その時に注意したいのは”俯瞰の視点を持てるかどうか”にかかっています。

端的に言うと

  • エンジニア=深く、かつより研磨する視点
  • プロジェクトマネジメント=浅く、他者に説明する視点

の両面を持つ必要があり、プロジェクトが続く中で思考の切り替えだけでも、それなりの労力がかかります。

ことプロジェクトマネジメントに於いては一箇所に留まっての深掘りは他所へのケアに手が回らず、まして自身でコードを書きながらとなると、”自分のコード”、”クライアント対応”、”社内リソース”の3つ+αへ気を配ることになり、効果的とは言い難いです。

しかし、社内のテクニカルな品質管理の底上げという面では、その限りではないですし、スタッフ間の相対的な技術力の差(正確さ、スピード)を、細部の内容を理解した人が把握できるという面ではメリットは大変大きいです。

テクニカルディレクターの必要性と役割については割愛しますが、プロジェクトマネジメントとの住み分けは明確にした上での配置が肝になると言えるでしょう。

プロジェクトマネジメントだからできるエンジニアへのバックアップ

前述の通り、まだまだエンジニアの作業環境の自由度は低く、制作スケジュール的にもエンジニアマターは五月雨開発は当たり前、「量産、流し込みだから」とか「コード書けばいいから」と、軽く思われるなど、理想的な状況には至ってはいないかもしれません。
またエンジニア側からも独自文化と一般との隔たりもまだあり、なかなか理解され難い状況も続いています。

そんな納品の辻褄合わせの犠牲になりがちなエンジニアの方々にとって”理想的な環境とは何なのか”少し考えてみても良いのではないのでしょうか。

  • 技術者が大事にしている事は何なのか
  • 技術者に手を止めさせないために何が必要/不要か
  • 技術者以外のスタッフ間のコミュニケーション効果はどうあるべきか

など。
コードや文法が理解できずともディレクター/プロジェクトマネジメントだから話せる本質の部分もありますし、
エンジニアだからこそ拘っている技術的な美しさ、効率化への理解も重要です。
そのためにお互い少々目を瞑るところはあるかもしれませんが、
その試行錯誤ができるポジションにプロジェクトマネジメントはいるはずなので。

 

メーリングリストを使用する時に気をつけたいコミュニケーション設計の工夫

昨今ではSkype、ChatWork、Slackなど、業務上でチャットを利用したコミュニケーションも当たり前になりつつあります。
が、依然としてML(メーリングリスト)を利用したやりとりが主流という企業も多いことでしょう。

MLが完全悪とまでは言いませんが、そのお手軽感からか工夫や考慮すべき点に蓋をして、そのままになっているケースが多々あるかなと。
中にはMLで上でチャットの様なやりとりをしたり、MLのメールを本文もつけずに、そのまま転送してくる人も見受けられるような。だったら最初からチャットツール使えば良(ゲホゲホ

まぁ、とにかく、どうしてもMLを使いたいという現場の方いることも重々承知な訳で、自分が様々なプロジェクトに携わる中でMLをメインとしたコミュニケーションにおいて気になった点を挙げてみたいと思います。

TOは原則1人にする

よくありがちなのが、TOに何人も関係者のメールアドレスを入れておきつつCCにMLを入れるパターン。
これだとその情報が誰宛なのかパッと見で分かりませんし、受け手側としても「結局、誰に言ってるの?」ということになります。
決裁フロー的にも不明点を誰に聞けば良いのかが不明瞭ですし「誰かが見てるだろう」という意識は結果的に「誰も見てない」事態も招きかねません。
メールでのやりとりをする以上はTOとCCは明確に使い分け、その情報が誰宛のものであるか発信者側で考慮しましょう。

素材共有は事前の整理整頓が肝

また、zipなどの重たい添付ファイルをMLにいる複数人宛てに送付するのも、いささか懸念があります。wifi環境など外で仕事してる方も多いため、セキュリティ上の面からも得策とは言えません。
せめてDropBoxやGoogleDriveなどストレージでディレクトリを整理し、閲覧権限をある程度絞った上で適切な人にだけ適切な形で素材を渡すように心がけましょう。
そのためには日頃からのディレクトリ管理が肝となります。日本語名のzipファイルをルートのフォルダに突っ込んで「あとで整理しよ」とか思ったまま、ほったらかしにしがちの方は、特に注意してください。

起点と経緯と意図の共有

プロジェクトが進行していくうちにタスクが一人歩きをしてしまうことがあります。
「ディレクターからコレやっといてって言われたけど、自分では判断がつかない」という場面ですね。
逆を返せば発注側としては今までの(そのディレクターのみが知ってる)情報で、判断できるだろうという思っているため、こうした齟齬が生まれやすいのだと思います。

これを避ける方法としては、タスクをスタッフに依頼する際にスタッフが判断できる/しやすい情報も付けてあげることを考慮してみてはどうでしょうか。
シンプルなTODOでしたらその限りではないですが、ある程度の工夫や改善をスタッフにお願いした時は、そのタスクの起点、経緯、意図、理由を合わせて依頼をしましょう。
そうすることで受け手側も「これはこうした方が良いかも」と、依頼側の意図に寄せる軸ができます。

クライアントも絡む制作の場合は、あるべき論+クライアント会社内での政治的判断も付加されがちで、それを二次受け的なスタッフに丸投げしておいて、蓋を開けたら「思ってたんと違う」と言われても、スタッフ側からしたら「知らんがな」です。
それを初動で防ぐために、こうした一手間がとても大事になってきます。

この方法のもう一つの利点としては、判断基準を共有して決裁者が分散されることで、個々の判断スピードが上がり、チーム全体での対応力のプラッシュアップが計れるというのがあります。
上の決裁を待つ時間はプロジェクト進行において、ある意味、無駄な時間です。少しでも軽減をするために「このプロジェクト/関連する要素はこうあるべき」というイメージの共有ができるよう、枝のタスクの部分から怠らないようにしましょう。

設計不足は一点集中になるだけ

プロジェクトにおけるコミュニケーション設計の要点は
・受信側の立場を考慮した発信
・チームビルディングを目的とした共有
が大まかなポイントです。

今時のプロジェクト進行は点と点ではなく、点と点をどういった線でつなぐのか、その設計ができるかできないかで、そのプロジェクトの成功率の半分は勝負がつきます。
繰り返しますがMLや電話が絶対悪であるということ言いたい訳ではありません。ただそれらを利用するのなら上記について、発信者側の人達から考慮すべき点だと思うわけです。

善は急がば回れではないですが、ご自身が忙しいと自覚されているディレクターであるなら、なおのこと、こういったコミュニケーション設計をプロジェクト進行前に大切に行うようにしてください。
「でも忙しいから手がつけられない」と言うのであれば、それは「あなたの中で単に優先度が低いだけでしょ?」と個人的には思います。

願わくば、これをご覧のみなさんが、そうでない事を。

 

【捨てる】から始めるプロジェクトマネジメント

明けましておめでとうございます。

今年の冬はあまり寒くなく常秋の国に行きたいカネダとしては、大変過ごしやすい限りですが、
年末年始感が皆無のまま気がついたら年明け、仕事始めとなっておりました。
それはそれで考えもののような。

このままダラッといくのアレなので、旧年の自分の動きをおさらいしつつ、今年の自分の動き方について計を案じてみようかと。

ダーツプロになるためにやった2つのこと

2014年2月頃から趣味でダーツを始めたのですが、なぜか始めた当初から「プロになること」を目標に続けており。

続ける上で気をつけていたのは
・日々の気付きをフィードバックしてPDCAにする仕組み作り
・続けることを目的化すること

フィードバックについては、Evernoteにフォームの部位や、どこでいつ何を目的に投げるかを都度で書きとめ、時間があるときや、なんとなく投げに行こうかなと漫然と考えたときに見返すなどして、自分への留意点のフリークエンシーをあげる仕組みをまず作りました。

細かい気付きなどについてはmixiの日記やつぶやきを利用し、こちらもやはり「あとで振り返る」ことを前提としていました。

ログがあることで投げ始めで「前に投げた時に決めたこと、気づいたことってなんだっけ」と振り返れましたし、スタートがそこからになる。また投げた時の新しい気付きがあればそれをログとして残すという具合。

Gitなどのブランチに似た概念かもしれませんが、徐々に留意点が洗練されてきて、ここが担保できれば、その前のこの動きを気にしなくても良いといった風に、意識の集中を制限できるのも大きい効果だったと思います。

で、この度2015年10月にプロソフトダーツ団体のPERFECTのプロ認定試験に合格。

今年は2月からプロツアーに参加することが可能になったので、スポット参加になるかもしれませんが、このまま続けていければと思っています。
あ、ちなみにWebディレクターは辞めてませんのであしからず。

環境に左右されない原則の確認

旧年は常駐案件をメインに2月〜11月で請け負っていました。

正直、環境自体はメールや電話がメイン。
バックログなどのPMツールもない中での仕事でしたので、それなりにストレスもありましたが、個人的にスプレッドシートに課題管理表を作成し、個々のタスクの進捗を管理していたため、大きい混乱もなく先方に高評価をいただけました。

常々、仕事は「誰が、何を、いつまでに、どうする」を抑え、関係者一同が参照しやすい環境をまず設計することが大事と考えています。環境が変わるとツールも変わりますし、関係者の仕事に関するリテラシーも様々です。
しかし、抑えるべき原則は変わらないという部分に確信が持てたのは、個人的に大きい収穫でした。
絵に描いたような代理店案件でしたし、改めてコミュニケーションツールの重要さを知りましたが、久しぶりにウォーターフォールの典型を垣間見ながら、自分がフリーランスになって得た知恵を少なからず活用できた気がします。

あえて「捨てる」という選択肢

さて2016年ですが個人的なテーマとして「洗練/メリハリ」をテーマにしたいと思います。

質を求めるための量の担保。そのための基礎の設計が去年のテーマになっていたと思います。
今年はそこからの洗練。ある種の取捨選択を強いていければと。

人は何かを捨てる時には、自分で自分に言い訳をしたり、なにかしら妥協のうえで捨てるという行動に陥りがちです。
しかしポジティブな理由ゆえの「捨てる」という考え方も本来あって然るべきです。
自身のプライベート、仕事に関わらず、抑えるポイントを精査した後、可能性や求める結果を吟味した上で不要なものや効果が薄いものをあえて捨てる勇気。
そこから空いたリソースを求める方向へ注力する。

おそらくやることは基本的に去年と変わらないでしょう。
今まで通りログを残し、レビューし、改善に繋げる。その改善時のプラン構築の時に意識的に一手間加えるといったところかと。
「努力」や「頑張る」ではなく、楽しんで工夫を続けていく。そのことを改めて胸に刻みたいと思います。

改めて本年もよろしくお願いいたします。

 

”空気”作りだけで終らない”Fact”を導くMTG手法

自分は主にプロジェクトマネージメントを生業としているのですが、
ひと口にPM(プロジェクトマネージメント)と言っても、
会社やプロジェクト毎で様々な役割の分担があります。

プロジェクトマネージメントを進行管理の面だけでなく、広義に”プロジェクト全体を司る人”と定義付けた場合、
バックログなどでのタスク管理やスタッフへのリマインドのみならず、
いわゆる本来ディレクターが担うコンサルティングの分野においても目を配る必要があります。

前者との違いは、対象が制作スタッフだけでなく、クライアント、つまり外部へ向けての情報共有が主なマターとなるわけです。

情報の共有と感情の共感

プロジェクトにおける情報の共有とは、端的にいうと”Fact(真実)”です。
誰が、何を、いつまでに、どうする
といった事実を基に制作スタッフへ、情報として共有します。

もちろんそれだけではなく、
・そもそもでそのTODOの起点は何(誰)なのか。
・どういった経緯で、そういう結論に至ったのか。
・それを行う意図は何なのか。
といった部分もFactの中に含まれます。

極端なウォータフォール型の請負業だと、この辺りの肉の部分がスッ飛ばされて制作へ落ちてくるため、
デザインフェーズなどで手戻りが多いのは往々にしてよくあることかもしれません。

一方で、コンサルフェーズの場合、タスクに落としこむ手前の段階にあるため、
TODOのためのFactは、前者に比べるとさほどの重要性を持たない事があります。
むしろFactよりHypothesis(仮説)や、クライアントからのヒアリングから
引き出した想いや目的を引き出す事がまず重要となるでしょう。

仮説を事実に変えたときに潜む谷

昨今ではコンサルフェーズにおいて、クライアントとワークショップの場を用いるプロジェクトも
増えてきたことと思います。
実際、最近はPMとして入ったプロジェクトにおいても
リアルタイムドキュメンテーションのファシリテートを行う場面も増えてきました。

リーンキャンパスや、グラフィックファシリテーションなど、
視覚化をする事において仮説や想いの見える化を行うMTGです。
旧態的なヒアリングシートの質問項目からRFPを出してもらって、粛々と進めるプロジェクトと違い、
クライアントとパートナーシップを築きながら、チームビルディングをする手法です。

一見すると、この手法はプロジェクトの体制をクライアントとフラットに築く上で一定の効果はあるのですが、
慣れないと、なかなかどうしてプロジェクトが停滞する場面がよくあります。

それは見える化までは良いのですが「で、誰が、何から始めるの?」が、把握しづらいということです。

当事者意識という名の幻想

ウォータフォール型、アジャイル型などプロジェクトの形態も増えてきていますが、
個人的にアジャイル型は、小さなウォータフォール型の集合体と感じる場面があります。

やはり人間、古来より”誰かが決めて”、それに基づいて、自分のやることを進行するという図式に慣れているからでしょうか。
停滞しているプロジェクトを進める特効薬は「決める人がいないなら、まず決める人を決めてくれ」なのは、
アジャイル型のプロジェクトにおいて見過ごしがちな部分です
(得てして「アジャイルであること」に拘ってしまっている事が多いのが理由かと)。

谷を越える方法としてのリーダーシップ

リーダーは原則1人です。当然ですね。リーダーが何人もいると指示系統が破綻します。
しかし、本質的なリーダーである事と、社内における上司的権限を持っている事は、
必ずしもイコールではありません。

プロジェクトにおいても同じ事です。
「クライアントだから言うことを聞かなくてはいけない」というバイアスから
思考停止してしまっている請負制作は多いと思います。

目を向けるべきは1点『プロジェクト本来の目的』です。
目的を正しく把握していれば、権限を持つ人の指示を仰がずとも、個々で「今何が必要なのか」の判断はできると感じています。
リアルタイムドキュメンテーションやアジャイルでのチームビルディングにおいて、本質的な目的はそこにあります。

”空気作り”やパートナーシップ築きだけでなく、参加者1人1人が「このプロジェクトにおいて、これが正しい」と判断できる基準というFactを共有する事。
そのためのMTGのファシリテートが大事になってきます。

MTGにおけるワークショップ自体をサービス化しているのなら別ですが、
それらからのWBSへの落とし込みにおいては、まだまだ骨が折れるところです。

しかし、プロジェクトの可能性を広げる”Hypothesis”とプロジェクトを前に進める上で大切な”Fact”を、しっかりと見極める目をもつこと。
それが、これからのディレクター/プロジェクトマネージャーにとって、
もっと必要なスキルになってくるのだと思います。

 

改善のプロセス設計は一日して成らず

すっかり新年も節分も明けまして。本年もよろしくお願いいたします。

去年は、色々と自分の中で新しい目標をたてたり、そのための環境構築などに費やした一年でした。
今年は、それらについて一定の成果を望みたいところ。結果はどうあれ、プロセス重視で今まで通りに続けていきたいものです。

去年辺りから個人的にボンヤリと考えていた事の1つに『現状の改善のためのプロセス設計』というのがありまして。
ちょっとそれらについて述べてみたいと思います。

『改善』の第一歩はどこから手をつけるべきか

ある事案について改善をしたいと考えていたとします。(急
会社単位でも良いですし、プロジェクト単位でも良いでしょう。もちろん個人での生活の中でも構いません。改善したい何か(ストレス的な何か)があることってありますよね?
で、それを改善する上で人は方法を考えます。会社単位なら上司や経営者に相談。個人なら問題点を考えて、我慢したり切り詰めたりといったところでしょうか。

ですが、この方法には、少し問題がある気がします。それは、ストレスを改善するために新しいストレスを無意識に生み出しているからです。

『何かのせい』にしていても望む成果は得にくいもの

問題点のある何かしら事柄について、私達はすぐに「その事柄の責任者に何とかしてもらおう」という意識が働きがちです。先の例なら会社では上司、個人なら自分です。

しかし、それだと問題発見の起点が自分であっても行動までのプロセスがトップダウンになるため、実際の行動時での効果の評価を得にくい構造になりがちですし、上司や自分の本能的な部分で、本当にその改善が必要なのかという問題意識が合致していない限り、なかなか思うような成果は得にくいかと思います。

問題点の粒度を最小化することでコストも最小化される

一気に得たい成果や評価を得ようとしても、時間もかかりますし、リソースやコストもかかります。まして自分に決裁権のない範疇で問題点を挙げても「なんかウルサイこと言ってるな』くらいで、取り合ってもらえないことも多いのではないでしょうか。
「正しいことをしたければ、偉くなれ」とは、某刑事ドラマのベテラン刑事のセリフですが、文化や習慣を一気に変えるのは、かなりのパワーが必要です。

ですので、まずはその問題点の元凶を論理的に最小単位まで辿ることをしてみてはどうでしょうか?

膨れ上がった問題点も元を辿れば単一の事柄

問題点の多くは事情や要素が複雑に絡み合っている事が多いです。見えない巨大な何かを前にして尻込みをする前に一つの仮説を基にして、最小粒度まで辿っていくと、思ってたよりその元凶は単純な事が多いです。

問題点の元凶を捉えたら、次は改善策を考えます。どうでしょうか?当初考えていたよりは、ずっと小さいコスト/リソースで解決できるイメージになっていませんでしょうか?
社内的な問題点ならコミュニケーション方法だったり、個人ならお金の使い方とか。思考プロセスを改善したいのなら、望む思考をするための時間や場所を確保するなどですかね。

小さいギアが大きいギアを動かすとき

巨大化した問題点を改善するためには、それ相応のパワーが必要になります。権限やヒト・モノ・カネを使って動かすことも可能かと思いますが、なかなか現場レベル/個人レベルでは一苦労だと思いますし、現場レベルだからこそ改善が必要と声を挙げる機会も多いはず。

ですので、まずは大きいギアを動かすための小さいギアを作ってみましょう。最初は小さいギアから、やがて大きいギアに力が作用して全体が動き出すイメージです。

重要なのは、小さいながらも改善が進んでいることを実感することです。そしてそれを継続する事。仮に大きいギアまで届かなくても、その実感が自分を大きくすると同時に自身にとって大切な財産になるはず。

工夫もせずに無いもの強請りをしていては、本当に改善される事は永久にありません。
そのためのプロセスをどう踏むかの設計をしてこそ、そこから改善は始まるのだと感じます。