#codezine

[tak4hir0]

パーソルキャリア、「保存版ハンドブック スキル年収マップ ITエンジニア編」を公開

　「保存版ハンドブック スキル年収マップ ITエンジニア編」によれば、平均年収の1位は「ITコンサルタント」（752万円）で、2位は「セキュリティエンジニア」（675万円）、3位は「プリセールス」（670万円）となっている。 　職種×スキルで平均年収をみると、「ITコンサルタント」×「グリッドコンピューティング」（1066万円）がもっとも高い組み合わせとなっており、「セキュリティエンジニア」×「ラインマネジメント」（863万円）、「社内情報システム（社内SE）」×「IFRS」（841万円）がそれに続いた。 　開発言語別の平均年収ランキングでは、1位が「ABAP」（661万円）、2位が「R」（656万円）、3位が「Perl」（630万円）となっている。また、「Go」（627万円）が7位にランクインした。 　ITエンジニアが学びたい（強化したい）プログラミング言語ランキングの1位は「Python」（平均年収ランキング16位）、2位は「Java」（平均年収ランキング18位）、3位は「JavaScript」（平均年収ランキング31位）となっており、学びたい言語と年収の高い言語の順位に乖離が生じている。

[tak4hir0]

そもそも、プロダクトマネージャーが成功させるべき「プロダクト」とは何か？

「プロダクト」とは？ 　プロダクトマネージャーはプロダクトの成功に責任を持つ人であるが、改めてプロダクトとは何か考えてみよう。 　本連載ではプロダクトを「市場において顧客となりうる個人や団体に価値を提供するもの」と定義する。ITを活用したプロダクトを主に取り上げているが、これにはパソコンやスマートフォンのようなハードウェアやOSやブラウザ、さらにはクラウド技術やそれらを活用するECサイトなどのソフトウェアが該当するということは前回触れた。 　これらのプロダクトはいくつかの機能に分割されたり、複数プロダクト群を持ったりすることもある。プロダクトを部品として活用するような上位プロダクトが存在することもある。これらを図にすると次のようになる。 プロダクトの例　プロダクトはいくつかの機能により構成されることが多い。また、複数のプロダクトによりプロダクト群が構成されることもある。 　具体例としてSNSサービスを取り上げて見ると、下図に示すような関係になる。 　SNSサービスの中には、文章や写真を投稿する機能もあれば、友だちの投稿を閲覧する機能、投稿に「いいね」でリアクションをする機能などがある。また、SNSのタイムラインとは独立して、SNS上でつながっている友だちと個別にメッセージのやり取りをする機能もある。この場合、SNSとしてのプロダクトと、メッセンジャーとしてのプロダクトを分割することもある。そして、SNSプロダクトとメッセンジャープロダクトは同じプロダクト群に所属する関係になる。 　このようにプロダクトは複数の機能や個別のプロダクトが連携して動作することが多い。プロダクトマネージャーの役割で説明したように、プロダクトはこれらのどの粒度のものも該当する。粒度によって求められる要件は異なり、またプロダクトマネージャーの役割も異なる。 　一方でソフトウェアの割合の小さいものや人間のオペレーションが中心となるものであっても、プロダクトと考えることができる。 　例えば、シェアリングサービスの代表例ともなる「Uber」などのライドシェアは、国や地域によっては純粋なライドシェアではなく、タクシー配車サービスの形で提供されることもある。タクシー配車は以前から存在していた業務であり、電話でタクシーの配車を依頼するというようなオペレーションで実現されていた。 　このタクシー配車をスマホアプリの形で自動化する点で一つの進化系であるが、そこまでの進化を遂げなかった場合でも、タクシー利用者の課題を理解し、それを解消するオペレーションにしようとする取り組みはプロダクトマネジメントの一環であると考えられる。人手を介したオペレーション部分を残したとしても、依頼電話が多いピークのシーズンや依頼内容を分析することで、顧客の課題解決は可能であろう。タクシー配車をプロダクトとして見た場合、スマホアプリの提供とは手段であり、プロダクト改善にITを使うだけがすべてではない。 　このタクシー配車に関しては、多くの国でUberやそれに類するサービスが普及していることを考えると、需要予測やオペレーションスピードの向上などにおいてIT活用は最終的には必須であろうと思われるが、それでもタクシー利用者の体験としての最も重要な乗車体験は、自動運転が一般に普及するまでは、運転手という人間によるオペレーションに頼らざるを得ない。 　このように人間のオペレーションの割合が高いものであったとしても、その部分を含めてプロダクトマネジメントの手法を生かすことが可能であるし、必須だとも言えよう。

[tak4hir0]

Facebook、Pythonコードのセキュリティ問題解析ツール「Pysa」をオープンソースで公開

　Pysaは「Python Static Analyzer」の頭文字を取ったもので、PythonのタイプチェッカーであるPyre上に構築されている。同社内では、Pythonのコードが、技術的なプライバシーポリシーに基づいてユーザーデータへのアクセスや開示を防ぐように設計された内部フレームワークを適切に使用しているかを確認したり、XSSやSQLインジェクションといった、一般的なWebアプリにおけるセキュリティ問題を検出したりするのに用いられる。 　とりわけ、Instagramのサーバーを強化するためのコードベースのスケーリング支援に使用されており、手動なら数週間～数か月はかかるようなコード変更の際のコードベース品質とセキュリティの確認を、約1時間で実行できる。 　同社は、Pythonでの開発においてDjangoやTornadoといったオープンソースのPythonサーバーフレームワークを使用していることもあり、PysaはDjangoやTornadoを用いたプロジェクトにおける、セキュリティ上の問題の検出に最初から対応している。未対応のフレームワークでPysaを使用する場合も、わずかな変更で対応が可能になるという。 　なお、PysaはFacebookの静的解析ツール「Zoncolan」と同じアルゴリズムを採用しており、一部のコードは「Zoncolan」と共有している。

[tak4hir0]

ProductZine、プロダクト開発を学べるオンラインイベント開催、登壇者に市谷聡啓ら

※本イベントは定員に達したため、申し込みを締め切りました。たくさんのご参加ありがとうございます。 　テーマは「プロダクトマネジメントを学ぶ夏」。Q&Aの時間を設け、参加者と「プロダクトマネジメント」にまつわる課題と知見を共有する場を目指す。 　開催趣旨は以下の通り。 今プロダクト開発に興味を持っている方も、すでに深く自社プロダクトに向き合っているPMや開発者、デザイナーの方もプロダクト開発を学び直してみませんか？ 将来の見通しを立てにくい不確実な世の中で、ユーザーに最大の価値を届けるために、仮説検証しながらプロダクトを作り上げていく、それが「プロダクトマネジメント」です。 どんな局面にあっても必要なのは学び、それを実践に変えていくこと。プロダクトマネジメントの第一人者たちから「プロダクト開発」とは何か？ 現場で知っておかなければならないことは何か？ を学び、課題を共有し、よりよいプロダクト開発へ一歩踏み出せる場として、本イベントを開催します。 開催概要 日時：2020年8月9日（日）13時～15時 会場：オンライン開催（Zoom） 参加費：無料 参加対象：プロダクトマネジメントを学びたい人、プロダクトマネージャーおよびそれを目指す人 定員：400名（先着順） 申し込み方法：申し込みフォームより記入 登壇者 及川卓也氏、曽根原春樹氏、小城久美子氏（連載「プロダクトマネジメントの基本」執筆陣） ProductZine チーフキュレーター 市谷聡啓氏

[tak4hir0]

プロダクトを成功させるチーム構築のためにPMがすべきこととは？

プロダクトチームのあり方とプロダクトマネージャーの役割 　さて、この連載ではプロダクトマネージャーが担うべき役割の範囲は幅広く、プロダクトのライフサイクルによって別の振る舞いをしなければいけないとも書いてきた。もしかすると、これからプロダクトマネージャーに挑戦する読者の中には、学ぶべき領域があまりに多く、「自分には難しいのではないか？」と思われてしまった方もいるかもしれない。 　しかし、心配することはない。CEOがすべての要素には精通していないのと同じように、プロダクトマネージャーも、チームで要素を分担すればよいのである。プロダクトマネージャーがすべてを一人で背負い込むのではない。そして、プロダクトマネージャーにはそのチームをまとめ、リードすることが求められている。 　このチームのことを「プロダクトチーム」と呼ぶ。プロダクトチームにはプロダクトを作り上げるために必要な役割がすべてそろっている。例えば、ソフトウェア（IT）を主体とするプロダクトの場合には、（ソフトウェア）エンジニアやデザイナー、QA担当者などが中心となるが、マーケティングや広報、サポートなど、複数の組織からのメンバーにより構成される。 　そして、チームで開発を行うことはとても難しい。また、プロダクトマネージャーは一般的には人事権を持たないとされているためプロダクトチームのメンバーを選ぶことができないだろう。プロダクトマネージャーは、プロダクトの成功のためにどう振る舞うべきかを考えなければならないため、特に次の3点を意識する必要がある。 ビジョンを達成する「プロダクトの強い軸」を明確にすること 誰が何に責任を持つのか、役割を整理して可視化すること マイルストーンを可視化すること 　1つ目の「プロダクトの強い軸」はこの連載の第6回でも紹介したものだ。詳しくは第6回を再度お読みいただきたいが、このCore、Input、Outputのどれかだけでなく、すべてをチームに共有し、議論のベースとすることで、メンバー全員の意識が統一され、進む方向が定まる。プロダクトチームはプロダクトの成功のために組織化されたものなので、このプロダクトの強い軸はプロダクトチームにとっても軸となるものだ。 　2つ目の責任範囲の明確化について紹介しよう。チームメンバーの役割や責任範囲を明確にするには、社内であっても各職能のJob Description（職務記述書）を明確にするのが望ましい。もし、その職能の担当者を新しく採用する場合にはどのような採用要件で募集をするのかを記載することで、期待される役割の認識をそろえることができる。各メンバーがどのような職能を持ち、それを生かし、どのような役割を全うすることになっているのかをJob Descriptionは語っているはずだ。 　会社によっては全社員がジェネラリストとして特定の職種を志向していないこともあるかもしれないが、その場合にはその社員に求めるJob Descriptionとは別に、お互いの役割を明確化する目的で、担当職務のJob Descriptionを作成しよう。ジェネラリストとして採用されていても、そのチームにおいて期待される専門はあるはずだ。それをまずは明確にすることで、お互いの役割を可視化することができる。 　さらに、メンバーの責任分担を明確にするために、RACIという手法が存在する。これは、タスクごとに、実行責任者（Responsible）、説明責任者（Accountable）、協業先（Consulted）、報告先（Informed）を決めておく手法だ。一般的なアジャイル開発での役割分担を整理した場合、次の表のようなマトリックス表として整理することができる。   PM PjM エンジニア QA担当者 バックログの作成 R A C I 工数見積 I A R C イテレーション（スプリント）計画 A R C C 朝会の開催 A R C C 個別工数見積 I A R C 振り返り実施 A R C C テストプラン策定 I A C R ステークホルダーとの交渉 R A I I ロードマップとのすり合わせ R A I I 　このRACIにはいくつもの派生物があり、実行責任者（Responsible）に加えて、実際の作業担当を行うサポート（Support）を追加したものや、スクラム開発手法を用いる場合にスクラムマスターの役割を想定したファシリテーター（Facilitator）を追加したものなどがある。 　3つ目のマイルストーンの可視化も重要だ。チームを持つということは大小の差はあるが、メンバーに権限を委譲することでもある。意思決定が分散した状態で各々が正しい意思決定をするために、長期的な計画を知っておくことは必須である。ビジョンを達成するためにどのタイミングで何をしなければいけないのか、そして、どの順番で実施するのかを周知しておくことで、時間軸に沿った意思決定をすることができる。 　プロダクトのステージとフェーズのうち、プロダクトマネージャーが一度に見なければならない範囲はとても広い。なぜなら目の前のフェーズに取り掛かりながら、常にチームより一歩先の未来のことも考えなければならないからだ。しかしながら、プロダクトマネージャーだけが未来を見据えて物事を考え、他のメンバーは目の前の目標に集中しているのは健全だろうか。もちろん、プロダクトチームが目の前の目標に集中できる環境を整えることもプロダクトマネージャーの役割の1つではあるが、関わるチームメンバー全員がプロダクトの長期的な方針を念頭に置きながら動いている組織は、細部の意思決定にまで長期的な目標が反映される、とても強い組織だと言えるだろう。そのため、プロダクトチームが長期的な視点を持つ機会を提供することも必要だ。

[tak4hir0]

「言うは易し、行うは難し」のプロダクトマネジメント

はじめに 　初めまして。「予定通り進まないプロジェクトを、思った以上の成果に変える」プロジェクト進行支援家の後藤洋平と申します。”何を・どこまで・どうやって実現するか”が未知である、新たな取り組みにおける共有ビジョンづくりの方法論である「プ譜（＝プロジェクト譜）」という進行管理ツールの普及に取り組んでいます。 　プロジェクト進行支援という仕事柄、発展的に、プロダクトマネジメントにおいてもプ譜を適用する事例が増えています。そんなこともあって、この度、縁あってProductZineに寄稿させていただけることになりました。自分自身も現場で奮闘する人間として、現場感覚を主軸にしつつ、大局観や理論も見失わないようにして、有益な情報を提供できるように努めたいと思っています。お付き合いのほど、宜しくお願い申し上げます。 想定読者と連載のゴール 　本連載は、サブスクリプション型SaaSベンダーの経営者やCTO、あるいは現場指揮官であるセールスやカスタマーサクセス系の部門のマネージャの方々を読者として想定しています。全3回の短期連載形式で、プロダクトマネジメントという課題における要諦について整理をさせていただきたいと考えています。 　具体的には、プ譜という独自の方法論にたどり着く前と、その後、両方の取り組みについて紹介していくことで、最終的には、プロダクトマネジメントという活動において「どんな業務の形、どんな情報の流れのデザインが望ましいか」についての提言ができると良いなと思っています。 　というわけで、さっそく、第1回に入らせていただきます。題して、一見正しそうに見えて、実は悪手なオーソドックスアプローチ。間違わないようにすると、正解にたどり着けないという、プロダクトマネジメントの難しさについて語ってみたいと思います。 プロダクトマネジメントの目的は実にシンプル「開発優先順位を発見し、合意すること」 　まずは議論を始める前提を整理するために、プロダクトマネジメントが求められる背景について簡単に整理させていただきます。 　AWSが初めて公開された2006年から実に14年という時間が経過し、世はまさにSaaSの百花繚乱時代を迎えています。サブスクリプション型SaaSという提供形態は、従来のパッケージ型の製品と異なり、製品全体が完成する前段階でも提供開始でき、少ない初期費用と利用量に応じた月額課金によって資金の回収もでき、それをさらに製品の改良改善につなげられるという、ベンダー／ユーザーの双方にとって、実に都合のいい座組みを実現するものでした。 　しかし、一方でこの形態は、製品の開発と提供における、あらゆる課題を解決できるわけでなかったことが、昨今、分かってきています。 　問題は、実際にサービス提供を行って、対価を得ながら、製品を改良改善していくという根本的なモデルそのものに内在しているのでした。 　そもそも、従来型のパッケージ＆オンプレミス型製品かサブスクリプション＆SaaS型製品かによらず、この世に完全なプロダクトは存在しません。実際にそれが業務の現場で動き始めたとたん、さまざまな利害関係者から無限の要望要求が雨あられと降ってくる状態が訪れます。 　違いがあるとすれば、極端に言うと、旧来型の製品は「我慢して使う（そしていつの間にか慣れる）」という方法を選ばざるを得ず、逆に言えばそれで済んでもいたのでした。どうしてもカスタマイズしたい場合は、自社専用に構築した情報システムなので、資金とエンジニアさえ確保できればそれも可能でした。 　一方、SaaSは常に未来への可能性に開かれており、時間が経つと、もっと良くなるかもしれない。また、追加開発するにしても、標準的な全ユーザー共通の機能にするのか、個別企業向けのカスタマイズにするのか、またそれらについての課金はどのようにするのかなど、複雑に関連する問題が多く、永遠に増え続ける要望要求と付き合う難易度が、実は、こちらのほうが遥かに高い一面があります。 　営業的には「売るためにはこういう機能や仕様が必要だ」、マーケ的には「注目を集めるような斬新なコンセプトと美しい事例を」、顧客からはもちろん「もっと使いやすく、もっと便利に、もっと安価に」、経営者からは「機能も顧客満足も大事だが、利益も大事」etc.……。どれもこれも、一つひとつは至極まっとうな正しい意見なのですが、当たり前ながら、開発するためには時間も資金も必要であり、困ったことに、そうした資源は、有限なのです。 　こうした理由によって、実にシンプルな「開発優先順位を発見し、合意すること」というだけのことが、非常に難しいのが、SaaS製品特有の悩みとなっています。 　筆者自身は、人材サービス企業向けのマーケットシェアNo.1の基幹業務システムをSaaS提供する企業で、カスタマーサクセス組織を立ち上げ、導入・運用コンサルティングに奔走した経験があります。さほど大きな組織というわけでもなかったのですが、処理しなければならない情報は非常に多岐にわたり、さまざまな課題を感じながら仕事をしていました。 　その時にこれは問題だと思ったのが、顧客対応含めた全般的なオペレーションの効率悪化と、それに根ざした組織感情の悪化の問題でした。真面目で優秀な人達が、共通のゴールに向かって仕事をしているはずなのに、部門間の利害対立や不信感が企業全体の効率性を極めて下げていると感じ、どうにか解決できないかと思っていたのでした。 補足 　2016～7年ぐらいのこと、当時はプロダクトマネジメントという言葉は流行していなかったと思いますが、今から振り返ると、まさにあの当時、自分が所属していた組織はプロダクトマネジメントの不在に悩まされていたのだなと思っています。

[tak4hir0]

プロダクト開発のホットトピックまとめ（6/20～7/9）

※旧SEメンバーシップ会員の方は、同じ登録情報（Eメール＆パスワード）でログインいただけます。

[tak4hir0]

グレープシティ、「RaySheet」にノーコードで画面レイアウトが可能な「RaySheetPage Designer」機能を追加：CodeZine（コードジン）

　グレープシティは、Salesforce上でExcelと同等の操作性や視認性を実現するSalesforce AppExchangeアプリ「RaySheet（レイシート）」に、ノンプログラミングで画面レイアウト設定ができる「RaySheetPage Designer（レイシート ページ デザイナー）」機能を追加して、6月24日にリリースした。 　「RaySheet」は、Salesforceの商談や取引先といったデータのExcelに類似した一覧での表示／編集や、データのフィルタリングが可能なSalesforce AppExchangeアプリ。 　今回追加された「RaySheetPage Designer」は、取引先や商談、ToDo、見積などさまざまなオブジェクトから必要な一覧画面を作成し、Lightning Experience上に複数配置できる機能で、設定ベースでのレイアウトが可能になっており、コーディングスキルがなくてもSalesforceの画面をカスタマイズできるので、業務をよく知る現場の担当者が自身の使いやすい画面を作れる。 　レイアウトのパターンは18種類を用意しており、サブスクリプションの契約とMRR（月間収益）のような親子関係のあるデータなどでも、画面遷移することなく1画面で参照／入力可能な画面を簡単に作成できる。 「RaySheetPage Designer」機能の活用例 関連リンク プレスリリース グレープシティ 「RaySheet」 Article copyright © 2020 Shoeisha Co., Ltd.