どのようにエンジニアの目標設定を行うか - $shibayu36->blog;
以前 ゴールを決め目標を決める・解決案ではなく質問する - コーチングの学習で学んだこと - $shibayu36->blog; で、「ゴールを決め、現在位置とのギャップを考え、目標を決める」と良いということをまとめた。イメージとしては以下の図の通り。 しかし、前回の記事だと具体的にどのようにエンジニアの目標設定を行うかイメージが湧かない。そこで、もう少し具体的に最近どのようにやっていたかを書いてみたいと思う。 僕がメンティーと目標設定を行うときは、以下のフローを辿っている。 なんでも良いのでゴールのイメージを明確にする 現在の自分とゴールのイメージのギャップを考える ギャップを埋める目標を考え、アクションを定める ちなみに今回は、チームの成果達成のために個人の目標を決めるのではなく、エンジニアのスキル向上の目標を立てるという前提で書いていく。 なんでも良いのでゴールのイメージを明確にする
医療情報の信頼性問題から、情報の受け手が心がけることを考える - $shibayu36->blog;
bylines.news.yahoo.co.jp 上の記事が素晴らしいなーと思ったので、関連して以前に医者に聞いた話とその話について自分が思ったことを書いておきたい。 最近少し重めの病気にかかったこともあり、医療情報をインターネットを通じて調べるということが昔より多くなった。そのため、いろんな記事を見ていたのだが、そうしているとインターネット上における医療の情報や健康に関する情報は信頼性の低いものが非常に多いということが分かった。無意味に恐怖心を煽るような記事や、逆に無責任に症状について問題ないと書いている記事、他にも全く根拠の無い治療法について書かれている記事など、素人による記事が非常に多い。このような記事は病人にとって無益なだけでなく、暗い気持ちにさせたり他人に変なレッテルを貼られる原因となったりと有害である。 このように医療情報や健康に関する情報は信頼性が低いことが多いのだが、それで
問題 => 原因 => 解決方法という順で物事を考える - $shibayu36->blog;
今日LIGのブログを読んで、直近自分の中で課題に思っていることと近いことがそのまま書かれていたので、非常に参考になった。そこで自分の思考を整理するためにも、以下の記事を読んでそのあたりについて思うところを書いてみる。 プロジェクトでトラブルが発生したときにWebディレクターがとるべき3つの手順 | 株式会社LIG 自分自身の課題 最近の自分自身の課題としては、「問題が発生したときに、すぐに解決手法を考えてしまう」というものだった。それには全く自分自身では気づいてなかったのだけど、最近はあるところで 問題を見つけた時、いちどその原因はなにかを考えたほうが良い 問題 = 原因ではない、そこを意識した方がいい との指摘を受けて、確かに自分は問題だと思ったときに、それが本質的な問題か別の問題なのではないかと考えてはいたと思う一方、問題の原因とは何かについては深く考えてなかったということに気づいた。
「イシューからはじめよ」を読んだ - $shibayu36->blog;
最近やることがたくさんあってどうしたら良いか分からなかったので、同僚の薦めもあって「イシューからはじめよ」を読んだ。結構面白かった。 イシューからはじめよ──知的生産の「シンプルな本質」 作者:安宅和人英治出版Amazon この本には、やるべきことがたくさんあった時に、タスクをやる効率をどんどん上げていくという方向にまず走るのではなく、その中で重要なイシューを見極めてそれを重点的に取り組むべきである、というようなことが書かれていた。とにかくやるのではなく、まずやることを見極めよみたいな感じ。確かに忙しい時はとにかくやるとなりがちだけど、とにかくやっててもあんまり成果が上がらないことがあるので、まず見極めないといけないと思った。 この本の中で 悩まずに考える 「これは何に答えを出すものなのか」を明確にしてから問題に取り組む 一次情報を死守 という言葉が印象に残ったので、それについて書く。 悩
実践に繋げるように勉強する - $shibayu36->blog;
遅延評価勉強法だと得られなかったもの - As a Futurist... 漢(オトコ)のコンピュータ道: ヒゲモジャのギークが提案する技術習得戦略 を読んで、なんとなく気分が高まったので、自分の学習のことについて書いてみる。 以下の様なことを書いているつもり。 勉強は実践につなげると知識が定着すると思っている 実践課題を探すのではなくて、実践の目処のあるものを勉強する 一番簡単な実践課題として、自分の言葉でまとめ直すということをしている 実践に繋げる 僕は勉強する時は、いろいろ本を読んだり、情報を調べたりして、まず知識をつけようとすることが多い。ただし、それだけだとだめで、実践しないと知識が定着せず、どんどん忘れていき、結局意味ないということになる。実践大事。 大事なのはわかってるんだけど、実践するのは意外と難しい。本に練習問題あったりすることもあるけどあんまり面白くないし、良い実践課題
ディズニーとかの映画で英語の勉強してる - $shibayu36->blog;
最近英語勉強してるけど、とにかく勉強したくない。とにかく勉強したくないから、なんか楽しみながら自然に身につけたい。 どうしたらいいかなーと考えて、いろいろ試してみた。リスニングの勉強では結構有名なのはフレンズを見るって言うやつ。 英語耳をこれで作った？留学先で出会った友達お勧めの効果抜群リスニング勉強法 | ボキャブラリー | TOEIC Lab : TOEICを短期間で高得点を目指す人のためのサイト 海外ドラマ「フレンズ」のディクテーションとフレーズの暗記を1ヶ月続ける方法 - higepon blog これは試してみたんだけど残念ながら一瞬で挫折した。なんか僕自身があんまりコメディ好きじゃなくてフレンズ自体を楽しめなかったというのと、なんか普通にそこそこ英語速かったからあんまり理解できなかった。英語速いの頑張って聞こうとすると勉強っぽくなってくる。 いろいろ試した結果、ディズニーとかピ
マンガでわかる統計学で、統計を学び直す - $shibayu36->blog;
最近Webサービス開発する際に統計学がある程度使えそうと思って、勉強しようと思っている。それで最近買ったのが以下の本。 統計学の基礎―カラーイメージで学ぶ 作者:市原 清志,佐藤 正一日本教育研究センターAmazon ただ、買ったはいいものの、自分には少し難しく、あーまた統計の勉強挫折しそうだなー*1と感じていた。それでここでまた挫折するのは嫌だなーと思って、少しレベルを落として、《Gunosy》開発チームが厳選、WEB業界人が読むべき“統計学”の必読書ベスト５ | キャリアハックにも紹介されていた「マンガでわかる統計学」を買った。 マンガでわかる統計学 作者:信, 高橋,トレンドプロオーム社Amazon この本が統計学をこれまで避け続けてきた自分にとって非常に良かった。 2時間くらいでさっと読み終わることが出来る 統計学を学ぶ上でのはじめの一歩の部分がよくまとまっている データの種類とか
Webサービスの実践としてのブログ - $shibayu36->blog;
仕事でWebサービスを作ったりしていると、PVを増やすにはどういうコンテンツを作っていけばいいかとか、analyticsでどうやってある事柄を調査するかとか、広告のクリック率をどうやったら伸ばせるかとか、そういう知識が必要になることがある。そのたびにいろいろ勉強したりするのだけれど、理論だけ見ていてもいまいち身につかない。じゃあ仕事で扱えるWebサービスを見ようとすると、数字が大きすぎたり、いろいろなところから流入があってどこから見ればいいかわからない。 それで、もうちょっと小さめなデータないかなと思っていたところ、自分のブログで書き続けてある程度アクセス数が稼げれば、それを使って実験・実践を行い、勉強できるなーと思い始めた。 実験 最近はアクセス数がそれなりに増えてきたので、少しずつ実験してみたりしている。例えば最近だと以下の様な実験をしてみた。 twitterでバズった時に、アクセスを
株式会社はてなに入社しました - $shibayu36->blog;
これまではずっとアルバイトでしたが、この四月から株式会社はてなに社員として入社しました。最初の一週間の様子と、これから何をやりたいかについて少しだけ書きます。 一週間 先週は3日間研修があって、その後チームに配属されて仕事を始めました。 研修では、はてなの中で各開発チームがどのようなことをしているかについてや、営業やサポートなどがどのような仕事をしているかについて、お話を伺いました。これまで2年間くらいアルバイトをやってきたとはいえ、自分が仕事をしていた以外のチームのことはそこまで詳しく知らなかったので、いろいろな話を聞けて非常に楽しかったです。 配属はもともといたチームで変わりはありませんでしたが、これからもはてなの基盤となる部分(プラットフォームや課金など)をやっていくことになると思います。 実際一週間位仕事をして、まず感じたのは「一週間疲れたー」ということでした。アルバイトからそのま
$shibayu36->blog;
以前同僚から、いくつかのプロジェクトやタスクを持っているときにどう進めると良いかという質問を受けた。僕はその時、価値が出るポイントまで一気に進めてから次のタスクに取り組むようにしていると答えた。この話についてブログに言語化してみる。 良くない進め方の一例 たとえばプロジェクトA（自分の担当分工数10日）、プロジェクトB（自分の担当分工数20日）で、合計30日分のタスクを持っているとする。この時良くない進め方は、両方ともを完全に並列に少しずつ行って、30日後に終わるということだ。1 このやり方だと30日後にならないとプロジェクトAもBも結果が出ない。もしプロジェクトAのみに集中して終わらせれば少なくともプロジェクトAの結果は10日後に出るのに関わらずである。 このやり方がまずいのは当たり前に見えるのだが、気をつけないとやってしまいがちである。なぜなら少しずつ進めれば、他の関係メンバーに「自分
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
