アナロジー思考　「構造」と「関係性」を見抜く

感想

読み始めてすぐ「もしかしたら自分はアナロジー思考が得意かもしれない」と思った。なぜならわりと「難しいものを何か別の全く関係ないもので例えてわかりやすくする」ということをよくやっているからである。例えば過去にWordPressのイベントで登壇したときはMovableTypeをごはん、WordPressをパンに例えたプレゼンをした。他にも、所属チームの役割についてはお弁当、ブログ構築についてはケーキ、などプレゼンの度に何か例えを使っている。Gitのコマンドを郵便局に例えばものは多くの人からわかりやすいと支持された。主にTech×食べものなのだけど…。

このような全く関係のないところから発想を借りてくる、ということがアナロジー思考と呼ばれるものだったということを改めて学んだ。しかし「自分の理解」「他人への説明」という部分ではできているが「新しい発想」に関してはそうとは言えない。アナロジー思考力を鍛える、という章に書かれていた「複数の世界を並存して考える」という部分が苦手であり、リアリティのないドラマに文句を言ったりする。意識してあらゆるものに対し別の世界を「一緒にしてしまう」ではなく「繋げる」という思考力を鍛えたい。

以下、自分用要約まとめ。 続きを読む

21世紀のビジネスにデザイン思考が必要な理由

感想

ビジネスマンもデザイン思考で問題解決してこうぜ！的。デザイナーの人が読むというより、普段あまりこういう考え方で問題解決をしない人向け。デザイン業の人は改めてデザイン思考の必要性と確認の意味で読むと良いです。半分以降はビジネスマン向けの要素つよめ。 フレームワークやプロトタイピングについては実践したことがない人にもわかりやすくまとめてある。改めて確認できたのがよかった。知っているだけでなく、ちゃんと使いこなせるようにならないといけないなー

以下、自分用要約まとめ。 続きを読む

仮説思考 BCG流 問題発見・解決の発想法

感想

改善を目的とする仕事をする人におすすめ。今の業務はまさに検証の繰り返しなので仮説思考は必須。 「仮説から始めれば作業量は激減する！」激減まじかよ！と思ったけど思ったより既に普段から意識していたことも多くあった。しかし意識しているとは言え、しっかり実践できているということではないので、改めて仮説を持って業務に挑もうと思う。「網羅思考」の章を読み、まさに時々そのような行動を取ってしまっているということを痛感。加えて「両極端に振って考える」が苦手である。何度も実際に実践してみないと間違った仮説に突き進んでしまいそうなので普段から『何故を繰り返す』という癖を付けていきたい。

以下、自分用要約まとめ。 続きを読む

チームが機能するとはどういうことか――「学習力」と「実行力」を高める実践アプローチ

感想

これからチームを持つ、チーミングを必要とする人におすすめ。特にプレイヤーからマネジメント側に回る人は必読。自分はまさにこれからチームでプロダクトに関わって行く、というタイミングだったので適切な内容だった。若干冗長なので半分ぐらいまで読めばだいたい内容は掴めるという感じチリ鉱山落盤事故救出チームの話など挙げられている事例もチーミングを具体的にイメージしやすい。チームで協力し成果を出したい、という想いに沿った本なので読むだけに留まらせずぜひ経験と共に習得していきたい内容。

自分のチームは若いメンバーで構成されているのだが、そういうメンバーにどういう形でチーミングしていくか？において、特に信頼関係を築いていく上で「心理的安全な場」の章は実践でも非常に役立った。チーミングのスキルはひとりで習得できるものではないので実際に今のチーム内で試行し、お互い尊敬しつつ安心して成果を上げるチームを目指していきたいです。

以下、自分用要約まとめ。

続きを読む

こんにちは！yunico.nagataです。結構ひさしぶりになってしまった。最近はまた少し別のことを勉強してます。

よって、いろんな本を読むわけですが、小説のようにじっくりと一行ずつ読むので非常に進みが遅く、そして内容がなかなか頭に入ってこない。 そんなに頭が良くないので勉強しようと本を読むけど本もうまく読めないとか悲しすぎます。という訳で変えてみることにしました。

参考にしたのはけんすうさんのブログ。2009年の記事なんですが、いま読んでも非常に役立つノウハウです。

そんなに頭が良くない人はそれなりに適切なやり方を意識的に選択していかないとやばい。頭が良くないということを自覚するのも大事です。具体的なやり方はブログに書かれているものが全てなのですが、少し引用をさせていただくとこんな感じ。

１：もくじを熟読

２：著者欄を熟読

３：ネットとかでその本について調べてレビューを読む

４：どんないいことが書かれているか仮説を立ててどっかに書いておく

５：１時間で読み切るぞと時間を計って読む（電車を降りるまで、とか決めてもOK）

６：ぐわって仮説で立てた個所がないか探しながらざっと全体を「眺める」

７：関係ありそうなところがあれば本のはしを追っておく

８：関係ありそうなところは熟読

９：読み終わったらもうその本は捨てちゃう。

１０：その本から何を得たかどっかに書いておく。書かなくても頭の中で考えておく

要は、必要なエッセンスだけ取り出せられればOK、ぐらいの気持ちで読む。欲張りすぎないことです。

実際に仮説を立ててから、時間を決めて、眺めながら関係ありそうなところを探して必要な部分のみを取り出していく、という読み方に変えてみたところ、非常に効率よく内容を理解することができました。てか、周りの人に話したらみんな既にそうしていた……

時間がなくてなかなか本が読めない〜とか、本を読むのが苦手だ〜、という人におすすめです。

おわり

こんにちは！yunico.nagataです。34歳になりました！

さて、ちょっとタイトルにあるようなことについて考えるキッカケがあったので、自分の考えを書いてみたいと思います。結構いろんなところに書いているのでまたかという感じはあります。

Gitとどう向き合うべきか

たぶん世の中には

• Gitが使えればよくわかっていなくてもそれでいい派
• どういうものかをきちんと理解して使ったほうがいい派

のふたつに分かれるかなあと思います。

日々の業務で使うぐらいであればとりあえず使えればいいって感じでもいいかもなんですが、わたしは後者、きちんと理解をしてから使った方がいいんじゃないかと思う派です。

理由の元は自分の実体験。nanapiでGitを導入します〜ってなったとき「うわ〜ちょうむずそう〜やりたくねえ〜」って思ったのが正直な気持ちで、最初はそれっぽく使えればいいやと思ってGUIからポチポチ操作をしていました。 でもGitってそこそこ複雑なものなので、エラーはまあ、出まくる。そうしたときにGUI上での解決が難しかったりします。「Gitのエラーを」「そのGUIのやり方で」解決しないといけないのでややこしい。 エラーでググってもターミナルでの解決法ばっかり出るし。で、結局解決できない。「まじGitむずい　使いたくない…」みたいな気持ちが加速する。 結局エンジニアにお願いして解決してもらうのだけれど、エンジニアはみんなCUIで操作してるから当然コマンドで解決しますよね。だからまた同じエラーが起きてもわたしは結局またGUIで解決できないわけです。以下負のループ。 この辺は去年のnanapi勉強会でも話したりしたやつです。

そこから、エンジニアに教えてもらいやすいし、コマンドで覚えた方がシンプルだし、ググりやすいし、ってことでCUIで覚え始めたんですが、いまではもうこれ以外考えられん…という感じ。 CUIシンプルでいい。どのPCでもどんな環境でもすぐ使えるし。 仕組みとかをちゃんと理解した上でコマンド操作もできるけどGUIの方がラクだからっていうのは賛成 。RubyMineとかもそこからGit操作ができちゃうので、エディタとターミナルの移動がなくていいですよね。

時々見かける「デザイナーは黙ってGUI使えや」っていうのとか「GUIで使えてればそれでいいじゃん」的なのを見るとなんだかなーと思ってしまいます、、 5月から入った新人ちゃんもGit初体験っていってたけど今ではフツーにターミナルから操作してるので、理解できればCUIでも問題ないきがする。 というわけで「ちゃんと理解した上でのGUIは賛成」派！という感じ。

こんにちは！yunico.nagataです。昨日今日寒すぎないですか？4月ですよ？

期が新しくなったので、新しいことに取り組んでいます。結構やる気満々だよ！

前期からずっとモチベーションが続いているのだけど理由は自分でもよくわかりません。たぶん、

• 人と一緒にやってる
• 好きなことをやってる
• おもしろがってやってる

あたりが良いんじゃないかな〜と思ってます。何ごともおもしろがってやるというのは大事すねえ。

なんかもっと書こうと思ったけどこんな感じっす。