わたすけ

わたすけ

評価は他人から受けるもの

昔、自分は「アイデア出しの得意な0→1向きの人間」だと思っていた。 ただ、いろんな人から評価を受けた結果、実際には0.5とか1のアイデアや悩みの種をそれなりに実現可能性のある形と座組にする、「0.5〜1→10が得意な人間」なんだろうなと思うようになった。 (ここでいう数字はサービスの成長度ではなく、具体度の比喩と受け取って欲しい。最大値は100) 多少の挫折感もあったが、自分の得意領域を自分で決めて固執しなくてよかったと今は思っている。 任天堂の元社長の岩田氏も得意かど

わたすけ

    • 問題に飽きない慣れない

      慣れや飽きって恐ろしいもので、"ネタ"として変わり映えがしなくなったら事態は深刻していっているのにスルーされたりする。 大きな話で言えば、円安ドル高の進行とかもそうだし(ちょっと前のほうが騒がれてなかったですか？)、会社で言えば「よくあるユーザーからの苦情」とかもそう。 案外、問題に気づかれた時や事態の悪くなり始めた時が最もニュースバリューが高いので騒がれて、以降はいつものこと扱いされたりして、全然事態は改善されていないのになぜかぬるーっと見過ごされたりする。 こういうこ

      わたすけ

      • 猫を飼うにあたって買ってよかったもの

        これはなに10月から猫を飼い始めました。 (保護猫団体から1歳5ヶ月位の子を譲り受けました) それにあたって、買ってよかったものをまとめました。 まわりの猫飼い先輩方からの推薦も参考にしました。 買ったもの自動トイレ いろんな人から「自動トイレは圧倒的に楽になるよ」と薦められたので。 多くのメーカーから出てるけど、自分が買ったのはPETKITの第2世代のやつです。 比較して、 入り口が低いので入りやすそう 排泄物の入る箱の密閉度が高いのでニオイが漏れにくいらし

        わたすけ

        • 新しい環境でバリューを発揮するためにやったこと

          これはなに新しいチームに配属されたり転職してきたりしたとき、どうバリューを発揮するか、watasukeなりの考え watasukeは2022/7から新しい部署に配属されたのでそのときやったこと、思ったこと 樫田光さんの書かれた新しい環境でバリューが出せずに悩んでいる場合の解決法に触発されたものです watasukeの場合できることをやる 自分にできる、手っ取り早くバリューを発揮できることからコツコツとはじめる たとえばwatasukeは元いたチームの経験を活かした視

          わたすけ

        評価は他人から受けるもの

        わたすけ

          PMのおかげは3割

          なにがいいたいの成果に対するPMの貢献割合は大きくても3割位だなあという肌感がある あとはエンジニアやデザイナーやCSやバックオフィスや決裁者が称えられる分 でもそれぞれ得意領域があってどこが欠けても10割にはならないからPMもみんなも誇りを持って自分の領域でがんばろう 本編PMってなんなのPMって謎だなあと思うことがあります。 自分を振り返ると、コードを書くわけでもなく、デザインするわけでもなく、自分はあれしろこれしろと言うだけに思えたりして。 PMはプロダクトの

          わたすけ

          PMのおかげは3割

          わたすけ

          ICL(眼内コンタクトレンズ)手術を受けて、よかった

          ※注: 私は医師ではないので、正確な知識は各自ググったり医師に聞いたりしてください。 ICL(眼内コンタクトレンズ)ってなに？いわゆる視力を良くするための手法のひとつで、レーシックの強い版みたいなやつです。 レーシックは角膜を削るのに対して、ICLは目の中にコンタクトレンズを埋め込みます。 手法上、レーシックが不可逆なのに対してICLはいざとなれば取り外したり入れ直したりもできます。 また、見え方の質もレーシックより良いとされています。 レーシックは角膜を削ってしまうの

          わたすけ

          ICL(眼内コンタクトレンズ)手術を受けて、よかった

          わたすけ

          問題を問題として扱ってもらう技術(がほしい)

          問題を発見する技術や、問題を解決する技術が話題に上がることは多いけど、それと同じくらい問題を問題として扱う・扱ってもらう技術って重要だなと思う。 仮に問題が発見されたとしても、問題として扱われなければ存在しなかったのと同じになってしまうので。 たとえば、問題が報告されたのに 「その問題は既知なんだよなあ…(ただし未解決)」 「その問題は誰が対応すればいいかわかんないんだよなあ…」 みたいになって解決にまで進まないケースを誰もが一度は見たことがあると思う。 そういうのって

          わたすけ

          問題を問題として扱ってもらう技術(がほしい)

          わたすけ

          報・連・相(ほうれんそう)に悩まないために整理してフローチャートをつくった

          この文章はなにか将来の自分が報・連・相(ほうれんそう)について悩んだ時に取るべき行動をかんたんに選べるようにする文章。 自分のほうれんそうに関する思考が詰め込まれているのに加え、その時の自分の取るべき行動がわかるフローチャートがある。 できたフローチャートはこれ。以下の文章はここに至るまでの整理。 ※自分向けに特化しているので、自分以外の人はそのままでは適用できないかもしれない(とくに行動の判断基準) なぜ書いたのかちょくちょく「どうほうれんそうしようか」と悩むが、辿る

          わたすけ

          報・連・相(ほうれんそう)に悩まないために整理してフローチャートをつくった

          わたすけ

          承認欲求の目的は承認ではなく自己肯定じゃないか

          承認欲求に振り回される人生を送ってきた。 そんななかで不思議だったのは、「なぜ自分は他者から承認を求めるのか」ということだ。 欲求が生まれるには何らかの原理が背景にあるはずだ。 例えば「何かを食べたい」という欲求の背景には「お腹が空いたままでは餓死してしまう」という生理的な理由があり、だからこそ「お腹が空いたら何かを食べたくさせる」という仕組みが生物にはできあがっていったのだと思う。 でも、承認欲求に関して言えばどうもそこまでシンプルな原理ではない気がする。 他者から承認

          わたすけ

          承認欲求の目的は承認ではなく自己肯定じゃないか

          わたすけ

          祖父と養子縁組して名字と山を継いだ話

          四年前に母方の祖父と養子縁組をした。先祖代々の名字と土地を継ぐためである。（こう書くと”お家のために”的なニュアンスが出るが、これまで育ってきた中でも、今でも、別段自身の生き方に制限をかけられるような経験はしていない） 発端は3,4年前だったか、母から冗談めかした、しかし本心でもあることがわかる口ぶりで「祖父がどう跡を継ごうか悩んでいる」「あなたが継いだりしてくれたらいいけどね」と祖父の家から帰る車中で言ってきたことだった。 僕は「面倒がなければ別に構わないけどね」と返した

          わたすけ

          祖父と養子縁組して名字と山を継いだ話

          わたすけ

          よくないDMにはズルDMとビビりDMがある

          ここでいうDMとはSlackのDMのことだ。 SlackのDMの使われ方にはよく悪評が立つ。そして「DMは減らそう」と標語のように言われる。 では悪評が立つ原因の"よくないDM"とはどんなものだろう。 よくないDMは大きく”ズルDM”と”ビビりDM”に二分できると思う。 以下ではそれらの定義と起きる理由、そして対策について考察していく。 ズルDMとはズルDMは、本来あることが望ましい”事実確認”・”情報共有”・”関係者全員の合意”をすっ飛ばして何かを決める、正道ではないズ

          わたすけ

          よくないDMにはズルDMとビビりDMがある

          わたすけ

          非エンジニアがウェブサービスをつくるならプログラミングスクールに通うよりメンターを雇ったほうがいい

          先日、個人制作のウェブサービス「イチオシ交換ガチャ」をリリースしました。 その際、勉強のためにプログラミングスクールに一瞬入学し、落胆して自主退学し、知人のソフトウェアエンジニア(以下エンジニア)にメンターをしてもらって無事リリースできた経験から得た知見を記録しておきます。 誰に向けた記事か ・非エンジニア・個人でウェブサービスを作りたいと思っている人・どのように勉強すればウェブサービスを作れるか悩んでいる人 に向けて書いています。 要するに過去の自分が読みたかった

          わたすけ

          非エンジニアがウェブサービスをつくるならプログラミングスクールに通うよりメンターを雇ったほうがいい

          わたすけ

          自分のタスク管理をGoogleカレンダーで行う

          この投稿はわたすけ Advent Calendar 2017　4日目の記事です。 表題のとおりなのですが、ぼくはGoogleカレンダーで日々の自分のタスクを管理しています。 キャプチャは見やすいように自分のカレンダーだけを表示していますが、実際はチームメンバーのカレンダーも表示させています。 タスク管理方法はオンライン・オフライン問わずほんとうに数多あるのですが、いろいろ試してGoogleカレンダーを用いる形に落ち着いているので、なぜGoogleカレンダーを選んだのか、

          わたすけ

          自分のタスク管理をGoogleカレンダーで行う

          わたすけ

          チャットで聞くか直接話しかけるかMTGを設置するかの判断基準

          仕事をしていると「これ誰かに聞いたほうがいいな」という瞬間が時々発生する。そのときに、Slackなどのチャットで聞くか or 直接話しかけるか or MTGを設置するかという判断に迫られることになる。（そもそも自分で調べるか人に聞くかというところでも判断は発生するのだが、今回はそこには触れない。）その判断を、どのような基準で自分は行っているのかを、整理の意味も込めて書き出してみたい。 いきなりだが、下記が誰かに話を聞くときのかんたんなぼくの判断フローチャートだ。これをもとに

          わたすけ

          チャットで聞くか直接話しかけるかMTGを設置するかの判断基準

          わたすけ

          リモートでも一緒に働きたいかはレスポンスの早さで決まる

          この話はディレクター視点、つまりプロジェクトを管理する側からのものだとご留意ください。リモートで働きたいと考えている方の参考になれば幸いです。 現在、ぼくの所属するチームでは、数名のメンバーが部分的リモート勤務を行なっています。（週一出社、その他リモート）また、過去にはフルリモートのメンバーとの仕事、海外のメンバーとの仕事も経験してきました。その経験から、リモートでも一緒に働きたいかはレスポンスの早さで決まる、という持論があるのでその話をしようと思います。 まず前提として

          わたすけ

          リモートでも一緒に働きたいかはレスポンスの早さで決まる

          わたすけ

          ”答えの準備ができている人”はかっこいい

          ぼくが思うかっこいい人の条件のひとつに、”あらゆる質問に即答できる”というものがある。 それは別に必ずしも博識というだけでもなくて、たとえば「好きな食べ物なに？」と聞かれたときに「好きな食べ物？うーん……豚汁かな」と思考を挟むのではなくて、「豚汁。」とスパッと答えられることだったり、「最近見た映画でよかったのある？」と聞かれたときに「ブレードランナー2049は最高だったよ」と即答できるということだったりもする。 質問に即答できるかというのは、頭の回転の速さよりもむしろ事前

          わたすけ

          ”答えの準備ができている人”はかっこいい

          わたすけ