誰かから共有された方針を聞いた時、なんだか納得できなくてモヤッとすることがある。そういう時に共有した側もされた側も不幸にならないためのお作法的な動き方があると思っていて、雑にまとめておきたい。 1. 初手でファイティングポーズを取らない 納得できないこと ≒ 背景がわからないことに対する不快感はすごくて、つい"強い"言葉を使ってしまいがち 相手も人間なので、そういった態度や口調は鏡のように反射してくる。そうすると物事を前に進めにくくなってしまう どんなにアホな方針に見えたとしても、その裏にはそれなりにタフな議論が積み重ねられていることも多い まずは深呼吸して初手でファイティングポーズを取りそうになるのを抑えて、「取りまとめありがとう」って感じで相手へのリスペクトを示すとよい 2. 何に納得できないか深掘りする 納得できない時、意外と自分でも何が問題なのかはっきりとわかってないことも多い 内

「桜井政博のゲーム作るには」が、最終回を迎えた。 この番組は『星のカービィ』や『大乱闘スマッシュブラザーズ』のディレクターとしてお馴染みの桜井政博氏が、自身のゲーム制作で得たノウハウや仕事の姿勢などを発信するYouTubeチャンネルとして、業界の内外を問わず大きな話題を呼んでいた。 約2年半にわたって動画が投稿され、その数なんと、まとめ動画を除き260本！ その最終回はプレミア公開で多くのユーザーにリアルタイムで視聴され、「実は2年半も前に収録されていた」「別の企画と並行しながら作られていた」「制作費は9000万円」などの衝撃のデータが公開された。これもまた、ちょっと内容が濃密すぎて、大きな話題を呼んだ。 あの衝撃の裏話の数々に、「桜井さんがすごすぎて、正直少し怖い」という声も一部であがっていたけど……正直私もそう感じざるを得なかった。 い、いろんな意味ですごすぎる！ 今回、そんな「桜井政

新R25、乃木坂46 Mobileなどのファンビジネスを支えるマルチテナンシーなプラットフォームの全体像 / cam-multi-cloud

独学で個人開発を始めて5年が経ちました。これまでには収益化に成功したサービスもあれば、鳴かず飛ばずでお蔵入りになったサービスも数多くあります。それらの経験から、成功したサービスはなぜ上手くいったのか、マーケティングや収益化において押さえておくべきことは何か、その要点が少しずつ見えるようになりました。 今回は私が開発〜集客〜収益化を行うプロセスと、各工程で気をつけているポイントを順を追って書き出してみます。上手く言語化できているか分かりませんが、暖かい目でお付き合いください。 収益化した3つのサービス 私はこれまでにWebサービスを20個以上開発しており、現在はポモドーロタイマー（月間100万ユーザー）やYouTubeのループ再生ツール（月間10万ユーザー）などを運営し、そこからの収入で生活しています。 基本は海外向けのBtoCで、以下のようなツール系が中心です： 収益化済みサービス： Po

こんにちは。ダイニーのPM @takashi です。 みなさんは、社内からのプロダクト仕様質問などが多くて困っているなどはないでしょうか？ ダイニーでは、日々、顧客からの質問も含めて、プロダクトに関する詳細な仕様質問や、データ不備や不具合の調査依頼など様々な質問が寄せられています。 また、ダイニーは、導入店舗数が増えたり、新入社員が増えた時、営業が商談・サクセス活動のために顧客と接触を増やした時など、事業が大きくなるほど質問が増える構造となっており、対応が大変になっています。 基本的には、PMが回答する仕組みにしているのですが、件数が多く時間を取られてしまい、本来の企画等に割ける時間が減ってしまっている課題があったので、改善に取り組みました。 前提ダイニーでは、Slackに気軽にプロダクト関連の質問をできるチャンネルがあり、Slack Workflow を使って、フォームから質問できるよう

はじめにいつもお世話になっている方も、初めましての方も、この記事を見ようとしてくださり、ありがとうございます。 今回、完全専門外の素人エンジニアが、アプリ開発をして月100万円の不労所得を稼ぐ、という自分の中の一つの目標を達成することができたため、こちらを記事にさせていただいたところ、大変多くの方に見ていただき、大変嬉しく思っております。 今回は第二作目となる、前回の続きになります。 一作目をまだ見ていない！という方はこちらを見てください〜！ 一作目は、 なぜアプリ開発を始めようとおもったのか？ どのようなモチベーションで開発を続けられたのか？ アプリ収益化できていなかった時代にどう工夫して収益化したか？ などなどの内容になっており、アプリ開発をこれから始めようと考えられている方や、アプリ開発初心者の方に是非見ていただきたい内容になっております。 二作目は、『個人開発において、より戦略的に

この記事は以前 エンジニアと人生 というオンラインコミュニティで執筆し技術書典で頒布した本の中の、私の執筆した章をリライトしたものです。 無料公開の背景 本は有料で販売していたのでこの記事も有料記事にしようかとも思っていましたが、最近個人開発をネタにした特に中身のない記事を有料で買ってしまい後悔している友人を見かけて、そういうのにうんざりしていたので無料で公開することにしました。 個人開発云々いうなら中身のない情報商材じゃなくて自分のサービスで稼げよな！ ということで。でも投げ銭はありがたくいただくのでいいと思ったらバッジしてください！ 【追記】 上記に対して「有料記事がダメって事？」という反応を頂きました。書き方が悪く申し訳ありません。 有料でノウハウなどを販売する事は良いと思います！そしてそれでサービスの運営費を賄えるなら嬉しい事です。 なんならサービスに関する事ならこの記事の"データ

こんばんちは、スーパー太っちょWebディレクターです。 スーパーは太っちょにかかります。 なんと！ 前の記事（中間管理職を楽しむ方法。 - 笑顔を創りたいWebディレクターの日常）を読んでくれた方から、こんなおハガキ？をいただきました。 おなまえ（匿名OK）： s.m ご質問内容： 中間管理職を楽しむ方法のブログを読みました。わたしは中間管理職のすぐ下のポジションで（管理職より年下で平です）中間管理職にとって一番使い勝手が良い存在です。実際に「頼りにしている」と言われています。ただ管理職でもないのに管理職からチーム内のことについて相談されたり、チーム内でも二番手と認識されているため相談が多く飛んできたりと頼ってもらえて嬉しくはあるのですが、「管理職でもないのに…（権限もない、給料も違う）」という気持ちになり虚しくなります。勤務年数的に後輩を指導する立場であることは自覚していますが、前向きに

マネジメントの想定問題集があれば、疑似体験により引き出しが増えて成長が早まるのではないかと思ったことがあるので雑にかいておきたい。 マネジメントは昔からたくさんの関連書籍も出ていて、ある程度型をもって技術として磨いていけるものではある。 一方で、「やらないことを決める」「思い切って委譲する」といったいわゆる"セオリー"的なことは理解はしつつも、そういう小綺麗な話ばかりではないのはマネジメント経験者なら共感できるのではなかろうか。 社内での役割や経営・メンバーとの関係性にもよるけれども、たとえば次のような泥くさい想定問題があったらどう答えるか考えてみると面白いかもしれない。 1on1 でメンバーから「事業 / プロダクトの方針がわからない」と言われました このまま放置すると離職リスクになりうるかもしれません マネージャーとしてどう動きますか？ 事業計画上、4週間後にはリリースしたい機能があり

こんばんちは、スーパー太っちょWebディレクターです。 スーパーは太っちょにかかります。 はてな匿名ダイアリーでこんな記事を見つけて。 anond.hatelabo.jp 大変そうだなぁ・・・というよりつらそうだなぁと思った。 僕も中間管理職で、今の会社でもう３年以上経つ（＝４年目）。それ以前の会社での管理職経験を加えると、おそらく７〜８年やってると思うます。 マネジメントに関してはこんな記事も書いてましたの〜。 toksato.hatenablog.com そんな僕が、増田（匿名ダイアリーの筆者）に対して何か書くことで参考になるかなと思って、書いてみましょう、そうしましょうというやつです。 そんなわけで、うぇぶぎょうかいのむめいでぃれくたーのお時間です。 ■目次 それぞれ一つずつ回答してみるよ 中間管理職を楽しむ方法：あなたは選ばれし者なのです 追記:この記事読んだ方からおハガキ（？）い

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? これは、同じエンジニアである妻から聞いた話なのですが、彼女の案件で「メンバー全員で公式ドキュメントを読みあわせる」という取り組みがあったそうです。 で、この方法「チーム全体にとって大きなメリットがあるんじゃないか？」と思ったので、共有させていただきます。 「誰も知らない」から「みんな知ってる」に 私は開発職なので、めずらしいことなのかそうではないのか判断がつかないのですが、その案件では、導入対象の製品について詳しい知識を持っているメンバーが一人もいなかったというのです。 誰もその製品をさわったことがなく、とりあえず強そうなメンバーを入れ

AIにフルスタックアプリの生成を指示、Webブラウザ上のNode.js環境でそのまま実行できる「bolt.new」、StackBlitzが公開 WebAssemblyを用いてWebブラウザ上でNode.js環境を実現する「WebContainer」などを提供するStackBlitzは、Webブラウザ上でAIにフルスタックアプリの生成を指示し、そのままWebブラウザ上のNode.js環境で実行やデバッグなどを行える新サービス「bolt.new」を公開しました。 bolt.newはGitHubでサインオンすることにより誰でも無料で試すことができます。 bolt.newの大きな特徴は3つあります。 1つ目は、AIがフルスタックアプリケーションの生成を、必要なパッケージやライブラリの導入からコードの生成、ビルドまで含めて最初から最後まで実行してくれる点。 2つ目は、AIが生成したフルスタックアプリ

参考 IT業界では、請負契約と準委任契約がよく使われます。 委任契約はあまり使われることはなく、筆者も見たことがありません。 これは、エンジニアが法律行為を伴う業務を行うことが少ないためです。 請負契約と準委任契約の違い 請負契約と準委任契約は、どちらも業務委託契約の一種ですが、大きな違いがあります。 一言でいうと、請負契約は「成果物を納品することが目的」であり、準委任契約は「業務の遂行自体が目的」です。 請負契約では成果物を納品する責任が発生しますが、準委任契約ではその責任は発生しません。 ウォーターフォール開発で言うと、PoCや要件定義は準委任契約、設計や開発、テストは請負契約になることが多いです。 また、SES（システムエンジニアリングサービス）も準委任契約で結ばれることが多いですね。 PoCや要件定義が準委任契約になることが多いのは、不確定要素が多いため、確実に成果物を納品すること

2024/09/24追記 なんか適当に書いてたのが沢山の人に読まれてて驚いてる。読みにくくてごめんね。 いつの間にか、働いてて（最重要）健康で（これも重要）好き嫌いが少なくて（そこまで重視してない）あとはまぁ私より身長が高いと良いかな〜くらいだった私の希望が、とにかく高身長希望！みたいにすり替わってたのが1番びっくりした。私自身は160後半で、自分と同じくらいの人と付き合ったこともあるけど、オシャレのつもりでヒールの靴を履いたら「バカにしてるのか」と怒ったりするし（これは自分の見る目がないだけ）相手のためにヒールを履かないのもなんかおかしいな…と思って、気兼ねなくヒールを履けるくらいの身長だといいなって気持ちで身長が高ければなお良し、と書いたんだよね。ヒール好きだし。ヒールを履いてる私のことを良いねって言ってくれる人なら身長は特に重視してなかったよ。 ちなみに低身長男性からは「女として見る

1つのIssueが大きくなると1 Pull Requestで大量の差分が発生します。 そうなるとレビュワーに負担がかかり、コンフリクトの可能性も高まり、コードレビューを効率よく進めることができません。 このINVEST原則を守ることでチームはより効果的に作業を進め、柔軟に対応して開発を進めることができます。 Git Flow Git Flowは5種類(main, hotfix, release, develop, feature)のブランチを運用するブランチ戦略です。 2010年に提唱された有名なブランチ戦略です。 オンラインサービスのように継続的デリバリーするコードを想定して作られた戦略ではないです。 main ブランチ 常にリリースできる状態を保つ hotfix, develop へ切り出す このブランチへの直pushはNG hotfix ブランチ バグ修正など緊急時に対応するためのブ

『スプラトゥーン3』で開催されていた「グランドフェスティバル」が終わった。これは最後のフェスではないのだが、ひとつの区切りになる大規模なイベントだった。 『スプラトゥーン3』は事前の告知どおり2年間のコンテンツ追加が実施され、このフェスで一区切りとなっている。今後もバランス調整アップデートはあるそうだが、新規コンテンツの追加は終了となる。 実質的な終焉を飾るお祭りということで、グランドフェスティバルは非常に豪華な作りであった。ハブが専用マップになり、細かな仕掛けがたくさんあり、かなりの工数がかけられたであろう。 さて、そんなグランドフェスティバルのお題は「大切なのは？ 過去 vs 現在 vs 未来」であった。まるでユーザーに「スプラトゥーン」シリーズのどこを好むのかと言わんばかりのお題だ。 はたしてこのシリーズは、現在どんな状況に置かれているのか？ そして『スプラトゥーン4』はどうなるべき

追記　気づいたら伸びてた、ありがたい。 店の名前言った方がいい→これは何人か推測されてる通りKOZO、ありがとうKOZO。 金に糸目をつけない美食か→決してそこまで敷居は高くない。食べログに値段出てたけどソシャゲのガチャ20連と同じ程度なので庶民にも十分手が出る。何に価値を感じるかってあると思うけどこれは本気でいい体験だった。 目的　ステマとかではない。よっしゃ再訪のチャンス！とか思っていたらお店が閉店になっていてショックを受けた。 なんなら親の還暦祝いを絶対そこでしたかったぐらいの勢いだし親が死ぬまでには、いや自分が死ぬまでにもう一度あの店（シェフ）の料理を食べておきたいと思った。 辞めた理由ってのもあるだろうけど正直有名店の半額以下だしコスパ良すぎて儲からないなら倍払っていいまであるからもう一度店出してという、中毒患者の呻きみたいなものだと思ってほしい。 どんな店なの　京都にあるガスト

以下の記事などで既にかなり話題になっていますが、ぼくも触ってみました(使い方などの詳細はこちらの記事を参照してください)。 結論としては、マジすごくてかなり衝撃的です。すべてのホワイトカラーワーカーにとって、かなりディスラプティブなツールになるのではないでしょうか。 自分はコンサルタントでして、これまでにたくさんの資料を作ってきてスキルを磨いてきたつもりだったので、AIポン出しでここまでのものが出てきてしまうと、正直、人生について考えさせられちゃいますね。 この記事では、Napkinを使ってどういう資料ができたのか共有したいと思います。 ポストモーテムの勉強会をしたいなと思っていたので、まずはChatGPTで資料の骨子を出力し、それをNapkinに入力してみました。それで得られたのが、以下の資料です。 スライド1: タイトルスライド タイトル: ポストモーテムの教科書 副題: SREにおけ

技術選定の成功 2年間を振り返る TypeScript,Hono,Nest.js,React,GraphQL 技術選定に失敗はない 技術選定に失敗はありません。 仮説を立て、検証し、結果の分析からNext Actionを考える。検証の結果がどうであれ、それは過程に過ぎません。 机上の空論だけで全てを理解できるほど、我々人間は賢くないのです。（注意: これは人類全体を誹謗中傷する意味ではありません。） この記事では、この２年間で行った技術選定の成功例をその理由と共に紹介していこうと思います。 申し訳遅れましたが、私、YadaYadaKonnanYadaといいます。私は今回初めて記事を書いたので、どうぞお手柔らかに。 Twitterエンジニア垢作りました。エンジニアのお友達がいません。 @uncode_jp 前提 技術選定に結論はありません。組織毎に前提が違うのだから当然のことです。みんな違っ