1月に参加したセミナーで、自分の中でまとめようと思っていましたが全くまとまらず、忘れそうなので備忘録までに。タイトル？は「デザイン勉強会3rd 〜10年後の自分をデザインしよう〜」というものでした。

■デザイン視点でのプロジェクトマネジメント（PM）
・どこにリスクがあって、どうカバーすれば良いか
・必要な成果をバランス良く全部とる（リソース、品質、スケジュール管理など）
・ディレクター＝webディレクターではない理由
webディレクターはその場その場をどうするか考えるが、PMは全てを考える必要がある
・クリエイティブの場合、特にデザインに関しては生産業ではないので、スケジュールの読みが難しい
※デザイナーにはリスクを分散させることを考える必要がある。→作業分担や複数人アサインするなど
・PMは手腕が大事（あるデザイナーとのやりとりの経験など）

経営的に、コストの稼働率を考える場合があるが、上から末端に「○○ぐらいのコストが…」といっても理解しにくい。しっかりと教育していくのが大事である。

★社会全体のほうから、モチベーション向上につながる何かをもっておくのも大事

・PMは一度頭の中でプロジェクトを終わらせている
・複数のプロジェクトが稼働している時に、全て同じペースでやると上手くいかない。ふつうか、まったりか、社運を掛けたものか、などなどでペース配分を工夫する必要がある。

■キャリアパスを見据えたチームマネジメント
・リーダーとメンバーをはっきりさせる（リーダーといってもメンバーの一人である）
・メンバーの職域をチーム内で共有する（職能とは、ライティングとコーディングができますとか。職域とは、個人が何をできるか。）
・職能の理解は、プロジェクト自体の設計や見積もりに役立つ
・職域の理解は、プロジェクトの進行にあたって重要
・スキルマップ（スマップ）を作る
自分たちが持っている、いないスキルを列挙する（自分たちの有するスキルがわかり、足りないこともわかる。把握するために…可視化する。自己分析にもなる。）
・同じタスクでも目的や視点の違いで成果がかわってくる。（コーディング一つとっても、単純に形にするだけか、SEOやアクセシビリティを考えたものなのか）
・プロジェクトを社内だけでやるか、社外も加えるかより、各々がお互いのスキルを把握することが大事である。
・チームのメンバーを固定にしすぎると組織としてリスクが高い。もちろん属人的なモノは仕方がない
（例：人数が100人いる会社のメリットが、50人がダウンしても残りの50人で対応できる点）
・リリース日に予備日を作る場合、PMだけが把握しておく方が良いかもしれない（予め伝えておくと、結局予備日も使ってしまうことが多いため。もちろん予備日は作らないに越したことはない。）
・スマップの申告は他社評価であることが大事→きっかけは自己評価の方がはじめやすい。
※これで給料が左右される（採点されてしまうので）と思う人がいるが、「キミの目標設定の参考にする」など伝え方を考える。

なんだかもりもりですが、このセミナーの前のプロジェクトで、「進捗管理」の部分がなかなか上手くいかなかったので、この辺りからヒントを得て「共有をどうするか」とか「そもそもどう進めるか」などをキックオフの際にがっつり決めてからスタートするようにしました。まだ進行中なので失敗するかもしれませんが変な不安感はないので良い方向には向かっているのかなと思います。