やるべきことの見つけ方とそのときに一番大事なもの - ihara2525's blog
僕が働いているクックパッドでは、何かに取り組むときに、それは「三つの輪」が重なっているのか、という話をよくします。 「三つの輪」は、「やりたい」「得意」「やるべき」の輪で、簡単ですが以下がその図です。 自分が心から情熱を持って取り組めること（やりたい）、かつ、一番になれること（得意）、かつ、会社に貢献できること（やるべき）、それら三つが重なるところを見つけて、そこに集中して取り組もう、という考え方です。 なお、「やるべき」は、クックパッドであれば「毎日の料理を楽しみにする」ですし、各々が解決したい問題が入るものだと思います。 で、これらをもう少し具体的なものに例えてみると、「やりたい」は「燃料」、「得意」は「エンジン」、「やるべき」は「目的地」です。 いくら燃料があっても、エンジンが貧弱ならたいしたスピードや馬力は出ませんし、 いくらエンジンが素晴らしくても、燃料がなければ動きませんし、
「えっと」「あのー」が多い人は思考のメモリ不足かも？会話のプロに聞いた"つなぎ言葉"の改善方法 | スタッフブログ | マイネ王
ライター: しまだあや エッセイを書く作家活動を中心に、企画やMCなど。代表作品に「今週末の日曜日、ユニクロで白T買って泣く」、「7日後に死ぬカニ」、「小学1年生ぶりに、父の前で真っ裸になった話」、「日常を3日間タイムループさせたら、74歳に娘ができた」。大阪生まれ、奈良暮らし。家の94%を開放するという変わった暮らし方をしている。 突然ですが、みなさんは、お喋りは得意ですか？ YoutubeやPodcastなど、誰でもがネットでお喋りを配信できる時代になりました。私も最近、Podcastでラジオ番組づくりにチャレンジしてるんですが、自分の収録を聞いて、気付いたことがありまして。 私、話の途中に「なんか」「あの」「えっと」って、めっちゃ言ってるんですよ。 ちょっとくらいなら気にならないけど、連続すると、すんごい焦ってる人みたいだし、編集しにくい。なんとかしたいなあ。 この「あの」「えっと」
アウトプットと主体性 - ぱすたけ日記
今年立ち上げた企画・イベントの振り返り3連発 - Helpfeel Developers' Blog とかを書いているように最近は会社の特に技術的なアウトプットの促進にある程度の力を割いている。これは僕自身がカンファレンスなどに関わっているのと同様に、そういった場を作っていくことで社のアウトプットが増えるのは良いことだと思っているのと、且つそういう仕組みを考えたり実行するのが個人的な興味や趣味の対象であるというのもある。例えば、それぞれの大きい流れだったり演出だったり、裏側の配信の仕組みだったりを考えるのが好きでそれがパチっとハマったり上手くいったときは嬉しい。そういう癖があるので、アウトプットを促進するためだったら、Nota Tech Conf 2022 Springの"全員登壇"を支えた技術 - Helpfeel Developers' Blogのような支援手段を考えることもめちゃくち
機能は追加すればいいというものではない
みなさん、新機能は好きですか。ソフトウェアへの機能追加は、ユーザ目線で単純に考えると「できることが増えていくのでよい」という響きを帯びています。しかし実際は、長く使われるソフトウェアであればあるほど、新機能を追加すべきかどうかはものすごく気を使って決めるものであって、やればいいというものではないのです。この記事の目的は、新機能の追加には細心の注意が必要だとわかってもらうことです。おもな対象読者はソフトウェアを長期間メンテしたことがないかたがたです。 みなさんが使っているOSSに新機能を追加するPRを送った場合を考えてみましょう。ここで重要なのは、PRが送られてきたメンテナやコミッタといわれるコア開発者たちの立場になって考えることです。彼らの役割は、自分たちを含むユーザがそのソフトウェアを使い続けられるようにメンテし続けることです。このメンテのコストに注目すると、機能追加は基本的にコストを上
ストーリー性のあるプレゼン - id:onk のはてなブログ
発表資料作り、全体的な流れは 1 週間ぐらいかけて構想して、半日使って 15,000 字ほど書いて (コード片含む)、半日使ってスライドに起こす(結果として 6000 字ぐらい使う)、って感じですね。貯めた文字列を組み合わせている最中に構想とは別のストーリーが降ってくることも多い。— Takafumi ONAKA (@onk) July 3, 2018 このツイートの「文字を組み合わせる」のところについて、もうちょっと掘り下げてみる。*1 この記事は はてなエンジニア Advent Calendar 2022 の1月2日の記事です。昨日は id:stefafafan で 『UNIXという考え方―その設計思想と哲学』を読んだ - stefafafan の fa は3つです でした。 3 つのポイント 知っていること 7 割、聞いたことがあること 2 割、知らないこと 1 割 引用しやすいワー
プログラムの複雑さ・表面積・グラフの構造 - Object.create(null)
特に何かしらの出典はありません. プログラムの複雑さに対する大局的で直感的な指標として, 表面積とグラフの構造というのを個人的に意識しているという話. いわゆる code smell をどう嗅ぎつけているか. 表面積 プログラムは最も単純には 1 つの入力チャンネル (引数) と 1 つの出力チャンネル (戻り値) でモデル化できます. 要するに関数ということですが, 関数型プログラミングに限らず大抵は似たような考え方ができます. graph LR yield[ ] -- 引数 --> program[プログラム] -- 戻り値 --> return[ ] 一方で現実世界で価値のあるプログラムとなるためには引数と戻り値だけでは不十分で, 実際にはその他の入出力チャンネルも必要になってきます. 例えば, 可変な変数の読み書き 環境変数の読み取り ユーザー入力の読み取り 画面への出力 ファイル
「驚く」ことが体験ネットワークを構築する｜shinshinohara
「勉強できる子」は一度説明しただけで理解し、覚えてしまう。「勉強の苦手な子」は一度説明しただけでは理解できず、覚えることもできない。なんなら同じ説明を何度もしても理解できない。この現象をもって「頭が悪い」と決めつけてしまう「勉強のできる人」は多い。しかし私は見解が異なる。 観察してると「勉強のできる子」は、その言葉を聞く前にすでに知識のネットワークが準備されている。電流の話を聞く前に、モーターや電球の仕組みだとかに興味を持ち、すでにある体験ネットワーク、知識ネットワークの結節点の一つにその名称をあてはめるだけ。だからすんなり覚えてしまう。 ところが「勉強の苦手な子」は、体験ネットワークがすっぽり抜けてしまっていることが多い。花をマジマジ見たことがないし、電気のオモチャを分解したりしたことがない。見たことも聞いたこともないことを突然聞かされても面食らうだけだし、何度説明されても体験と結びつか
書評が書けない
本をうなずきながら読む 読み終わってみたが、とくに書くことがない おもむろに書き出してみてもダイジェストにしかならない １＋１＝２という記載に疑問のもちようがない イスラムはこういう教え、キリスト教はこういう教え、仏教はこういう教え そういうもんなんだから読んで書けと言われてもまとめるだけになってしまう そういえば、大学のレポートや卒論も参考文献のダイジェストを「思われる」、「考えられる」で締めて考えたフリをしているだけだった 人気の書評ブログの言葉づかいをまねてみても上手に書けない 「書き続ければ上手くなる」。みんなこういう。文章が上手いやつに限ってこういうことをいう けれど、上手いやつは最初からキラリと光るものをもってる。問題意識というか、物事を力強く疑うことできる体力というか、明らかに他の人とは違う原石をもってる 昔から自分にはそういうものがなかった。読書感想文も目も当てられないほど
ヘタクソなコードを書いてもいい - 覚書
プログラミング言語のお作法から外れたコードやメンテ性が悪いコードを書くのはダメとよくいわれます。わたしは学生の頃、そういう意見を過剰に気にしていました。コードを書くことそのものに慣れていないのに綺麗に書こうとして手が動かず、動かないがゆえにコーディングの練習が進まない、という悪循環になっていました。そうすると何もアウトプットしないまま知識だけが増えていって、自分がこれくらいできそうというイメージと実際のプログラミング能力とのギャップで苦しみました。 この意識が薄れたのは、あるときものすごく手が早い人のコードを偶然見たときでした。たしかにちゃんと動くものができているんですが、そのコードの中身は当時の私の基準からいって*1おぞましいほど汚いものでした。そこで「これはわたしが書けば100倍くらい綺麗なコードを書けるんでは…」と一瞬思ったんですが、その後すぐに「あ、自分は知識はあるけど練習してない
プログラマにも読んでほしい「QC検定にも役立つ！QCべからず集」OSEK(71) - Qiita
QCの基本はデータ解析。データ解析ばかりしていて、仕事に役立てない人をいっぱいみてきた。 ある日、ある人の言葉から、筋書きを考えていたら、それ自分かもってなった。 データサイエンティストの気づき『勉強だけして仕事に役立てない人。大嫌い』それ自分かもってなった。 https://qiita.com/kaizen_nagoya/items/d85830d58d8dd7f71d07 OSEK OSを利用するにあたって、設計にあたっての証明と、HAZOPによる安全分析と、成果に対する品質測定を行ってきた。 QC検定にも役立つ！ QCべからず集 すごく内容がよい。 プログラマの方にも読んで欲しいと思い、筆をとりました。 はじめに(introduction) 統計、確率を学べば、因果関係が大事なのではなく、時系列の推移が大事だとわかる。 統計力学、量子力学、遺伝子工学、疫学などの分野で常識になると嬉し
情報ではなく経験をアウトプットすること - 余白
調べれば大抵の情報は誰でも手に入る今日このごろ。特に技術的な情報はオープンソースで一次情報へのアクセスは容易になった。 それと同時に繰り返し言われるアウトプットの重要性。 しかし、ブログやLTなどでアウトプットしても、「もっと質のいい情報があるのに自分がアウトプットする必要があるのか」「逆にノイズになるだけじゃないか」というような考えになってしまう人もいるのではないか。 そんな架空の声にお応えして、それでもなおあえて、一次情報ではない「あなたのアウトプット」の重要性を伝えてみようと思う。 実際にやる人は多くない 定量的なデータがあるわけではないが、直感的に共感してもらえるだろう。 ある技術や手法が話題になったとして、それを情報として知っている人はこの時代いくらでもいる。 だが、それを実際にその手でやったことがあるというだけでかなり群衆からは抜きん出た経験を持つことになる。 ましてやそれをや
質の高い技術文書を書く方法 - As a Futurist...
大学や大学院で論文の書き方を鍛え上げた人たちには遠く遠く及ばないが、僕の様なはぐれもの1でも最近は Amazon 社内で文書の質が高いと評価してもらえるまでにはなった。Software Engineer として、コードでのアウトプットはもちろん大事だけど、文書のアウトプット(およびそれによって得られた実際のアウトプット)は同じだけ重要である2。今回は自分が最近どういうところに気をつけて技術文書を書いているのか、ということについて数年後の自分が忘れてないことを確かめられる様にまとめておく。 そもそも文書とは？ 英語だと document。ここで指す(技術)文書とは、人間が読む文体で書かれた技術に関連する情報、といったものだ。具体的に言うと以下の様なものを想定している: 新しいプロジェクトの骨子を説明する資料 会議の叩き台となる 1 枚ペラ 本番環境に変更を加えるにあたっての包括的な情報や具体
『デザイン思考』という言葉にデザイナーとして改めて向き合って考えた結果得られたもの - Pepabo Tech Portal
こんにちは、デザイン部デザイン戦略チームでプリンシパルデザイナーをしている咲 @satosio です。 2020年4月にGMOインターネットグループの新卒入社パートナーを対象に「デザイン思考について」約1時間の講義を行いました。この記事ではそこで使用したスライドをもとに「デザイナーにとってデザイン思考とはなにか」を説明していきます。 「デザイン思考」はデザイナーに限った話ではないのですが、「デザイン思考（笑）」というように、言葉自体をなんとなく毛嫌いしてしまっているデザイナーに「デザイン思考」と呼ばれているものの正体はなにかを説明することが本記事の目的です。 結論 概要 共感とはSympathyではなくEmpathy 共感からインサイトを得ることで自分ごと化する デザインとは意思決定の積み重ね 意思決定は「仮説推論」に基づいている デザインの思考法とはフレーミングを用いた仮説推論 デザイン
エンジニアのスキルと抽象度｜Jumbo
この記事を読む前に、「みんなちがってみんないい」と3回唱えよ スキル相談で考えること1on1や採用・育成の中で「新しく〇〇を勉強しようと思っているんですよねー、どうですかね？」かみたいな相談をされることが多く、基本的には「イイじゃん、Youやっちゃいなよ」の精神なのですが、なんのために？そのスキルはどこまで伸ばすのか？という話はなるべくするようにしています。 その時に期待されている役割や今のスキルを分析するために、「解決すべき課題の抽象度」「スキルの関連性」という話をよくするので共有しようと思います。 我々の仕事我々は「課題（タスク）」を解決することでお金をもらっています。とくにエンジニアやデザイナーは"課題解決に特化する仕事"だと考えています。この課題には以下のようなものがあります。 解決すべき課題 ・SQLのパフォーマンス問題 ・iOSアプリユーザーさんの使い勝手が悪い ・組織の人数不
現場の技術を知らずに研究するコンプレックスについて - 人間とウェブの未来
僕は大学時代に研究を続けたかったのだけど、当時アルバイトとして働いていたレンタルサーバー会社の中の取り組みがとても高度に思えて、こういう状況を知らずに研究を続けるのは怖いと思って、大学院に行かずに就職した。そして、3年後になんとか大学院に再び入り直すことができたし、博士課程での研究では随分と会社で学んだ運用技術をネタにした研究をすることができた。 これまで、僕は運用技術をネタに研究をやってきたのだが、研究に専念すればするほど、その経過時間だけ新たな運用技術の時代背景や細部も変化していき、それを個人としてうまくキャッチアップして研究につなげていくことが非常に困難であることに数年前から気づき始めた。でも、自分自身はそれを素直に受け入れることができず、どうにか自分の現場の経験があることを武器に研究をすることにこだわっていた。しかし、それも誤魔化しきれない程に、少しずつ少しずつ限界が来ていたし、自
なぜ作ったゲームが面白くならないのか？基礎にして奥義「フロー理論」｜かえるD
そろそろ、ゲームデザインの話もしていこうかと思う。今回は、ゲームが面白いとはそもそも何なのか？そもそもゲームとはなんなのかを紐解き、そこからどうすれば面白くなるのかを書いていこうと思う。 そして、最初に本記事の結論を書いておく。 ・ゲームとは学習を嗜好品化したものである ・人が学習から面白いと感じるには条件がある＝フロー理論この二つが、本記事の結論である。面白いと思ったら、この先を読み進めていただければ幸いだ。 そもそもとして、今回の記事をnoteに書こうと思った理由の一つとして、毎年新卒に向けて同じような話をするのだけれど、ずっと張り付いて教えられるわけでもないし、必要になったタイミングで情報を提供しないと、なかなか身に付かないので、これ参考にすると良いよというような似たようなまとまったリファレンスがほしかったのだ。でもそのようなリファレンスは存在しないので自分で書こうと思った次第だ。
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
