#!/bin/bash
NCPU=96
for ((i=0;1;i++)) ; do
if make -j$(NCPU) >/dev/null 2>>log.txt ; then
echo "$i: $(date): OK" >>log.txt
else
echo "$i: $(date): NG" >>log.txt
fi
make clean >/dev/null 2>>log.txt
done
プロダクトマネージャーとは経営学用語の一つ。企業においてマーケティング活動全般の権限と責任を持つ管理者を担当する職種を言う。ここで言われている権限というのは製品の開発から、その製品の宣伝、販売、流通などの広範囲にわたっている。プロダクトマネージャーとは職種の名称であり職位を示す言葉でなく、必ずしもマネージャー職が担当すると言う意味ではない。現実にはその製品に詳しい一般社員が担当する場合が多い。
Wikipedia
当初は創業者たちがプロダクトマネジメントを牽引していましたが、会社や事業が拡大するに連れ、事業部制になりました。この頃は各製品の事業部長が事業責任やプロダクトマネジメントを負っていました。
2006年頃に事業部制から職能制とプロジェクト制になり、プロダクトマネージャー職を導入しました。その後、開発部門と連携を強めることと、販売部門の活動を統合するために、開発側、ビジネス側双方にプロダクトマネージャー職を置く体制になりました。
Image may be NSFW. Clik here to view. ▼参考 サイボウズPM(開発PM)について
2つのプロダクトマネージャー職
サイボウズでは、開発業務を担当する「開発PM」と販売、マーケティング業務を担当する「ビジネスプロダクトマネージャー」(以降BPM)と2つのPM職があります。 もともと独立した組織としてプロダクトマネージャー職が生まれましたが、開発部門と連携を強化するために、開発部門内に統合されていました。 その後、顧客の要求を吸い上げる、販売戦略を立案することに特化した職能として、また担当製品のビジネス面での責任者として、「BPM」が設置されました。
Image may be NSFW. Clik here to view.
次のスライドでは、アメリカ拠点のビジネスチームと協同してペインストーミングやカスタマージャーニーマップという手法を使って課題を探求し、どんな問題に取り掛かるかを定義した体験が書かれています。 こうした手法による顧客や市場の課題の仮説設定もプロダクトマネージャーの重要な役割です。
Image may be NSFW. Clik here to view. ▼参考 ペインストーミングで言葉の壁を超える
利用者の行動を観察する
課題の探求は仮説設定だけではありません。利用者がどのような行動をするのか、どんなところで製品の操作に躓くのか、実際に使う様子を観察する調査も行います。 デザインチームと協力してユーザービリティテストを実施したり、利用者の行動や発言から、製品の課題を探求します。
Image may be NSFW. Clik here to view. ▼参考 【ユーザビリティテスト@サンフランシスコ】
こうして発見した課題を機能に落とし込み、確実にリリースする責任があるのがプロダクトマネージャーの責任です。 開発チームのメンバーに、しっかり納得、理解してもらった上で開発を進める必要があります。チームによっては、ベトナム、上海拠点と協力して開発を進めています。 意見交換やノウハウ共有、親睦を深めるために年に数回実際に海外拠点に出張することがあります。
Image may be NSFW. Clik here to view.
ReplicaのPodは、KubernetesのAffinity and anti-affinityにより、必ず異なるノードに配置されます。
これにより、1つのノードが故障しても同時に複数のReplicaが落ちることはなく、ストレージの機能を提供し続けることが可能です。 また、Replicaが1つになったときは、書き込みができないリードオンリーモードになります。
Xcode のメニューから 「Debug > Attach to Process > By Process Identifier (PID) or Name」を選択します。
Image may be NSFW. Clik here to view.
「PID or Process Name」 の部分に開発中のアプリ名(プロセス名)を指定して、「Attach」ボタンを押します。 そうすると、Xcode は、アプリが未起動の場合はプロセスが起動するまでアタッチを待機してくれます。
なので、プッシュ通知などからアプリが立ち上がったときに、即時にアタッチされ起動直後の処理のデバッグが可能になります。
Android の場合
Android の場合は、ブレークポイントの手前で Debug#waitForDebugger()を仕込んでおきます。これにより、アプリはデバッガがアタッチされるまで待機するようになります。 なので、プッシュ通知などでアプリが起動後、停止している最中に Android Studio のメニューの 「Run > Attach debugger to Android process」を実行してプロセスにアタッチすれば、アプリが再び動き出しデバッグ可能な状態になります。
Image may be NSFW. Clik here to view.
まとめ
iOS の場合は、Xcode で先にアタッチを準備しプロセスが起動するまで待機。
Android の場合は、アプリが先にアタッチされるのを待機し Android Studio がアタッチする。
順番が異なりますが、両 OS ともにプッシュ通知などから起動したときの処理のデバッグが可能です。 あまり必要となる機会は無いと思いますが、最近必要になって調べてみたのでどなたかのお役に立てれば幸いです。
講義はたくさんあるので全部紹介することはできませんが、例えば Linux カーネルの脆弱性を突く方法を学ぶ講義や、
USB ポートに挿すだけでキーボードを自動入力してしまう Bad USB と呼ばれるハードウェアを作る講義などがあります。
筆者（内田）は以前、Bad USB の講義に潜り込ませてもらい、PC に挿すと自動で管理者権限のコマンドを実行するようなハードウェアを作ることができました。
