ユーザ系でプロダクトマネージャーは活躍できないか

聞きに行きたかったイベントだったが、

  • ボーッとしてたら売り切れだった
  • 大きいハコでトラックが1本=セッションを選べない
  • ずっと座学なのが無理
  • そこそこ忙しくなりそう(実際行ける状況ではなかった)

ので結果的にパスした。

 

togetter.com

 

こうしたカンファレンスに行くなら、必ず何かセッションごとにお土産、つまり、気づきを得たいと思う派である。できれば、ワークショップの方が身体を使って体感できるので好ましい。

この歳になると座学で聴講スタイルは少し、辛い。だいたい、そうだよね、で終わってしまうからである。

ところで、こんなエントリがあった。冒頭から頭に???くらいになったのである。

 

私は日本のユーザー企業でプロダクトマネージャーは活躍できない、と思っています。ユーザー企業というのは「収益基盤はリアル系の事業であり、情シス部門はあっても自前のエンジニアはいない」という会社のことです。

 

www.graat.co.jp

 

まず思い浮かべたことは、『ユーザー企業』とはいわゆる『ユーザ系システム会社』に関連しているのかどうかということである。ちなみに、wkipediaではこう解説されている。

 

ユーザー系情報システム子会社(ユーザーけい じょうほうシステム こがいしゃ)とは、大手企業の情報システム部門や機能を分社化・移転して設立した会社である。システム子会社、情報子会社とも呼ばれる[1]。

引用 ユーザー系 - Wikipedia

 

 ユーザ企業→ユーザ系のシステム会社をもつ企業→ユーザ系システム会社の親会社と。

 

であるとすると、ユーザ企業の業態はいろいろである。わかりやすく言えば、東証1部の業種カテゴリの中でメーカ系システム会社と独立系システム会社を除いたものすべてが当てはまる。

○○系システム会社の分類は、従来からあり、そうそう変わったとは知っていない。もしかしたら、自分だけ世間から取り残されているのかもしれないが、多分、そういうことはないだろう。というか、そう思いたい。

であるとすると、勝手に同音異義語を作られるとびっくりする。

次にWeb企業である。これは、『あーそうですか。あなたの中では』系の話かな、と。

 

世にプロダクトマネジメント事例はありますが、それは「Web企業」つまり「サービスやアプリを事業の根幹とし、エンジニアリングも内製する、イケてる会社」のものが中心です。

 

問題というか、自分の不勉強さを痛感させられた箇所はこちらである。

 

一方で、現状、日本の産業構造の大多数を占める「ユーザー企業」において、プロダクトマネージャー(PdM)の職務を担うことには困難さを伴います。

 

確かに、東証一部の業種カテゴリでは、プロダクトを作っていない会社も存在するかもしれない。従来の運送業はプロダクト開発をしているイメージはない。まあ、アプリを提供している黒い猫の会社もあるので一概には言えない。

そうすると、商品開発をしている会社であれば、プロダクトが存在する。存在すれば、なんと呼ぶかは別としてプロダクトマネージャに相当する役割があるだろう。

#自動車開発であれば主査がプロダクトマネージャと言ってもいいのかもしれない。

何を持って困難というのか理解に苦しむ。

 

「ユーザー企業」でプロダクトマネージャーという立場の方ができているのは、せいぜい開発チームの管理です。本来やるべき、プロダクトの方針決め・事業戦略立案といったことは、別部署の管掌業務だったり、「上の方」で決まってしまったりします。

引用 同上

 

いや、違う。いや、そういうユーザ系システム会社もあるかもしれないが、基本は、ユーザ系システム会社は、ユーザ企業のシステム部門の機能分担である。

ここをわかっていないのではないか。

どういうことかというと、情報システムの企画を親会社のIT企画部門と一緒になってするのである。中期計画を作るとなれば、IT企画部門と何をやるかを検討する。もちろん、年次計画も同じである。

以上の観点からも引用したエントリについては、狭窄した視野でしか物事を見ていないのではないかと思うのだが。

 

 

オレンジティー(茶葉)/Orange Tea

オレンジティー(茶葉)/Orange Tea

 

 

月曜日を嫌いにしない3つの工夫

なんとなく、月曜日を迎える前日の日曜日の夕方、明日から仕事か…とずっしりと重力を感じる人が多いようなのだが、そういう気分の重さを月曜日だけに押し付けるのはどうなのだろうか。

いわゆるサザエさんシンドロームと呼ばれるやつだ。

残念ながら、自分には月曜だからという曜日によって気分の重力を感じることはなかったが、過去にいくつかのプロジェクトにおいては出社すること自体嫌でいやでで仕方がない経験をしてきた。結局、抜けてしまえばどうってことないのであるが…それも喉元過ぎればなんとやらで学習機能はすっぽりと抜けているいたのかもしれない。

かなり雑な書き方をすれば、色々とあった中でやりたいこと実現するために試行錯誤しながらも仕事を続けてきたのは油田を持っていないからである。油田を持っていないのだから仕方がない。

働くのであるが、幸いにして月曜日は嫌いとか一切思ったことがないのは、やりたいことを実現していく中で仕事をちょっと面白くする工夫をしているからである。まあ、その工夫も作為的なというか狙ったものではなく、気づいたらそうしていたという経験知を言語化するとそうだったという後付けの理論である。

その後付けの、ちょっとした工夫は3つある。後付けで考えるとこれから紹介する順番になるのだが、この順序で見つけたり、工夫を始めたのかといば、それは違う。多分に、3つ揃った後、それもある程度経験知が溜まった後、何かが紐づけてくれたのだろう。

学ぶ

 作業をするとき、それが誰かに指示されたとしても、習得できるスキルは自分で設定できる。すでに習得ずみの技術であっても、その作業を進める上での対人関係とか意思伝達などをレベルアップしてスムースにやろうとか、やり取りを少なくするためのコミュニケーションとか、いくらでも学習するスキルを設定できるのである。

ちっちゃなレベル上げであるが、こうしたことはコツコツとやっておくと1年も経てば実は大きな財産になる。油田にはならないが。

楽しむ

先に学ぶをおいたのは、学べるとできることが増えるので嬉しいという感情を得られる。楽しい〜!である。さて誰の声でCVをしたか教えて欲しい。

仕事の内容が酷くても締め切りが鬼でも学びがあると結果的に楽しめる。楽しいとひどい作業でもなんとかやっていける。どうせやらないといけないのであるから、やるなら得るものを得て、楽しんだ方がいい。掛かる自分のリソースも少なく済む。

楽しいがやはり油田の代わりにはならないが。

終わらす

多分、3つの中で一番最初に習得したのは作業を終わらさないと、という意識だったのだろう。これはプロマネだから終わらせてなんぼという価値観を身につけたからかもしれない。

ただ、これを1番にしてまうとあとが続かないのである。楽しくなくても、辛くても終わればいいのかというとそれでは月曜日は嫌いなままである。

作業を淡々と感情を抜きに終わらすのもいいかもしれない。割り切りがあって。でも、それじゃつまらんだろうということである。どうせやるなら、学びがあって、(自分だけ)楽しくやれて、終わりたいものだ。

この3つのステップを踏むだけで心は穏やかに、焦ることもかなり少なく、作業が捗る。

学ぶ、楽しむ、終わらす。日本人的には、おわらす、たのしむ、まなぶで『おたま』とか名付けると自己啓発の本にできそうである。

油田を買えるほど売れればいいが(書く予定はない。オファーは受けます)。

 

 

柳 宗理 レードル (おたま)M 日本製

柳 宗理 レードル (おたま)M 日本製

 

 

 

 

 

役に立たないプロジェクトマネジメント 用語

【課題管理】かだいかんり

本当にやばいプロジェクト課題は記載されないで闇に葬られるもの。

 

【コスト管理】こすとかんり

 顧客の言い値で受注した金額に合わせた実績の記録。

 

【コード】こーど

あちらこちらからコピペされて継ぎ接ぎになっているもの。

 

【仕様】しよう

合意の取られていない空想。

 

【進捗会議】しんちょくかいぎ

 チームのメンバを集め、計画に対し遅れているメンバを吊るし上げる時間。

 

【スケジュール】すけじゅーる

実現する可能性のない、顧客の都合に合わせた工程管理表。 

 

WBS】ダブルビーエス

メンバにWBSを作らせるが、契約の納期や勝手に約束された期日でできるWBSにしてくれと言われるチャート。

 

【テストケース】てすとけーす

様々な理由により、省かれてしまう作業項目。 

 

【パソコン】ぱそこん

生産性<調達コストで支給される開発道具。無くすとめっちゃ怒られる。

 

【80%】はちじゅうぱーせんと

進捗会議で唱えられる呪文。

 

【プロジェクトチーム】ぷろじぇくとちーむ

 見積もりの工数として出したヘッドカウント分のエンジニアの集まり。

 

【品質管理】ひんしつかんり

存在しない概念。

 

【変更管理】へんこうかんり

曖昧な契約により当初のスコープとして押し戻されるため誰も見たことがない管理方法。

 

【要件】ようけん

 システムテストになってから考える検収条件。

 

【レビュー】れびゅー

人数が集まるわりに『てにをは』か見た目しか指摘されない打ち合わせ。

 

このほか思いついたら、ブコメに書いてくださいな。

 

 

舟を編む 上巻 (KCx)

舟を編む 上巻 (KCx)

 

 

計画通りに進められない理由

色々な仕事をやってきたが、どれ一つして同じ内容の仕事はなく、仕事はこう進めたら上手くいくよ、なんて方法はない。

だったら、仕事をしてみないと何をすればいい変わらないのだから、何も準備しなくていいかというと、現実はそれほど甘くないのも事実なのである。

エンジニアが関わる仕事、企画でもプロマネでも一担当のエンジニアでも出来上がっている仕事、手順書通りにやればいい仕事なんて存在しない。手順が決まっている仕事だとしても、手順書に書かれていないことが起きる。まあそれは手順書をそれで良しとしたプロセスの問題ではあるが。

そんなことはない、計画を作って進めているのだから、計画どおりに進めていれば問題は起きないと思っているならそれは思い違いも甚だしい。計画は過去に成功したやり方を参考にしているか、多分これでできるだろうという仮説でしかない。

仮説であるから誰も確証を持てるはずがないのであるが、信じるのである。いや、信じたいのかもしれない。いずれにしろ、やってみなければわからないのである。

実際やってみると、計画どおりにはいかない。計画どおりにいくのであれば、プロジェクトマネジメントで進捗をマネジメントする必要性はない。計画と実績の乖離がないのだから実績をモニタリングする必要はないのである。

それでも毎週か毎日か進捗の実績を報告しているのは、仮説でしかない計画の確からしさを確かめるためである。

で、計画どおりにいかないために対応する必要が出てくる。

多くは計画が杜撰であるか、関連する影響範囲を見誤っているか、である。エンジニアの力量と計画のミスマッチは計画の杜撰に含む。

現実の世界で計画と実績の較差を知るためには、計画と遂行プロセスでモニタリングするための単位は必要な精度で収集しなければならないがそうした考えをしないで始めてしまうため気づける異常をみすみすと見逃すことになる。

この考えを取り入れるだけで計画の遂行はかなりコントロールしやすくなるのであるが、そうしたことを教えてくれる人も研修もないため、エンジニアは繰り返すが誰も気づかないのである。

 

 

 

 

失われるエンジニアとしての読書力

本を買うことも好きだし、読むことも好きである。だからついつい積ん読も増える。積ん読にする本は、自分の興味で買ったり、facebookのお友達の読んでいる本のタイトルに惹かれて手に入れる2パターンがある。

以前は、購入履歴になるのでamazonで買っていたが、紀伊国屋書店で買った履歴を(ポイントカードを登録しておけば)Webで調べられるので店頭で実物をみて買っている。

そういえばすっかり技術書かテーマの都合で参考図書を必要として買う以外、つまり、ラノベとか小説を読む機会が減った。

読書に割く時間も以前に比べて減ったと思うし、何より本を読む読書力が枯渇してしまったのではないかとしか考えられないくらい、本が読めない。

体感をグラフにするとこんな感じである。縦軸は読書力で横軸は年齢である。

f:id:fumisan:20181111091859p:plain

 

『うそ〜!』と思うかもしれないが50代の読書力はマジでこんな体感なのである。年代を上がるたびにガクッと落ちていることに気づく。年代での読書力はじわじわと落ちているがそれには気づかない。で、大台に乗るたびに膝から崩れるような読書力を失っていることに衝撃を受ける。

とはいえそうした状況を受け入れるわけにはいかない。いかないのでどうしているかというと、アウトプット駆動型の読書をサイクリックに挟むことで強制的に読書をさせるを得ない環境を自ら作る。

要は、退路を自分で塞いでいるだけなのであるが。

これでシーズン毎に何冊かを読まなければならず、自然と駆け足読やつまみ読(部分的なつまみ食い読書)ができて、本の消費が増えるという手法である。

こうでもしないと、インプットが枯渇し、古い形式知と目新しくもない経験知だけのゴミのようなおじさんエンジニアになってしまう。それを防止するには無理やり駆動を掛けないとどうしようもないのである。

というわけで今もまた本を読むのである。

 

あ、パターンて面白いね。

 

Fearless Change アジャイルに効く アイデアを組織に広めるための48のパターン

Fearless Change アジャイルに効く アイデアを組織に広めるための48のパターン

 

 

露出が多いエンジニアが外に出て行くわけ

露出といっても肌色成分の話ではない。それを期待していた読者には期待はずれかもしれない。ここで指す露出とは、組織内から組織の外へ、外部のカンファレンスなどにちょこちょこ見かけるエンジニアが講演などに出てくる事象を指す。

そうしたところへ出られた経験をお持ちのエンジニアと会食をする機会があり、色々と相談を受けた話の中で、外に出て行くエンジニアはなぜ外に行くのかという話になった。

カンファレンスで所属する組織名を出す場合、はじめに考えられるのはスポンサ枠である。次には、カンファレンスのテーマに即したその時代のキーパーソンに講演を依頼するパターンである。

前者は、組織の代表として露出することになる。つまり、お仕事。であるから、発表される内容は実質PRになる。スポンサ枠であるからその見返りのようなものだし、そうしたことで参加者に認知力をあげたいという目的を狙う。後者は、主催者側からオファーになるので、講演者は属する組織から出る場合もあるし、個人名出ることもある。

この2つのパターン以外では、カンファレンス自体が公募枠を作り、発表したいエンジニアが公募で申し込むパターンである。発表時の所属を明記するかどうかは発表する内容が業務に関することかプラクティスになるかで分かれるだろう。○○社の誰それとなるかただの誰それにするかに違いというよりは組織内の規程に抵触しない発表内容かどうかの判断によるだろう。

上述のパターンがある(それ以外にあるかもしれない)がいずれにしろ、エンジニアが自分から外に出て行くとき、どうして自分から露出するか、その動機について語ってくれた。

上述の1つ目のパターンは単純な話で、業務の一貫で行われるだけであるから動機も何もない。どちらかといえば、慣れるまでは望まない仕事になることが多く、まさに仕方がない、仕事になるようだ。これが慣れると率先して発表したがるので不思議なものである。

それよりは2番目の後者の方にエンジニアの闇なマインドを感じてしまう。

どういうことかというと、組織内で実現したいことが認めらないことが続くと所属する組織に対する期待が薄れ、その反動で外部で活動する方に走るケースがある。こういった場合、もともと外部のカンファレンスで発表枠を貰えるだけの力量はあるので、講演をしていると次第に別の組織やヘッドハンティングからスカウトや口コミの引き抜きのなかでそのエンジニアがやりたいことができるとなると躊躇することもなく移ってしまう。

実際には、属する組織から出て行くかどうかについては様々な条件を考えた上で映ると話されていたが、やはり、属する組織でやりたいことというよりは、対人関係(特に上司)や評価面での小さなフリクションが実は積年の積み重ねになっていて、雪崩れるきっかけが外部に露出なのだという。

その方の話を聴きながら、実際に移るかどうかは別にして、外界を知っておくことは属する組織の当たり前や無意識に組織に対するフリクションを溜めていたことを知るきっかけになるから、やはり、月160時間全部を組織内で過ごすことはエンジニアが自分の置かれている環境を知る機会をみすみす悪化させているのではないかという話になった。

 

 

あなたのプレゼン誰も聞いてませんよ!―シンプルに伝える魔法のテクニック

あなたのプレゼン誰も聞いてませんよ!―シンプルに伝える魔法のテクニック

 

 

 

エンジニアの兼務

今のところ、IT業界は盛況でエンジニアが足りない状況らしい。確かに、案件の引き合いは多く、始めなければならないのにエンジニアを手当できなく非常に困っているプロジェクトもあると耳に入ってくる。

2020年で一旦踊り場になるのではないかと思うのだが。

そうした状況で見かけたり、聞いたりするのがエンジニアのプロジェクトの兼務である。

大分前に、コアになる適用技術をリードできるアーキテクトを確保することが必須条件のプロジェクトを担当したこととがあった。丁度、同じ頃のタイミングに別のプロジェクトが並行して立ち上がった。不幸なことに同じ適用技術を採用したのであった。

どちらのプロジェクトも必要とするエンジニアは同じ自分になった。

さて、何が起きたか。

当然、エンジニアのリソースの奪い合いになるのである。自分ももう1つのプロジェクトのプロマネも笑顔でリソースの奪い合いを工数の按分、スケジュールのマイルストーンを盾に双方のためにプロジェクト最適化を図ろうとするのである。

もちろん、適用技術を持つエンジニアに対するリソースが合わせて1人月であれば、理屈としては按分でき、互いのプロジェクトは単にスケジュールを調整すればいい。

ただ、現実の世界ではそうはいかない。

そんな机上で考えたようにはいかない。

想定したより技術レベルが高いタスクになった、エンジニアが引いたスケジュールの見積もりが甘かった、などが起きる。

それも必ず起きる。

そうすると先に作業していた方に引っ張られるのである。割りを食うのはスケジュール上、後になっていたプロジェクト側である。何事も占有している方が強い。

では、なぜ複数のプロジェクトにエンジニアを兼務させると上手くいかなくなるのか。

それは、同時に二人必要な要求に対して兼務では問題を解決できないからである。

さらに、副作用として兼務は品質上のトラブルを引き起こすリスクを孕む。兼務のエンジニアはプロジェクトルームを行き来するたびに思考のスイッチを変える必要が出てくる。別のプロジェクトに行っていて戻ってきたら頭を切り替えなければならない。

さらに不在中にもプロジェクトは進んでいるから、スイッチを入れ直してログを追いかけるようとしても把握しきれないのである。

把握に余計な時間を取られるのは、通常、作業見積もりに考慮されていない。把握もしきれないから割り切りで走ってしまい、結果、不具合を引き起こす。

適用技術や難易度の高いコードを任せていると、根幹のところで不良が出るのである。

エンジニアの兼務はリスクである。重々、ご覚悟されたい。