葬式って超大変。両親が健在な人こそ読んで！その１｜とむよーこ
それはいきなりやってくる「喪主」役こんにちは。 私はこの3年間に両親がどちらも急逝し、 心の準備ができぬまま葬式を2回行いました。 特に最初に亡くなった父は、 印鑑や通帳類もまとまってなければ 、 死後どうするのかも話せていなかった ＆私自身がお葬式にでた経験がほぼ皆無だったため、「人を見送る」ってまじこんなに大変なんかい！誰か先に教えておいてよ！と思いました。 ということで、まだ両親が健在な方にこそ 「両親が突然亡くなったら何をしないといけないのか？」 「自分がいつか死ぬに当たり、準備しておくべきものは？」を知って、少しでも皆さんが何かあったときに焦らないでいいように、 私の経験をナレッジ共有しときたい！ と、noteにまとめることにしました。 何はともあれ必要なのは「届け出」結婚する時には「婚約届」を出すように、 人が死んだときには「死亡届」がないと何もできません。 提出期限は国内の場
『良いコード/悪いコードで学ぶ設計入門 』を出版します｜ミノ駆動
こんにちは、リファクタリングが大好きなミノ駆動です。 これは、私が執筆した『良いコード/悪いコードで学ぶ設計入門 ―保守しやすい 成長し続けるコードの書き方』について紹介する記事です。 2022年4月30日発売です（ほぼ同日に電子書籍版も出ます）。 AmazonなどECサイトで、すでに多くの予約が入っており、ヨドバシ.comでは一時期予約終了になったほどです。おかげさまで初版部数が2倍になりました。 ■どんな本？皆さんはプログラミングでバグを埋め込みたいですか？ロジック修正が上手くいかず、ヒィヒィ言いながら長時間残業したいですか？イヤに決まってますよね。ところが現実には、 何度もバグを埋め込んでしまう ロジックを読み解くのに時間がかかる やっとロジック修正しても、全然違う箇所がバグ化してしまう ……ほとんど誰もが体験しているのではないでしょうか。 でも、こうした状況をなんとかしたいと思って
0→1フェーズで最も重要なサービスコンセプトのつくり方 | 実プロジェクトの事例付き｜梶谷健人 / 新著「生成AI時代を勝ち抜く事業・組織のつくり方」
サービスを0→1でつくる上でまず必要になるのが、サービスのコンセプトづくりです。 いままで自社事業や様々な企業との共同プロジェクトを通じてサービスづくりに取り組む中で、サービスのコンセプトづくり、すなわちコンセプトメイキングのプロセスにもある種の型があることに気付きました。 このnoteでは社内ドキュメントである「サービスコンセプトのつくり方」の内容を一部NDAでシェアできない資料を除いて全公開します。 ＜コンセプトメイキングの大前提＞🧐 STEP１：コンセプトとは何かを知ろうコンセプトが何かを知る上で、コンセプトの立ち位置と役割を知ろうコンセプトそれ自体は様々な形があり、非常に漠然としている。 なので、コンセプトがそれ以外の要素とどういった関係にあるのか、どういった役割を果たすのかという観点からコンセプトとは何かを理解しよう。 まずサービスアイデアは下図のような構造を持っている。 ある
将来のCTOを迎えるために エンジニアリングマネージャーが半年でやったこと｜miyamoto
カミナシでEM(エンジニアリングマネージャー)をしている宮本と申します。 カミナシには現在CTOがいません。 ただ、採用活動は進めておりますので、近い内に採用活動が花開くことを切に願っております。 本記事では、将来のCTOを迎えるにあたり、EMである私が直近半年で何を考え、どんな対応をしてきたかについてまとめました。 カミナシが求めるCTOとはCTOを採用したいという話が挙がった際、カミナシは具体的にどういった方をCTOとして迎えたいのか議論になった事があります。 ここでよく議論の分かれ目になるのが、実務者のTOPとしてのCTOか、経営者としてのCTOか、という2つの観点です。 当然、両方の性質を備えているのが望ましいのですが、究極的にどちらの要素しか満たさざるを得ない場合、どちらを選択すべきか関係者の認識を揃えておく必要があると思います。 結論、カミナシでは経営者としてのCTOを優先した
現状を打破できるアイデアを思いつく方法｜ふろむだ@分裂勘違い君劇場
アイデアにはたいした価値はない。 とよく言われますが、 ただ単に「思いつく」かどうかで勝負が半ば決まってしまう、というケースはけっこう多いです。 たとえば、iモードにJavaが搭載されたとき、「テトリスのように、誰もがやり慣れたシンプルな定番ゲームをiモードJavaで提供する」というアイデアで会社を作って爆速成長、2年後にはJASDAQに株式の店頭公開をしてしまった人がいます。 これ、「誰もがやり慣れたシンプルな定番ゲームを提供する」というアイデアを思いついた瞬間、勝負は半ば決まってるんです。 当時の起業家たちで、「くそ、やられた。なんでこれを思いつかなかったかな」と悔しがってた人はけっこういました。 もちろん、資本を調達し、版権交渉をし、優秀な人材を集め……という部分も難しいですし、それをやりきれるかどうかも運次第なところはありますが、そこは優秀な人が延々と努力し続ければなんとかなること
ゲームの勝敗でかんしゃくを起こす子どもにできることは大人げない大人になること｜フィンランドワークショップomena
「ずるい！！ なんで勝てないの！？」 コントローラーを床に投げつけ ソファの上で大暴れしながら 小学１年生の男の子は 目に涙を溜めながらそう言った 私は月に数日 友達の子どものお世話をしている 親の代わりに学童に迎えに行って 親が用意しておいた 夕食を温めて食べさせる その後は一緒に遊びながら 友人が帰ってくるのを待っている 最初はおもちゃや トランプで遊んでいたが 最近はニンテンドースイッチの マリオパーティーという ゲームにハマっている その家にはゲームはあるものの その子はほとんど遊んだことがないと言う 私の友人は元々 ゲームはあまりやらないし 友人のパートナーつまり 子どもの父親がゲーム好きだが 「すぐに怒るから一緒にゲームはしない」 と子どもに言っていたそうだ そこへやってきた ゲームOKの大人に 彼は毎回 「ご飯食べたらゲームしよう！」と 目を輝かせているのだ。 最初の頃は 彼
やってほしくない緑とオレンジの使い方(カラーUDの話)｜ほうじ | 少数色覚デザイナー
少数色覚者にとって黄緑とオレンジは見分けづらい組み合わせの一つです。この記事のタイトル画像とかなかなか最悪です。 WEB、アプリや印刷物などのメディアではだいぶカラーユニバーサルデザインの考え方が浸透してきており、デザイナーも多様な色覚でも読み違えないように配慮してデザインすることが当たり前になってきていると思います。 Photoshopなどのグラフィックツールには簡単に少数色覚の見え方を確認できるプレビューモードがありますし、AdobeColorを使えば無料で少数色覚の人が混同しやすい色かどうかをすぐに確かめられます。https://color.adobe.com/ja/create/color-accessibility 少数色覚が見分けづらい色の組み合わせだと「-」が表示されるしかし、工業製品の世界では少数色覚にとって見分けづらい緑とオレンジの組み合わせのLEDインジケータ（表示）を
TOEIC満点ホルダーがやっているおすすめ英語学習法（2022年版）｜Shin
今回はビジネス系ではなく、英語学習系の記事になります。実は私、20代のころにTOEIC満点を獲得しているバイリンガルでして、英語のミーティング参加やメール作成などの仕事もこなしています。 今年はNFTやメタバースといったweb3の台頭、SaaSグローバル企業との競争など英語に触れる機会も多いので、私が日本にいながら英語力を落とさないためにやっている勉強法をまとめてみました。 今年こそは英語やるぞ！と思っている人はぜひどうぞ。 前提：99％の英語学習者が誤解していること私が今まで出会った中で99％の人が知らない、けど英語ができる人はやっているポイントがあります。それは英語学習というものは「自分が発音できる英語しか理解できない」です。どういうことでしょうか？ 例えば、こちらの単語を見てください。正しく発音できますか？ month これは「月」という意味ですね。2月や12月という月です。発音は「
零細企業を買収した後に行ったDXとは呼べないDX｜reisaikigyou_ma
零細企業買収ですこんにちは。ちっちゃい企業を買収したあとの諸々を適当にTwitterで吐き出してきましたが、いったんまとめるとどうなるのかな、とおもて書きます。どうぞ。 経営的な話題は汎用性ないことをやりまくっているので具体的に行ったDX施策、効率化施策だけにとりあえず特化します というか今流行りのDXって要はIT化ですよね。IT化が実はおおくの中小零細で全然できてなかったからワードを変えてIT化やってるだけっすよね。この記事にDXというワード出てきますがその度に「いやそれIT化だから、きっしょ(笑)」と突っ込んでいただけると。 そもそもの買収経緯小さい企業を買収しようと思う→トランビとかで探す→安いの見つける→買う という流れでした。そこに熱い思いとか、前経営者の思いとかの引継ぎみたいなのはなく、非常に淡々としたトランザクションでしたので、熱量だけ高いうっすいウェブ記事でありそうな「買収
界隈がざわつくほど超進化したPMBOK第7版の解説【プロジェクトマネジメント】｜Miz Kushida
・・・ ・不確実性パフォーマンス・ドメインについて加筆しました ・テーラリングについて加筆しました ・適応課題について補足を追加しました。 はじめにPMBOKといえば、PMIが世界中のプロマネの実務家から意見を集めてプロジェクトマネジメントについて知識体系化している分厚い本、というイメージです。 いや、でした。。。以前の第6版までは（7版からはすごく薄い）。 2021年8月に第7版が発表されると（ただし、日本語版はもっと先）公式からアナウンスがありましたが、本家サイトに行ってみると英語版は既に購入できる状態でしたので早速電子版を購入し読みましたので解説したいと思います。 一応前置きしておきますと、僕はPMPホルダーではありません。外資系にいるときにPMBOKをベースとしたプロジェクトマネジメントを実施したり、国内企業ではCMMI レベル5（最高レベル）を運用したりバージョンアップ対応を経験
ガチ勢のケーブル保護チューブを導入したら、大嫌いなケーブル整理が快感に変わった話｜山下義弘／ドケットストアの人
「電気の配線がごちゃごちゃになってるよ」 そう。 そんなことは、言われなくてもわかっている。 気づいたらいつの間にか、ケーブルはお互いに絡みに絡んでごっちゃごちゃになっている。 別に絡ませたいわけでもなく、絡ませるよう努力したわけでもなく、誰かが触ったわけでもないのに・・・。 小売チェーン店で働いていたときには、「スパイラルチューブ」なるものを使って複数の配線をまとめなさいと上司から指示を受けては、最寄りの百均なんかに買いに走った。 でも、このスパイラルチューブというのが曲者で、グルグルとコードに対して巻けば確かに綺麗にまとまるのだけど、まあとにかく１ｍ巻くのにも時間がかかる。 おまけに、途中で配線を増やすとか、途中で枝分かれさせようとか、綺麗にしようとしだせば・・・もう思い出しただけでもうんざりするくらい手間がかかる。 でも、配線あるところそんな悩みはどこまでも付いてくる。 お店で家電の
エンジニア採用の方法とか、技術組織の作り方とか｜いわーく
最近ほかの会社のCEOやCTOの人たちにエンジニア採用の方法や技術組織の作り方について相談をいただくことが増えてきました。 なので、相談いただいた際に自分が参照できるよう、殴り書きレベルでここに記しておこうと思います。 エンジニアの特異性について理解する優秀な"非"エンジニア経営者は「再現性」や「予測可能性」を高く実現するのが得意なようです。高度にシステム化されていて、誰が入っても一定以上に活躍でき、人を増やせば増やすほど企業に利益をもたらす。彼ら彼女らは、そんな形の組織を作るのが得意なのです。 しかし僕たちエンジニアは知っています。 エンジニアは人によって10倍、100倍の生産性の違いを発揮するということ。また「人月」は神話であり、人数と生産量が比例することは決してなく、人を増やすことで成果が減ってしまうことすら珍しくないということ。 ここに、優秀なビジネスマン経営者こそ陥ってしまう、モ
主観と客観を切り替える鍛錬｜Miwa Kuramitsu
突然ですが、ここに一つのプロダクトがあるとします。 そのプロダクトを見つめる視線には様々な種類があります。 そのプロダクトを利用しているユーザーの視点、利用していないが存在は知っているという人の視点、それをつくるデザイナーの視点、プロダクトを運営している会社経営者の視点… もしあなたがデザイナーであれば、デザイナーの視点だけが唯一自分で体感できる「主観」で、それ以外はすべて「客観」となります。 主観と客観のスイッチング プロダクトデザイナーはユーザーの期待通りに正しく動くしくみを設計し、「このプロダクトを利用した時に、ユーザーの生活はどう変化していくのだろうか？」と問いを立てながらアウトプットを評価していきます。 自らの考える理想像をデザインしながら、一方でそれに触れるユーザーの様子を想像する…プロダクトデザイナーは主観と客観を電気のスイッチのように瞬時に切り替えることに長けた人が多いイメ
スクラムとアジャイル開発の本を12冊一気に読んでみた！その中から初心者、中級者、上級者向けのおすすめを紹介｜Dentsu Digital Tech Blog
スクラムとアジャイル開発の本を12冊一気に読んでみた！その中から初心者、中級者、上級者向けのおすすめを紹介 こんにちは電通デジタル開発部エンジニアのリチャードです。弊社で開発している社内プロダクトEASIではスクラム開発を採用しており、開発部内には認定スクラムマスターも在籍しています。一方で私個人はこれまでスクラム開発を経験してはいたものの、断片的な知識と経験で乗り切っていた部分が強く、改めてスクラムやアジャイル開発の基本を学び直そうと思い立ち、12冊の本を一気読みしました。ちょうど数ヶ月前に電通デジタルへと転職したばかりだったので、よい機会だったと思います。 今回読んだ本の一覧はこちらです！過去に読んで改めて今回読み直した本もあるため、冊数は多くなっています。 初心者向け 1. いちばんやさしいアジャイル開発の教本 2. SCRUM BOOT CAMP THE BOOK 中級者向け 3.
書評 『Agile Testing Condensed Japanese Edition』 〜アジャイルテストの一冊目として最適〜｜hgsgtk
Janet GregoryとLisa Crispinによる2019年9月発行の書籍『Agile Testing Condensed』の日本語翻訳版です。アジャイルにおいてどのような考えでテストを行うべきなのか簡潔に書かれています！ Janet氏とLisa氏といえばAgile Testing DaysのYouTubeチャネルでも頻繁に登場しAgile Testingについてわかりやすい解説をしてくださってる 本書は訳者まえがきにあるが、著者たちの3冊の本（『Agile Testing: A Practical Guide for Testers and Agile Teams』、『More Agile Testing: Learning Journeys for the Whole Team』そして『Agile Testing Condensed: A Brief Introduction』
【サービス終了・お焚き上げ会場】slideship は何故うまくいかなかったのか｜Takahiro Ikeuchi
みなさんこんにちは。一段と寒くなって参りましたがいかがお過ごしでしょうか。インフルエンザの予防接種を受けに来たら病院が休診日でした。その敗戦の帰りにドトールで記事を仕上げております、池内です。おこしやす。 2015年に設立した法人を2019年に閉じることになったいきさつは廃業エントリで書いたとおりですが ↓ 今回は起業中の2つ目のプロダクトであった slideship.com について振り返り・お焚き上げ申しあげたいと思います。 slideship.com は、2020年12月31日をもって全サービスを終了し、サービスクローズすることになりました。slideship.com はなぜうまくいかなかったのか。 slideship.com とはslideship.com とは、Markdown 形式でプレゼンテーション・スライドの作成が行え、オンライン上でスライドの公開までワンストップで行えるク
CTO不在の企業で開発組織を作っていくために大事なこと｜BTO
おはこんばんちは!!尾藤 a.k.a. BTO です。 これは CTOA Advent Calendar 2020 の5日目の記事です。 今までウノウとUUUMの2社のスタートアップでCTOを足掛け10年近くやってきました。経歴柄、CTOのいない企業から開発組織の作り方の相談を受けることが多いですが、やはりCTOが不在で開発組織を作っていくのは非常に困難です。とはいえ、転職市場に都合よく即戦力になりうるCTO人材が簡単に見つかるのも稀です。そこでCTOが不在の中で開発組織を作っていくために大事なことをまとめてみました。 開発組織作りで大事なのは採用ではなく環境作り開発組織作りで大事なことはいろいろありますが、最も大事なのは採用と環境の2つではないかと思います。環境が良くなければ優秀なエンジニアは採用できないし、優秀なエンジニアに来てもらえなければ良い開発環境を作ることができません。いわゆる
Markdown で技術書が書ける｜abechanta
ソフトウェアに関する記事やコラムを書くなら、Markdown 記法はとても良い選択です。見た目の統一感があり、覚えやすく、軽量です。 この「Markdown での書きやすさ」を物理書籍や電子書籍の執筆にも応用できたらな、、、 "W3C Paged Media Viewer" はそれを実現する、OSS の Visual Studio Code のエクステンションです。エクステンションを入れただけの超シンプルな環境を使って、手間いらずでサクッと技術書を執筆することができます。 以下に示すとおり導入は簡単です。 1. VS Code を起動します 2. CTRL + SHIFT + X とタイプして Extensions ビューを表⽰します 3. 検索ボックスに paged media と⼊⼒し、 W3C Paged Media Viewer あるいは abechanta.vscode-ext-
【図解入門】シンプルな図の作り方｜櫻田潤🎨インフォグラフィック・エディター｜note
3年前に、図解の基本をまとめた本『図で考える。シンプルになる。』を書きました。その内容から、エッセンスを抽出したのが本noteになります。 （１）「幕の内図解」と「イチオシ図解」 図には、大きく分けて、2つのアプローチがあります。 ひとつは、幕の内弁当のように、いろんな要素を盛り込んだ図で、もうひとつが、唐揚げ弁当のように、イチオシのおかずにフォーカスした図です。 たとえば、桃太郎の話を「幕の内図解」のアプローチでまとめてみたのが、つぎの図です。 登場人物とエピソードをフラットに扱って、網羅的に盛り込んでいます。 この図を使って、人に説明しようとすると、「まず、お婆さんですが……」「つづいて、お爺さんですが……」といった具合に、「お婆さん」「お爺さん」「桃太郎」それぞれの視点に切り替えが必要になり、話す方も話しづらければ、聞く方もまどろっこしく感じてしまいます。 相手がじっくり聞く耳を持っ
失敗したエンジニア組織施策としくじりの反省｜nottegra@在宅勤務
前回、成功したエンジニア組織の施策について書きましたが、今回は失敗編です。失敗のほうが多いのでどうしても文量が多いのですがご勘弁下さい。 説明用に前職の関係記事がガンガン出てきますが、貶めたり咎める意図は全くありません。あくまで僕が責任持って実施した施策で失敗したことについてのノウハウ共有と反省についての記事です。 組織施策プレゼン大会 ※元記事がお亡くなりになっているのでWayback Machineより [概要] 組織施策についてチームごとにプレゼン。プレゼン毎に担当役員＋組織責任者(僕)が点数評価。点数が一定以上の場合施策実行をその場で採択。 内容は、課題提起→施策内容→実行体制→スケジュール→予算→まとめ。 [導入背景] エンジニア組織の人数が増えて組織硬直が進んでいたこと、全員の目線を合わせる機会があまり無かったことから、メンバーの不満が見えないレベルでたまり続けていました。 メ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
