不確実な状況に耐える力を学ぶ - 「ネガティブ・ケイパビリティ」を読んだ - $shibayu36->blog;
自分は問題解決は得意な方だと思っている。しかし逆に不確実な状況・不安な状況・課題がある状況をそのままにして耐える力をもっと付けたいなと思っている。そこで最近目にした「どうにも答えの出ない、どうにも対処しようのない事態に耐える能力」であるネガティブ・ケイパビリティについて学ぶため本を読んでみた。 ネガティブ・ケイパビリティ 答えの出ない事態に耐える力 (朝日選書) 作者:帚木 蓬生朝日新聞出版Amazon 正直、この本は歴史的な話とか雑談も多く、少し頭に入りにくかったが、一方で示唆のあることを学べた。例えば どうにも対処が難しい課題を見つけた時に、拙速に解決策を見出すのではなく、興味を抱いてその宙吊りの状態を耐えると良い。それによって深い理解に行き着く 問題解決があまりに強調されると、まず問題設定の時に、問題そのものを平易化してしまう傾向が生まれる。この時、複雑さを削ぎ落としているので、現実
ミーティングが効果的になるように、自分がよく使うミーティングテンプレート - $shibayu36->blog;
何かを進めようと思ってミーティングをとりあえず入れるというのをしてしまうことも多いが、適当にやるとミーティングが終わったが何も進んでいないとなりがちだ。そうならないように、自分用のミーティングテンプレートを作っているので、ブログに書いてみる。 ミーティングの用意で心がけること テンプレートの前に、自分がミーティングの用意で心がけることをリストアップする。ミーティングは「何かを先に進める」必要があると考えるため、次のことを心がけている。 何はともあれ「目的」を最初に決める。「〇〇を決める会議」なのか、「〇〇のアイデア出しの会議」なのか、「〇〇の認識合わせの会議」なのか 目的に合った「会議のゴール・完了条件」を決める。ゴールに到達したら成功、到達していなかったら失敗と振り返ることもできる。また、参加者がゴールに集中することで、横道に逸れづらいという効果もある 会の前に参加者にやってほしい「事前
株式会社はてなを退職しました - $shibayu36->blog;
2021年8月13日の本日が最終出社日でした。しばらく休暇を取り、10月から別の会社でエンジニアをする予定です。 はてなには2010年4月にアルバイトとして入社し、2012年4月からは社員として入社したので、アルバイト2年、社員9年4ヶ月と非常に長い間所属した。仕事の中で、周囲の人の優秀さに圧倒されながら学習とアウトプットをし続け、またいろんなチームや職種を経験させてもらえたおかげで、自分自身がかなり成長できた。はてなに入社できたことで、エンジニア経験がほぼないところから大きく成長できたため、誇張なく人生が変わったと思う。 はてなで経験できたこと 本当に色々経験できたのだが、自分の中で本当に良い仕事ができたなーと思ったことはこんな感じ。 世界規模で動く通知システム はてなブログMediaの立ち上げ カクヨムの立ち上げ 魔法のiらんどのリプレース ブログチームでのチーム改善や、Mackere
改善提案の議論をテキストで非同期に行う - リモートワークに合わせた提案方法を探る - $shibayu36->blog;
最近はリモートワークが主体で、みんなで集まっての同期的コミュニケーションがやりづらくなり、他の人の非言語情報を受け取ることも困難になった。その結果として、自分がチームで改善提案をした時に、周りの人からコメントを受け取る、提案に対する温度感を探るということが難しくなった。 改善提案にこのような課題があったので、リモートワークに合わせた方法を探り、まず改善提案の議論をテキストで非同期に行うというやり方を行ったので紹介する。その過程で自分が作った提案のテンプレートも共有するので、参考にしてもらえると嬉しい。 課題: 現在の働き方でも改善提案に対するフィードバックをもらいやすくしたい もう一度課題をまとめる。 自分がチームの改善提案をした時は、チーム内の意見や反応を見ながら、より改善提案をブラッシュアップして実施したいと考えている。つまり開発フローなどチームの改善提案でもコードレビューと同様、コメ
読書のやり方を変えてみたら知識の吸収速度・引き出し速度が上がった話 - $shibayu36->blog;
最近以下のような記事や本を読み読書法を変えてみたところ、知識の吸収速度・引き出し速度が上がったと感じるので紹介。 kentarokuribayashi.com 知的戦闘力を高める 独学の技法 作者:山口周ダイヤモンド社Amazon やり方 以下のような流れで読書している。 学びたいと思った知識が書いてありそうな本を2~5冊選ぶ 1冊ずつざっくり読みながら、面白かった部分・気になった部分はKindleで黄色にハイライトしておく 全冊読み終わったら、ハイライトした部分だけ眺めて、やっぱり面白いと思ったところは赤のハイライトを付け直す 赤のハイライトを眺めて、読書ノートに転記する 特に面白い部分については、自分の知見まとめノートにカテゴリごとに整理する 学びたいと思った知識が書いてありそうな本を2~5冊選ぶ 自分の中で学びたいテーマがあって本を読むはずなので、そのテーマについて書いてありそうな本
締め切りが厳しいプロジェクトで、プロジェクト初期にまずやっておきたいこと - $shibayu36->blog;
これまで僕は締切がかなり厳しいプロジェクトを数回経験してきた。その経験から、締切が厳しいという特性を持ったプロジェクトの初期にまずこれだけはやったほうが良いということがいくつか見つかったので、今回はそれらを紹介していこうと思う。 前提となるプロジェクト 今回紹介する方法は、次のような特性を持ったプロジェクトを前提とする。 細かい仕様は決まっていないが、作るものの要件はある程度明確である アジャイルの定義におけるスコープ・コスト・品質・スケジュールの中で、スケジュールを特に優先したい(スケジュールを変えられないなど) 数ヶ月以上のプロジェクトである 短いスパンでリリースしてユーザーの様子を見てその後のプロダクトバックログの優先度を変えるような性質のプロジェクトでは、別のやり方を取る必要があると思う。そこは注意してほしい。 プロジェクト初期にやっておきたいことは何か 上記のようなプロジェクトの
レビュータイムや定期的なissueチェックのためにGithubのissueを検索してSlackに投稿するCLIツールを作った - $shibayu36->blog;
https://github.com/shibayu36/notify-issues-to-slack というツールを作ったので紹介です。 背景 はてな社内では各チームでレビュータイムという時間を設けていることが多い。その時間にチーム内のissueやPull Requestを全部見るという心がけをしている。レビュータイムについては昔に以下のような記事を書いた。 blog.shibayu36.org 一方レビュータイムを導入したとしても、レビュー依頼中のissueやPull Request一覧がSlackに流れてこないと、レビューやっていくぞという気持ちが高まらないことがある。そのためレビュータイムになったらレビュー依頼中のissueをSlackに流すツールを各チームでそれぞれ作っていた。 最近自分もまた同じようなツールを作ろうとしてしまった。しかし、みんな同じツールを作っているのは良くない
組織設計を体系的に学ぶ - 「組織デザイン」を読んだ - $shibayu36->blog;
自分は組織での行動やマネジメントの分野に興味があるのだけど、その一貫でそもそも組織とはどう設計していくのかの基礎的な知識を学びたいと思ったので、評価の高い「組織デザイン」を読んだ。とにかく面白く、読んで非常に良かった。学ぶことが多すぎて、読書ノートが膨大になってしまった。 組織デザイン (日経文庫) 作者:沼上 幹日本経済新聞出版Amazon この本では、組織を設計するために必要な「組織」についての基本的な知識を体系的に教えてくれる。これを読めば 組織というのは、分業と調整から成り立っていること 組織形態の基本形である、機能別組織・事業部制組織・マトリクス組織それぞれの特徴 分業の様々なタイプのメリット・デメリット。垂直分業、水平分業、並行分業、機能別分業など。 分業によって得られた成果を統合する事前の調整手段である標準化という考え方 分業によって得られた成果を統合する時の例外への対応であ
「チームが機能するとはどういうことか」を読んだ - $shibayu36->blog;
【2016/09/26 12:30補足】 思ったよりこの記事が読まれてしまったので補足。ちょっと本についてネガティブなことを書いてしまったけど、僕個人が今の知識の状態で読んだ時に、1分間マネージャーシリーズなどの他の書籍である程度知っていた事もあって、文章を読む大変さに比べて満足度が低かったなあと感じただけでした。もし自分がマネージャをやっていて、かつなぜか部下への指示が多くなってしまい、自分の考える時間が少なくなってしまっているなあと思っている人は一読すると良いかもしれません。特にフレーミングの話は参考になると思います。 ただ、個人的にはこの本は少し長々としているなとも思っているので、先に他の人が読んだ読書ブログやnaoyaさんのプレゼンを読んでから読むと良さそうです。さらに各章の最後にLessons & Actionsみたいなまとめがあり、その部分が章で言いたいことを端的に表しているの
プロジェクトを成功させるために最初におこなっていること - $shibayu36->blog;
ディレクター時代に仕事でプロジェクトを受け持つ時にどうやったら成功させることが出来るのかについていろいろ考えていた。僕は開発フローをいろいろ考えるのが好きなのだけど、実際に自分がリーダーシップを取ってプロジェクトを進めることを経験すると、そもそもその前に考える・決めるべきことがたくさんあるということが分かったので、ブログに書いておこうと思う。 ここで言うプロジェクトとはサービスを一から作ったり、サービスの一機能を作ったり、受託案件一つだったりを指す。特に開発プロジェクトに限定するものでもない。 プロジェクトを成功に近づけるためには、まずプロジェクトの開始時に、プロジェクトの5W1Hを明確にし、個々のメンバーの責任範囲を決め、それらを一つの場所にまとめておくということをしておくと良いと考えている。 5W1Hを決める すごい基本的なことだけど、プロジェクトをやる上でやはり5W1Hは大事である。
良い物件ではなく良い不動産屋を探した - $shibayu36->blog;
いろいろあって今の家から引っ越すことになった。 良い物件どうやって探したらいいか分からなかったので、適当にググって http://nanapi.jp/286/ を実践してみたら、結果的にうまく行ったので経験をメモ。 結論 良い物件を探すのではなく、良い不動産屋を探すという方法にしたところ、僕の性格としては上手く行った 今回の流れ suumoやhomesで住みたい場所の物件を眺める 希望条件をまとめる 不動産屋を選んでメールしまくる 良さげなところを数社に絞って、さらに送られた物件見ながら返信してみる 一番いい感じに返答してくれた雰囲気の店に行って相談 suumoやhomesで住みたい場所の物件を眺める http://nanapi.jp/286/ とやってることは一緒なので割愛 希望条件をまとめる http://nanapi.jp/286/ とやってることは一緒なので割愛 不動産屋を選んでメ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
