dotrikunの日記

日々マンガを読んだりプログラムを書いたりしています。

インターネットの闇に飲まれない休日の過ごし方

2021年のインターネットは休日によくない

2021年現在、インターネットの一部が人喰い沼みたいなものになってしまっていると思う。

よくある流れとして

  1. 無料で誰でも使えるプラットフォームが作られる
  2. 炎上商法マンが炎上コンテンツを用意する
  3. 炎上コンテンツに釣られた人が集まる
  4. プラットフォーマーは広告で稼ぎ、炎上商法マンも注意を引きつつマネタイズ手段に誘導する

プラットフォームの移り変わりはありつつも、だいたい同じことを繰り返している。

TwitterやYoutubeを楽しむのは良い。 ただ拡散やサジェストでいやおうなくそういったものが目に入ってくる。 炎上コンテンツにアテンションを奪われ、憎悪に染められていくのは人生の浪費でしかない。

エンターテイメントを楽しんだり、アートを鑑賞したり、勉強したり、創作したり、自分の心の豊かさにつながる活動をしたい。

おすすめの休日の過ごし方

とはいえ外にも出かけられず、映画を観る集中力や勉強する気力がわかないこともままある。

そこでたどり着いたのがこちら

「Amazonなどで好きな作品に星5のレビューを投稿する」

星3や星4じゃなく、とにかく星5のレビューを書く。

推し作品の魅力や特徴を、なぜ星5に値するのかを言語化して、投稿する。

言語化スキルが高まり、推し作品の解像度も上がり、参考になった投票数で推し作品への貢献度も測れる。

あとなんだかわからないけど褒めてると自己肯定感アップにつながる（気がする）

エンジニアからプロダクトマネージャにジョブチェンジした話

この記事は Sansan Advent Calendar 2017 の5日目にあたるものです。

とある新人プロダクトマネージャのポエムです。 （私の観測範囲の出来事ベースなので暖かい目で見てください）

前段

私はこれまで3社で開発者としてシステム開発を経験してきました。

受託開発を1年、自社プロダクト開発を7年。内容はWebアプリとiOSアプリの開発です。役割は開発エンジニア兼たまにリードデベロッパー、開発チームリーダーなどを担当してきました。

そして先月からとあるスマホアプリのプロダクトマネージャにジョブチェンジしました。

なぜプロダクトマネージャになったのか

前任のプロダクトマネージャが退職した結果、不在になったポジションを埋める者としてその時点では自分が最も適任だと思い引き継ぎました。

適任だと思った理由としては

  • 開発チームリーダーとして社内にそれなりに顔が利いて、（エンジニアの中では）事業を理解している方である
  • iOSアプリのメインプログラマーとしてほとんどの機能を実装しており仕様を把握している

という感じです。

スマホアプリをフルリニューアルしてSwift書きまくれるようになったのになー、という気持ちもありつつ、新たな領域を広げるチャンスでもあるかなーと思い引き受けることにしました。

プロダクトマネージャのお仕事

仕事はめっちゃいろいろありますが、大別すると以下の4つカテゴリに当てはまるものは大体自分の仕事になります。

  1. プロダクトの運用保守
  2. プロダクトに関する課題の発見/課題の管理/開発プロジェクトの起案
  3. プロダクト開発
  4. プロモーション

今の会社はかなり組織が出来上がっているので、もっとスタートアップな環境だとサポートとかヘルプデスクとかもプロダクトマネージャの仕事になると思います。

プロダクトマネージャとして大切なこと

なって間もないですが、今の時点で分かっている範囲です。

課題の発見/整理/プロジェクト起案

プロダクトマネージャになった瞬間思ったことは「開発パワー全然足りねぇ！」です。

プロダクトで実現したいことは山ほどあります。 しかしできることが限られている中でやるべきこと、やらないといけないことを正確に把握し、課題をどう解決するのかを定義して開発にバトンタッチする必要があります。

そして埋もれている課題がないか、異常が起きていないか、常にアテンションを張り続ける毎日です。

優先度の判断

サービスを提供しているといろいろなことが突発的に起きます。 負荷で動かなくなったり、思いがけぬ不具合が発生したり、他社とのやりとりの中で機能が必要になったりします。

そういった時に今やっていることと、発生したことへの対処どちらを優先すべきなのかの判断を迫られます。

その判断の根拠となるのがビジネスや事業の理解、ユーザに対する理解、ユーザの業務に対する理解、数字などプロダクトに関係するあらゆる要素です。

判断の質を上げるために、とにかく知ることと調べることが大切です。

自分の限界をプロダクトの限界にしない

私は自分がユーザではないスマホアプリを担当しています。

それらしい使い方を考えて提案してはいるものの、実際の業務をリアルには想像できるはずがないと思ってますし、KPIに適切な数字を設定できていない可能性もあります。

だからといって最高のプロダクトが作れないかといったらそうでもないと思っています。 専門家や有識者の助けを借りる、ユーザやカスタマーサクセスの担当者にヒアリングをする、できていないことが分かってさえいればいくらでも工夫のやりようはあります。

エンジニア出身プロダクトマネージャの強み

エンジニアからジョブチェンジするといっても自分がまったく使わないアプリの担当なので相当な勇気が必要でした。 しかしエンジニアだからこそ発揮できる強みもありました。

実現するための手段、難易度、規模感を明確にイメージできる

手段を即座に想像し、技術面で企画の精度を上げることができる

開発者とのやりとりの効率、精度が良い

開発を進めるためにどういう情報が必要なのか、いつのタイミングで何が必要になるのか、といった段取りができることと、精度の高い開発コミュケーションをとることができる

自身の業務の効率化ができる

自分でスクリプトを書いて自動化したり、様々なシステムを使いこなすことができる

所感

（成熟していないプロダクトと開発組織においては）プロダクトマネージャというのは自分の領域を自分で定義していく必要があります。

また自分で担当領域を広げていったり、人に任せたり、仕組み化したり、とにかく自由度が高くて問題解決能力が問われます。

判断の質はすごい鍛えられると思うので、戦い慣れしたスタンド使いみたいになりたい方は機会があれば是非チャレンジするとよいのではないでしょうか！

『建設的に議論できる能力』はもっと評価されるべき

開発するために議論する機会はめちゃくちゃあって、

建設的に議論できることって開発生産性にかなり影響すると思ってます。

以下、建設的じゃないなーと思った体験。

混ぜっ返す

その場で議論不可能なぐらい議論の対象を見境なく広げたり、遡ったりする現実逃避的な行為。

根底から覆す一言を発したい気持ちが空振りしていたり、

結局目の前の事象から目を逸しているだけだって私は気づいたのです。

想像や仮説を事実のように話す

情報を正確に伝えずと判断を歪めてしまう行為。

無意識にバイアスがかかるのはしゃーない。

だからこそできるだけ正確に伝えることを心がけたい。自戒込めて。

自明なことをあえて議題にしようとする

なんらかの意図で議論を遅延させようとする時に起こりがち。

やりたくない、通したくないのであればちゃんと理由を説明して理解を得るのが正道じゃないでしょうか。

それが大変だという意見は同意です。

感情的になる

自身の意見が否定されることに過剰反応する行為。

私が否定しているのはあなたの意見であってあなた自身ではないのです。

私が述べているのは批判であって批難ではないのです。

できるだけ配慮するけど遠慮はしません。傷つけてごめん。

でも問題を解決したいという気持ちはきっと同じはず。

なんだかんだ言って、人間と人間が話し合うことでシナジーが発生すると信じているし、それ自体は普遍的な価値観だと思ってますよ。

A friend in need is a friend indeed.

システム開発

タイトなスケジュール、それなりの開発規模、タスクの同時並行がかなり多い、

そういった追い込まれた環境だと人間の底力みたいなものが輝いて見える時がある。

頭の回転キレッキレなタイプじゃなかったり、普段はそんなに評価されてない人でも

  • 取り乱さない
  • 追い込まれた中でも力を発揮できる
  • 自分にできることはないか模索する

といった意志、行動力が物事を前に進める馬力を発生させてくれて、

「ああ、この人は本当に信頼できる人だな」と思える。

無論プロジェクトがそんな状態に陥らないのが一番であることは言うまでもないし、

そんな状態を作り出したり、状況をさらに悪化させるような人物を信用してはいけないということだけは確信できる。

シビアなプロジェクトは信頼すべき人を教えてくれる機会でもあるわけですな。

「Swift の良いところってどんなところだと思いますか？」

仕事で iOSアプリ開発者の面接を担当しています。

一昔前に比べてiOSアプリ開発の裾野が広がったのか、 応募も増えてSwiftに触ったことがない人の方が少ないぐらいです。

面接の場で必ず聞くようにしているのが

「Swift の良いところってどんなところだと思いますか？」

という質問です。

みたいことや、納得感やユニークさがある回答とかなんでもOKなんですが、意外に説明できる人が少ないです。

（良いプログラマが弊社を受けに来ていないという可能性もおおいにありますが…）

効率厨と心理的安全性

システム開発

心理的安全性というワードに時節に遅れた上に踊らされている方を見かけたのでちょっと考えた。

心理的安全性を担保して意見吸い上げまくって、 それをもとにアクション起こして効率良くして成果に繋げるのがやりたいことであって、 成果を求める集団において心理的安全性だけあってもしゃーないですわ、ってばっちゃが言ってた。

あと心理的安全性が担保されてても「こいつに言っても無駄やな」と思ったら相談とかしませんし。

相談を受けて口先でうまく丸め込んだつもりでいると、相手も上辺だけ納得した顔をしてフィードバックの源泉を失っていくんじゃないでしょうか。

まとめると

  • 効率のための和気あいあいであって、その逆ではない
  • 改善の実行力が伴ってはじめて相談相手として成立する
  • Googleの人が言ってることを鵜呑みにしない

かな！

UITableViewCellに付け外し可能なチェックマークを置く時の話

iOS

この記事はSansan Advent Calendar 2016の16日目のやつです。

仕事でiOS8のサポートがまだまだ切れなくてUIStackViewを使えないから、UITableViewCellの小ネタでもどうぞ。

概要

AutoLayout対応してるUITableViewCellに、 UITableViewCellAccessoryTypeで付け外しするチェックマークを実現して失敗したお話。

UITableViewCellにチェックマーク置きたい

リストセルの選択状態を表現するために、セルの右端にチェックマークを出したい時があります。

f:id:dotrikun:20161214182702p:plain

UITableViewCellにはaccessoryTypeという気の利いたプロパティが用意されていて、 定義されたEnumを指定するだけでいい感じのチェックマークを表示することができます。

typedef NS_ENUM(NSInteger, UITableViewCellAccessoryType) {
    UITableViewCellAccessoryNone,                                                      // don't show any accessory view
    UITableViewCellAccessoryDisclosureIndicator,                                       // regular chevron. doesn't track
    UITableViewCellAccessoryDetailDisclosureButton __TVOS_PROHIBITED,                 // info button w/ chevron. tracks
    UITableViewCellAccessoryCheckmark,                                                 // checkmark. doesn't track
    UITableViewCellAccessoryDetailButton NS_ENUM_AVAILABLE_IOS(7_0)  __TVOS_PROHIBITED // info button. tracks
};

なにが起こったか

先に書いたやり方でチェックマークの表示/非表示を切り換えを実装すると、セルの横幅に合わせたラベルが伸び縮みしてキモい。

f:id:dotrikun:20161214182500g:plain

なんでこうなるかというと、accessoryTypeに UITableViewCellAccessoryNone 以外を指定するとContentViewの横幅が自動的に狭まるから。 LabelはAutoLayoutでContentViewの右端からマージン取ってるので、ContentViewの幅が変わるとみょんみょんしてしまう。

結論

付け外し可能なチェックマークを実装したい場合、 accessoryType は使わずにUITableViewCellのContentViewに自前でチェックマーク画像のimageViewを置いてレイアウトを組みましょう！ということです。

（みょんみょんするのを気にしない場合はその限りではない）