ぷろまねさん

グローバルコンサルティング会社でシステム開発・運用保守(アプリ方面)のプロジェクトマネジャーをしています。2014年PMP取得。アジャイル開発などの開発手法、Redmineなどの開発ツールを話題の中心に書いてます。

Slideshareに社内勉強会資料「『仕事の流儀』第1回基本編」を公開

以前「プロマネが声をかけるとき作業を邪魔してませんか? - ぷろまねさん」というのを記事にしたが、この中で言及した通り僕主導で社内、というかプロジェクト内勉強会を開始した。先日ようやく、めでたく第1回の開催をすることが出来、その場に30人超、電話でのバーチャル参加も20人以上と予想以上に参加してくれ大盛況だった。その後実施したアンケートでも概ね好評だったのでやってよかった、と心底思っているところ。

ということで、その第1回資料を公開した。社内の先輩方にレビューは頂いたものの、僕が作成した資料なので僕の名前で公開させていただく。

仕事の流儀 Vol1 基本編_ver1.1_外部公開ver

優れた仕事の条件

前半は「優れた仕事の条件とは?」というのがメインテーマになっている。僕が所属している会社はIT(+経営)コンサルティング会社だけあってバリュー(価値)の有無・大小ということに非常に重きを置いている。すなわち、「優れた仕事の条件」とは僕の会社では「バリューの高い」仕事と同じ意味だと思っている。

このバリューを生み出すのってなんだろう?と僕が僕なりに考えた答えがこの資料に記載した「QCDとスコープのバランス」と「リスクの最小化」である。QCD (Quality, Cost, Delivery) とスコープを重視するというのは以前から頭の中にあったことだけれど、それを「バランス」させるという概念はここ最近アジャイル開発についての知識に触れることで確立されたように思う(例えばアジャイルサムライなどで4つのトレードオフを考えるということが言及されている)。

補足:SQERTモデル

社内資料の引用を使用していたので上記Slideshareに公開した資料からは省いてしまったけれども、このQCDとスコープ、およびリスクという5つの要素をまとめてSQERT (Scope, Quarity, Effort, Risk, Time) モデルという場合もある。

Project Management Model – SQERT | RAPIDBI

僕の会社のプロジェクトマネジメントに関する研修ではこのモデルが紹介されていたのだが、個人的にはこの呼び方は好きではない。今回の資料で説明している通り、QCDとスコープは最適な分量を見極めて4者をバランスさせるべきもので、リスクはそれら4つを考えたときに明確化されるものであり、それは最小化させるべきものである*1

にも関わらず、SQERTモデルではR(リスク)を5つ中4つ目に位置させており、他の4者と同じ立ち位置に置いている。他の4者とリスクは本質的に異なるので、本モデルには熟慮が足りない、と思っている。

コミュニケーションの基礎

この第1回基本編の後の第2回以降は「コミュニケーション」と「文書の書き方」ということをメインテーマにしている。そのためその導入部として「コミュニケーションの基礎」を説明している。

良いコミュニケーションをするにはどうすれば良いかということを説明するに当たり、「受け取り方」「考え方」「伝え方」という3つのプロセスに分けるというやり方を採ってみた。実はこれは僕の会社が作った他の資料から拝借しているフレームワークだったりする。一般化するとIPO (Input, Process, Output)と同じフレームワークな訳だけども、コミュニケーションを説明するのに良い分け方だなと思っている。

特に若手エンジニア向けに行った勉強会ということもあって、主要メッセージは「相手のことを考えてコミュニケーションしよう」ということだ。PMOやプロマネをずっとやってきた僕は、ひたすら人とコミュニケーションすることがほとんどの仕事であるのでいつの間にかまともなコミュニケーションが出来ている(と思っている)のだけれど、エンジニアの場合そういかない場合も多い。相手がシステムに疎かろうとテーブル名やシステム用語で語ったり、相手の理解度を考慮せずに自分の頭の中のフローそのままに喋ったりといったことがどうしても散見される*2。そういった彼らがコミュニケーションで損しないためにはどうすれば良いか、ということを今回まとめてみたつもり。

 

アジャイルサムライ――達人開発者への道

アジャイルサムライ――達人開発者への道

 

  

考える技術・書く技術―問題解決力を伸ばすピラミッド原則

考える技術・書く技術―問題解決力を伸ばすピラミッド原則

 

 

*1:というと誤解がある場合もある。リスクを取らなければ相応の対価を得ることも出来ない、という場合だ。今回の議題の場合はそういった価値創造の場というよりは、もっとオペレーショナルな状況を想定しているため、リスクは最小化すべきものとして語っている。このあたりのリスクとの向き合い方はまた別途議題にしたい。

*2:この辺りが気になってしまうのは、僕自身がそのように喋られても理解できないということもあるのだけれど。