「プロダクトマネジメント」を含む日記 RSS

はてなキーワード: プロダクトマネジメントとは

2018-09-29

anond:20180929074243

フェイスブックFacebook)は28日、ハッカーによるアカウント乗っ取り可能にするセキュリティー上の欠陥を発見したと発表した。影響を受けたアカウントは5000万件に上るという。

 発表によると、同社に対するサイバー攻撃により、アカウントへのアクセス可能にする「アクセストークン」と呼ばれるデジタル認証情報流出したことが今週に発覚。同社のガイローゼンGuy Rosen)副社長プロダクトマネジメント担当)はブログ投稿で「攻撃者らがフェイスブックコード脆弱(ぜいじゃく)性を悪用したことは明らかだ」とした

2014-08-02

戦う気力をなくした

普通の人からすると大したことじゃないと思うけど、もう会社の中に貢献しようと思う気が失せたので、その実態を書いておく。

ソフトウェアを自社開発していて、顧客自身Webアプリケーションを作れるようなマルチテナントサービス提供しています

直属の部長

上下関係にとにかく弱い

後述する彼の上司であるCTOの言いなり。

全てをイエスで返していくからCTOには都合がいいみたい。

とある機能設計CTOが「コレ出来るよね?」ってすごい適当な図((丸と線をつないだだけ))を書いて説明してて、

別の部署の部下がちゃんと理由((CTOには言葉意味すらわかってなかったらしい))を説明して何度も断ってたのに、

無関係なうちの部長が呼び出されて「出来るよね?」って詰め寄られて「簡単にできますよ」ってさらっと援護してた。

自身はその機能に関して別に作業も具体的な設計をするわけでもないので、頭を悩ませるのは援護射撃をもらった担当開発者たち。

社歴が長い分既存製品に関する知識があり度々オブザーバーとして呼ばれるが、今はその製品を開発している部署所属しているわけでもなく、

最近方向性技術動向に関しては全然理解していないにも関わらず。

普段は雑談しながら笑ってることも多くて人柄は悪く無いと思ってるけど、仕事に関しては全部CTOの発言を決定事項として下ろしてくる。

自分が板挟みになりそうなら部下を責める。あなた意図はどこ?

前例主義

思考停止と思えるほどに「今までもこうやって来たんだし」がバンバンから出てくる。

それを変えるやり方や新しい概念の導入に戸惑うとイライラして険しい顔でとにかく前例に合わせるようにする。

そうやって前例にこだわってきたからなのか、ちょっとしたエピソードがある。

たった4人の小さい部署から毎週のMTGの余った時間で持ち回りの勉強会を提案して実施してたけど、

彼以外の3人がミドルウェアフレームワークや新製品の説明をしているのに対し、彼は割とすぐネタが無くなったのか既存製品の話とか会社規則に関する話が出てくるようになって、

最終的に「忙しいから」というよくわからない理由で勉強会が消えた。

3人共「楽しかったのになぁ」って口を揃えたんだけどね。

製品開発

部長がいる僕の部署は新製品と銘打って開発を進めてるけど、例によってCTOの発言によって既に現行製品をなぞる方向でただの焼き直しを進める形になっている。

僕とサシで話した時は「現行製品と同じ機能を作っていくんだったら新製品を作る意味ってなんだろうねぇ(´Д`)ハァ…」とか言ってたくせにCTOの前ではハハハと笑っている。

以前指摘したけど、彼は新製品に関するプロダクトマネジメントステークホルダー立場ではなく、あくま開発者らしい。

じゃあ誰が責任者ステークホルダーなんだよと思ったけど、そんなもの既存製品にもいなかった。

おかげさまで「あの時はこんな事情があって…」ばかりで迷走しまくってるんだけど、そういう反省は生かさないんだな。

CTO

CTO(最高技術責任者)とは名ばかりの役員

CTO技術

基本的技術に疎い。もともと企画をやってた人らしいけど、アイデアマン((その場の勝手な思いつきは多い))ではないなぁ。

バズワードは大好きだけど肝心の内容は何も知らないし間違いを指摘しても「そんな解釈もあるよね」ってごまかす。

でもそれでCTOっぽく技術リードしていると思っているらしい。

その他にもいろいろ。「ifとforが使えれば何でもできるだろ」だの暴言も多い。

社長は彼がCTOとして問題があることに気づいているらしいが、役員だしなぁ。

来期は彼を開発部署の上から外してくれるといいな。でもその頃には僕はいない。

CTO案件相談と業績

目の前の利益にはすぐ食いつく。

「こんな案件の依頼が来ていてお金はいいんですが、確実に専用のカスタマイズ必要なんですが…」というのに開発陣にヒアリングなしに受注を確定させる。

サーバだってもともと予算はないけどサクッと購入する。開発者たちにサーバを買う予算はないって渋りまくってるのに。

うまく行けば自分の実績として社内で大々的にアピールしまくるが、火消しに走るときは営業に文句行ったり開発者に文句行ったり。

そして保守のことは全然考えてないので、積み残されたカスタマイズサービス群が開発者運用者、更には顧客への次の担当者を苦しめる。

現行製品仕様を切り替えた時にカスタマイズ問題が起こったおかげで製品仕様カスタマイズ考慮したあれやこれやを要求されてがんじがらめ。

ええっと、マルチテナントって一体なんだろう。

ちなみに、コレよりひどい自称SIerの営業が居るが、とにかくカスタマイズ案件を取って受注しておいてPMをしないもんだから

突然「お客さんが明日欲しいっていうんだけど」って焦って飛んでくる事態を連発する。

もちろんそんなことを連発してても「大型案件」を受注するから営業成績はMVPとりまくり。そこからずっと続く保守運用は彼の仕事じゃないしね。

CTOと新製品

CTOの話に戻ると、僕らが作っている新製品(?)に関してもとにかく自分理解範囲内に収めるべく発言しまくるし、

新しい概念を持ちだされて意味がわからない時は「それって現行製品のコレはできるの?」で畳み掛けてくる。

もちろんそれを聞いた部長は「そうですよね。それも必要ですよね!」って援護してきて考えてきた設計がことごとく旧製品になっていく。

どうやらCTOの中では既存ユーザが内容を移行できる新製品にする予定で、機能まで全て踏襲するらしい。

そんなもん誰が使うんだろうねぇ。

「新製品を世に出していくには実案件で実績を作っていかなければ」って話をして、案件を持ってきた。

最初は短期間で終了する案件だったけど、運用期限の決まっていない案件が発生している。

そのために製品名もリリース時期も何も決めてないけど、メインから分離した保守ブランチができ、APIv1は提供済みだから今後はv2にならざるを得なくなり、

それすら新しい案件で潰されていくことだろう。

当初は「お客さんにはあくま実験的なものと説明し、お金は取らない」((そんな話を受けるお客さんはたぶんいないって指摘したけど聞いてくれない))とか言ってたのに、

今は「売り上げあげなきゃこれまでの開発費がリカバリできない」とか言ってる。

現行製品の話

まともなデバッグシステムエディタを使わず果たしてユーザPHPコードを書いて開発をするだろうか?もちろん、否。

お客さんから依頼を受けたら営業担当者四苦八苦しながら開発代行を行い納品する。

それでも難しい場合パートナー企業に依頼をして開発をしてもらい、納品する。

あれ?うちって受託開発会社だっけ?

そもそもPHP以外の機能自体も複雑になってて、開発者自身が「ここに機能追加しろって言われたけど、そもそもこの機能どうやって使えばいいの?」と迷うレベルだし、

想定してた使い方を超えてバグを付く動きを相談なしでお客さんに提供しちゃってるもんだから

どれが正しい仕様なのかすら不明瞭になっている。

現行製品の開発の話

Javaってオブジェクト指向プログラミングが出来るはずの言語なんだけど、オブジェクトなにそれ美味しいの?って状態。

クラスがただの関数置き場になっててメンバー変数をいじるもんだから副作用のせいで同じオブジェクトを使う処理がことごとく影響を受ける。

それを避けるにはどうするか?もちろん似たような機能を持つ別オブジェクトを作ったり、別関数で違うメンバーを使うようにしたりする。

とにかく既存の流れを邪魔しないように新しいコードを作ればいい。おっと既存機能と同じ処理をする部分があるな。コピペコピペっと。

もうリファクタをしようと思う開発者はいないし、単体テストもないからできない。いや、無いんじゃなくて単体テストを作れない。

あちこちにDBコネクションとか埋め込んであって都度データ取得するからさなコードでも動作するにはDBコネクションが必要なんだ。

僕は新卒メンバーには「会社内の書き方は(どの会社でもそうだけど、ここは特に)独自のやり方だから、コレが正しいと思わないように。

今後も開発者であるためにはxUnitとかバグの少ないコードの書き方とか自分自身勉強するんだよ。」と言っておいた。

どの部署保守的

Conwayの法則とはよく言ったもので、まさしくリファクタできない密結合で暗黙のパラメータの多い組織。

自分部署立場を守る発言は多いけど、1年後2年後3年後どんなふうに仕事を進めていきたいからみんなでこうしていきましょう、って意思決定していくことは無い。

未来像を描いて推し進めようとする人とよく飲みに行くけど、その人もCTOからとにかく押さえつけられてたりする。

製品の結合度や他社サービスとの連携を図っていく基盤となる部分を提案しているのに、内容も全然理解してなくて「話が大きすぎて工数かかりすぎ」と言われ、

役員会でCTO勝手に「仕様検討にかかった時間負債になった」と報告したらしい。

僕の話

「なにより、こんなことで諦める俺が憎い!」じゃないけど、そんな中途半端に辞めようと思う僕も駄目なやつだとは思う。

誰にも頼まれないまま開発インフラを変える動きを有志で立ち上げて色々やってCI((例によってユニットテストできない))が回るようになり始めたけど、それも中途半端

運用インフラを変える部分もやっと使える状態になったけど、まだまだ中途半端

製品の1モジュールもきっと中途半端になるだろう。

そういった点は大変に申し訳ない。

でも、今のまま居たって僕に未来はない。

僕は僕自身未来の為に活動していかなきゃと思った。

こんなところでこんなグチグチ言ってちゃダメなんだ。

から、ゴメン!

2009-04-03

アイディア技術だけは何も完成しない

http://anond.hatelabo.jp/20090403015444

アイディアマンと技術者が何もできずに焦燥しているようだ。

複数の人間が協力してクリエイティビティを発揮して何かを完成させるということについて、彼ら二人はあまりよく理解していないようだ。

仮に優れたアイディアと優れた技術があってもそれだけでは何も生まれない、必ず二つの視点が必要である。

プロダクトマネジメント

画期的エンジンをもった新しい車であっても、タイヤは必ず必要である。たとえそれが凡庸なタイヤだとしても。

アイディアを実現可能な要素に分解し、また構成し直す、設計図、青写真を作る必要がある。技術アイディアの間の大きな溝を埋める作業である。

このプロセスにおいて、アイディアは常に、技術的な裏付けがあり実現可能であるかを問いただされ、技術プロダクト全体としての目的を達成するものかが問いただされる。

プロジェクトマネジメント

設計図、青写真を、やるべきことに分割し、時間人間に割り当てる作業である。

しかるべき能力を持つ人間を連れてくる。道具、空間を用意する。

各人の個性を理解し、人が心地よく協力し合う空気作りをする、進捗を見張り時にはムチを振るう、といった事も含まれる場合がある。




はっきりいって優れたアイディアも、優れた技術も、優れたプロダクトマネジメントプロジェクトマネジメントの前においては従属要素である。

もし、君たち二人のどちらもこれら2つのマネジメント能力に目覚めないか、兼任するだけの余裕がないのであれば、それが出来る人間を連れてくるしか、事態を解決する方法はない。あるいは、兼任できる規模のものを目指すべきであろう。

やっかいなのは、これら2つともに教科書どおりにいくものでもないので、これまで結果を出したことがあるかどうかでしか能力の評価が出来ないところだ。



あえて言うとさらに3つめがある。

プロデュース

このプロジェクト全体の投資管理する。しかるべき人材に対価をはらい、成果物から対価を得る算段を企てる。

 
アーカイブ ヘルプ
ログイン ユーザー登録
ようこそ ゲスト さん