意思決定できる人は進める手順の型みたいなものを持っているように見える。逆に意思決定が遅かったりできなかったりする人は、進めるときに型のうちの何かが欠けているのかもしれない。 体系化された話は書籍で語られつくされているとは思うが、思考整理のために雑にまとめてみる。 最後は決めるだけだという考えを持つ 目的や満たしたいことを明確にする 最終的な決め方や期日を明確にする 選択肢を広げて考える 今は意思決定しない、という意思決定も選択肢に入れる 意思決定の軸を明確にする 軸をもとに定量/定性データを集める 軸をもとに選択肢を評価する 自分はこうしたいという"推し"を決めてたたき台にする ここまでの話をドキュメントにしている ここまでのプロセスに時間をかけない 意見を聞く人を見定めてフィードバックをもらう 最初に明確にした決め方で意思決定する 意思決定できない場合は決め方と期日と意思決定軸を再定義す

はじめに 社内でTodo管理の勉強会を実施した際に作成した資料があったのですが、今回自分の中の考えをまとめるせっかくの機会だと思い、字面で書き起こすことにしました。 意外と世の中では語られることのなく、『あたりまえ』として扱われてしまう『自己管理』について自分が半年間運用し、週ごとにカイゼンを続けたどり着いた、現時点でのHowを多くの人に伝えられればなと思っています。 もちろん最適解がこの形とは言いませんし、自己管理は人の数分だけ最適解はあると思っています。「みんな正しい、ただし部分的に」ということを念頭に、楽しんで読んでいただければ幸いです。 タイトルを付けた理由としては、かなりシステマチックな内容になってしまっていると感じてしまったため、「運用レベルが高い」人物を想定した結果、このタイトルになりました。 概念篇 『自己管理』を行っていく上で、確実に「ここは飛ばしてはいけない」と思ったた

リモートワーク中ワイ ワイ「あーーー！！！」 ワイ「ストレスが溜まるんじゃ〜〜〜！！！」 ワイ「株式会社ゆめみで働くのは、ストレスが溜まるんじゃ〜〜〜！！！」 娘（7歳）「パパ、どうしたの？」 ワイ「いや、あのな？」 ワイ「パパの会社には、エンジニアが沢山おんねん」 娘「知ってるよ」 娘「社員の大半がエンジニアだもんね」 娘「200人以上いるよね」 ワイ「せやねん」 ワイ「そんで、エンジニアってのは、性格にクセのある奴が多いねん」 娘「へ〜」 娘「それで、何がストレスなの？」 ワイ「あのな？」 ズバズバ物を言うエンジニア ワイ「周囲への配慮をせずに、ズバズバ物を言う奴がおんねん」 ワイ「何人もおんねん」 ワイ「それで、周りの人たちは傷ついてると思うねん」 娘「なるほどね」 ワイ「そういうズバズバな奴らがムカつくねん」 ワイ「けしからんねん」 娘「でも、パパも昔はそんな感じだったよね」 娘「

こんにちは。モロと申します。 実は数年前警察のお世話になり、数年裁判等をやって、昨年晴れて無罪放免となったのですが、そういえばその後どこにも情報をまとめていなかったことに気が付きました。 正直にいうとまったく気の進まない作業ですし、数年間これにかかりきりだったこともあり「わざわざまとめなくても誰でも知ってることでは……？」みたいな気持ちもあります。 とはいえ冷静に考えると大抵の人は一生関わり合いになることのない知識で、お世話になった界隈に対して何も残さないのも不義理という感じがしたため遅ればせながら筆を執らせていただきます。 はじめに 当記事は、実際に警察のお世話になり、数年間弁護士の方にご指導いただきはしたものの、あくまで法律の専門家でも何でもない一エンジニア（というか多少エンジニアリングをかじったデザイナー）によるもので、第三者による監修等もなされていません。 実体験に基づいて少しでも

この記事で書きたいことは、以下のような内容です。 ・成果物やパフォーマンスを公開する時、どうしてもハードルを下げたくて、卑屈になってしまう時があります ・ですが、我々は「成果を誰かに見せる」時卑屈になるべきではありません。少なくともその時その場では、「これは最高の成果物だ」と信じて発表しなくてはいけません ・それは何故かというと、「自分の成果物への信頼」が、実際に受け取る側から見たクオリティにも直接影響する為です ・これは、成果物を作り上げていく過程で努力することや、色んな意見や批判を受けいれてクオリティを上げていくこととは矛盾しません。むしろワンセットの話です ・卑屈になっていると公開自体のハードルが高くなってしまうこともあり、無駄にMPを消費します ・我々には「自分の卑屈さをねじ伏せる覚悟」が必要です 以上です。よろしくお願いします。 さて、書きたいことは最初に全部書いてしまったので、

組織内のメンバーを「リソース」として見始めると、それを100%使い切ることにばかり注力してしまいます。リソースの稼働率を下げることは、すなわち、生産性を下げること。マネージャーは、まるで強迫観念に取り憑かれたように、そのような考えに囚われます。 自社でのソフトウェアプロダクト開発において、その対象は特に、開発者に強く向けられます。その理由は明らかでしょう。バックログに積み上がり続けるアイデアをソフトウェアに変えられるのは、開発者だけです。より多く、できる限り早く、アイデアを市場投入したい。彼らに空き時間という無駄を作らせてしまうわけにはいかない。 しかし、そのような努力が、必ずしも良い結果につながるとは限りません。むしろ、開発者の稼働率を高めすぎたことが、リードタイムに悪影響を与えているかもしれないのです。そして言うまでもなく、アイデアの市場投入が延びれば延びるほど、ユーザーにとってもビジ

指定した音声ファイルを、楽器ごとのパートに分解してくれるソフトです。 音声ファイルをドラッグ＆ドロップで放り込むと、該当のファイルを ボーカル ベース ドラム その他（キーボード、ギター 等） ボーカル以外のインストゥルメンタル といった 5 つのファイルに分解してくれます。 処理を GPU（CUDA）で実行することもできます。

イノベーション イノベーションを起こすためのスキルを習得し、業務に活かす方法を学びます。

仕事において、相手に情報を正しく伝えることは必須です。逆に、伝えたいことが正しく伝わらなければ、相手は誤った情報を元に業務を遂行することになります。結果、いくら質高く、効率よく仕事をしたところで、アウトプットは想定外のものとなり、全く役に立たない場合すらあります。 このように正しく伝えることはよりよい仕事をする上での大前提であり、非常に重要です。そして、正しく伝えることは才能ではなく習得可能な技術です。「正しく伝える技術入門」では、伝えたいことを意図通りに正しく伝えるために必要ことをまとめます。 # 更新情報 * 2022/11/16 - 公開

「相談があるのだけど……」と知人友人から持ち掛けられて、親切心から「アドバイス」をしてあげた。 でも、全く相手に響かず、「なんで言うとおりにやらないの」と、逆に相手を責めてしまい、何の解決にもならなかった。 そんな経験のある人はいないでしょうか。 私は死ぬほどあります。 そんな失敗から、徐々に私は「人からの相談」について、考えを改めざるを得ませんでした。 実際、「アドバイスの欲しい人」は本当に少ないのです。 多くの人が求めているのは、「黙って話を聞いてくれる人」であって、あれこれと改善案を考えてくれる人ではありません。 しかも、もっと悪いことに親切心からの「改善策」「アドバイス」はむしろ、「なんでこんなこともやってないの？」という批判だと受け止める相談者も少なくありません。 「◯◯してください」や「◯◯すべきです」といった直接表現はまず、誤解されて伝わるのです。 そして、非難されている、と

IT業界のプロジェクトを成功に導くためのノウハウを網羅的に解説した書籍『プロジェクトマネジメントの基本が全部わかる本』（翔泳社）。著者でパラダイスウェアの代表取締役である橋本将功さんは、プロジェクトマネージャーが直面する課題として大きく3つ、「現場で使える知識体系がない」「無茶ぶりされる」「スキルの属人化」を挙げています。これらの課題を解決するために何が必要なのでしょうか。本書から、プロジェクトマネージャーが持つべきスキルセットと、プロジェクトの成功と失敗をどう定義すればよいのかを紹介します。 本記事は『プロジェクトマネジメントの基本が全部わかる本 交渉・タスクマネジメント・計画立案から見積り・契約・要件定義・設計・テスト・保守改善まで』の「序章　プロジェクトマネジメントのスキルの全体像」と「第1章　プロジェクトとはなにか─基本的な知識と考え方をおさえよう」から一部を抜粋したものです。掲載

PMカンファレンス2022の登壇資料です。

相手に誠実に、わかりやすい文章を書くための心がけをまとめました。 どういう思考プロセスからどんな表現が生まれるのか、参考として実例を紹介しています。実際に読み比べ、SmartHRの従業員として何かを伝えようとするときの、参考にしてください。 伝わる文章のガイドライン何を伝えるかによって、必要な情報の量や説明の粒度は異なります。 情報が不足していたり、逆に情報が多すぎたりすると、読者が意図を読み取れないことがあります。 読み手となる相手の状況（読む場面、事前知識など）を踏まえ、言葉にする内容や表現を厳選することが大切です。 目的に合わせて情報を取捨選択する読者の目線に立ち、コンテンツの目的に合わせて情報を取捨選択しましょう。 実例1：法律や業務に関わる記事目的業務に関係する「厚生年金保険」について正確に知りたいと思っている人に、わかりやすく内容を伝える。 Before日本の年金制度は、全国民

クライアント先の社内ポエムだけど必要になることがあったので転記した。 @nekoya さんにお願いしたらそちらも公開してくれた。:圧倒的感謝: @nekoya さんの話がとても良かったので僕もポエムを書いてみる。 zenn.dev 僕もその昔はもちろん駆け出しのエンジニアで自信が無くて自分を低く見積もったり、ある程度自信があっても 謙虚であることが美徳 と思って自分を敢えて卑下するなんてことをよくやっていた。 脳ある鷹は爪を隠す、なんていうけど確かに周囲に低能力だと思われていたほうが便利なシーンもあるにはある。 しかし少なくとも社会で働く上で 自分の能力を適切に評価する ことは自分にとっても会社にとっても重要なことだ。 その前提の上で、自分を過小に評価することは、あなたの仕事の成果に対して高評価し、認めてくれている人たちにとっては裏切り行為と言える。 例えばとても良い仕事をしたのにも関わら

これを読んで欲しい人のターゲット像や前提について Web版開発の話をしています ITのソフトウェアエンジニアの話をしています ある程度チームのやり方に対して影響を与えられる権限がある人 マネージャーかメンバーかはあまり気にしないです 「発言するのは自由だが聞き流されるだけ」ならこの記事を読む意味はないです ある程度裁量権があり、ビジネスサイドとも話ができるチームのメンバーを想定しています 作業の流れの前提について チケットがあって 作業者がそれを取って（自分で取るのか他人にアサインされるのかは問わない） PullRequestの形でレビュー依頼をかけてレビュワーがレビューする OKならmergeしてそのうち本番デプロイ 間にQAが入るかもしれないけどそこは問わない 手が遅いとは何か？ ある作業者のサイクルタイムが他の作業者に比べて長いこと 100の大きさの作業があるチケットを渡した際に、ほ

今の世の中、自分のアタマで考えないほうが良いターンになっていると思いませんか。 犬も歩けばフェイクに当たる これはアウト。 物理的にありえない水の動き、現実的ではない家の配置、画質と画像サイズ。AIが作成した写真です。 熊本地震の際にライオンが逃げたとフェイクニュースを流した人と同様で、災害時に不安を煽るデマを流している。通報しました。 なお、ライオンの件投稿した男性は後に逮捕されています https://t.co/WRRKb1xrWy— なかむらすばる🌻紅楼夢【き03-b】 (@subaru_chen) 2022年9月26日 先日、静岡県の水害のフェイク画像がツイッター上に流された。ある者はそれを本物と思って拡散し、別の者はフェイクだと疑って拡散を思いとどまったり、疑問の声をあげたりした。自分のタイムラインではこれに引っかかる人はいなかったように見えたけれど、皆が皆、引っかからずに済ん

日本には、少子高齢化による労働人口の減少、地方と都市部、大企業と中小企業におけるデジタル格差といった課題があります。その課題をチャンスに変え、可能性を最大限開花させるための鍵が、デジタルトランスフォーメーションです。実際に、デジタルを最大限活用することで 2030 年までに日本で生まれる経済価値は年間で最大 67 兆 7000 億円にものぼり、そのうち約 43% にあたる年間最大約 30 兆円を中小企業が生み出すと試算されています（ *1 ）。 また、デジタルトランスフォーメーションを推進するうえで欠かせないのが、デジタル人材の育成です。 Google は本日、キャリアアッププログラム「Google Career Certificates」を日本で開始しました。 本プログラムは、IT 分野でより専門性が高く需要のある職につくための、オンラインキャリアアッププログラムとして Google が

僕はチーム join 時に、Docker は初手で剥がすし、GitHub Actions でやっているワークフローの全体像を把握するのを次に行う、というのを基本的にはやっている。これはシステム構成やデプロイ周りの全貌を把握するのが好きなのと、何かが起きたときにコレをやっているのといないのとで問題切り分けの精度に圧倒的な差があるからなんだけど、join 直後にやるのが最適解とは限らない場面もある。 チームの人員構成として、テックリード業を既に担っている人が居る場合、追加人員にはテックリード未満の「プラスの工数として数えられる戦力」となって欲しい。この戦力というのは、「目の前に積み上がった問題を一緒に解いて欲しい」という期待。問題と言うよりも、既にタスクになっているものを消化したい、という期待の方が大きいと思う。 そういう期待があるときには、ちんたら Docker を剥がしている場合ではなく、

2022-08-08 リーダーの作法 ささいなことをていねいにを読み終えた。 著者は Netscape でマネージャー、Apple でディレクター、Slack でエグゼクティブを経験した Michael Lopp さんで、過去にBeing Geek や Managing Humans を書かれている。 翻訳の質も非常に高く、楽しく読めた。1 そんなにマネジメント関係を読んでいるわけではないが、HITH OUTPUT MANAGEMENT や、エンジニアのためのマネジメントキャリアパス ―テックリードから CTO までマネジメントスキル向上ガイド 同じくらい良い書籍で、学びや共感を多く感じた。 自分はマネジメントのポジションについたことはないが、仕事をしていくなかでマネジメント関係のソフトスキルや複数人でどうやってうまくリーダシップを発揮して、大きい問題を解決するかに興味があるので、良い書籍

「Day One - CTO/VPoE Conference 2022 Spring -」は、日本CTO協会が主催するイベントです。パネルディスカッションでは、政財界、テクノロジー分野の第一人者をパネリストにお迎えし、日本CTO協会理事のモデレートにより、“Day One”をテーマにご講演いただきます。ここで登壇したのは、株式会社Lighthouse Studio CTOの海老原昂輔氏。これまでの経験から導き出した、“ソフトウェアエンジニア的思考をマネジメントに活用するアプローチ”について発表しました。全2回。前半は、最初期のマネジメントとプログラマーとして犯してしまった禁忌について。 エンジニアにありがちなキャリアの変遷 海老原昂輔氏：「コードを書いていたいけど、マネジメントもやるようになっちゃった人のための生存戦略」というタイトルでトークをします。株式会社Lighthouse Stud