話の腰の折り方にもコツがある
■今回からは、商談や会議・ミーティングにおける上手な会話の仕切り方について解説していきます。第1回目は、話の長い人を相手に、いかに会話の主導権を握るかです。 どこの世界でも話の長い人というのは、いるものだ。 私も会議進行のお手伝いをよくさせていただくが、一度しゃべりだすと止まらない人を多く見かける。しかも、そういう人に限ってエライ人だったりするので、始末が悪い。 商談などもしかり。早く本題に移りたいのに、まったく関係のない話が延々と続いて、なかなか本題を切り出せない。あるいは、すぐに話が飛んでいってしまって、なかなかこちらの要件についてじっくり話ができないことがある。 時間に余裕のある場合はいいが、急を要する場合は困ってしまう。大事なお客さんの話の腰を折るわけにもいかず、あせりながら、ただじっと長話が一刻も早く終わってくれるのを祈るしかない。 私は会議のファシリテーションをしていて、進行上
フローチャートの力を思い出そう
一つ，後悔していることがある。 今年の6月29日，「オブジェクト倶楽部 2006夏イベント」に参加した。オブジェクト倶楽部は，永和システムマネジメントの社員有志が中心になり，オブジェクト指向の実践／研究／発表を目的として作ったグループ。夏と冬に定期的にイベントを開催している。2006夏イベントで6回目となる。 このイベントで，スターロジックの羽生章洋社長が講演した「仕事で必要なことはフローチャートで学んだ」というセッションを受講した。同じ時間帯の裏番組でとても魅力的なセッションがあったのだが，あえてこちらを選択した。羽生氏のプレゼンテーションのうまさをよく知っていたからだ。案の定，おもしろかった。羽生氏がタブレットPCを使ってその場でどんどんフローチャートを書いていく。講演の資料はこちらで公開されているが，これだけではとても伝わらないライブ感があった。 講演の内容はノートにメモしたし，講演
英語で書かれたマニュアルが読めないという以前に：佐野裕のサーバ管理者日記：ITpro
"上級システム管理者"を目指す者にとって、英語で書かれたマニュアルを読解することは必須のスキルですが、実際の現場では、「僕は英語が全然読めないので勘弁してください」という悲鳴に近い声がよく聞こえます。 その人たちの行動を見ていると、英語のマニュアルを読まなければどうしても先に進めないシチュエーションに遭遇すると、多くの場合、ネット上からマニュアルを落としてきて、それをそのまま自動翻訳機にかけようとします。ふむ、彼らは英文マニュアルを日本語のレベルで対処しようとしているわけですね。しかし、皆さんも経験があるかと思いますが、英日翻訳は多くの場合意味不明な翻訳結果を返すので、結果としてこのアプローチは失敗に終わることが非常に多いです。 ということは、このアプローチは、もし自動翻訳機の翻訳精度が上がれば解決する問題でしょうか。私は違うと思っています。 英語が読めないという彼らに、日本語のマニュアル
間違ったコードは間違って見えるようにする - The Joel on Software Translation Project
Joel Spolsky / 青木靖 訳 2005年5月11日 水曜 私が最初の本当の仕事をはじめたのは1983年9月に遡る。それはオラニムというイスラエルの大きな製パン工場で、16台の飛行機ほどもある巨大なオーブンで、毎晩10万個のパンが作られていた。 はじめて工場に入った時、そのあまりの汚さに信じられない思いだった。オーブンの側面は黄ばんでいるし、機械は錆びていて、そこらじゅうが油だらけだった。 「いつもこんなに汚いの?」と私は聞いてみた。 「なんだって? なんの話をしてるんだ?」とマネージャが答えた。「掃除したばかりだから、今が一番きれいな状態なんだ」 なんてこった。 毎朝の工場の清掃を何ヶ月か続けて、ようやく彼らの言っていたことが理解できるようになった。パン工場では、きれいというのは機械にパン生地が付いてないことを言うのだ。きれいというのは、ゴミ箱に発酵したパン生地が入ってないこと
オブジェクト指向プログラミングの本質とは何か? 本当にソースコードは分かりやすくなるのか? 【▲→川俣晶の縁側→ソフトウェア→技術雑記】
オブジェクト指向プログラミングの位置づけ § オブジェクト指向プログラミングは1つの有効なプログラミングパラダイムであって、その特徴を活かす場面に正しく適用すれば、それなりの成果を期待できると思います。 しかしながら、オブジェクトの万能幻想という宗教性の強い思想によって、「特徴を活かす場面に正しく適用」するという試みが阻害されていることが多いと考えます。 つまり、オブジェクト指向プログラミングは上手く機能していないことになります。 これを解消するために、デザインパターンであるとか、アスペクト指向といった非オブジェクト技術を導入してオブジェクト万能幻想の崩壊を防ごうとしているというのが、1990年代後半以降の歴史的な流れであると認識します。 しかし、パターンやアスペクトの導入はプログラミングに不必要かつ過剰な複雑さを導入することであり、このような「穴を見つけては新しい詰め物を探して詰め込む」
説得的コミュニケーション
受け手の行動や意見を特定の方向に変化させることを狙ったコミュニケーションを説得的コミュニケーションという。 説得の効果に影響する要因として、送り手の特質、受け手の特性、メッセージ内容と構成(呈示方法)などが指摘されている。 近年では、精緻化見込みモデルのように、メッセージ内容と受けて側の要因の関係に注目して詳細かつ統合的に説明しようという試みがなされている。
使いやすいライブラリ APIデザイン
使いやすいライブラリ API デザイン 産業技術総合研究所 情報技術研究部門 田中 哲 目的 ユーザの望みを なんとなく かなえてしまう APIを設計する 人間 ➲人間は怠惰である ● 人間は短い記述で済ますのが好き ● 人間はものおぼえが悪い がんばればできるから問題ないという考え方で デザインされた API は使いにくい 人間の根本的性質に反する むしろ、怠惰であることを活用してデザインする 怠惰指向設計 手段 1. ユーザの典型的な望みを推測する 2. (その望みを実現可能な機能を実装する) 3. 望みを実現する機能にユーザを誘導する 望みを推測 ユーザを誘導 怠惰であることを仮定して推測・誘導 openuri ➲ URI を open できるようにするライブラリ ➲ 対象は URI 一般だが主に http で使われる ➲ net/http より簡単にユーザの望みをかなえる re
「わざと」を「気づいたら」に | シゴタノ！
先日のセミナーでも、ブログを生活にうまく組み込んでいる好例として（勝手に）ご紹介させていただいたブログ「お掃除大好き化計画」で、思わず目に留まったのが以下のくだりです。 風呂掃除を習慣で楽に 「毎日」と「週１回」、どっちが楽だと思いますか？ 「毎日」といっても、５分もかからない作業です。 毎日拭いていると、ヌルッとしませんので素手で作業ができ、気がすごく楽です。 髪の毛だって、素手でヒョイとつまめます。 これが、１週間も放っておくと、ヌルつくどころか、ところどころ汚れが黒く付着してきます。 たぶんカビですね。 こうなったら、気持ち悪くて素手では触れませんから、ゴム手袋をして、洗剤を片手に「サーッ、やるぞー」ってことになってしまいます。 という問題意識です。 これを読んで、日々の自分の生活でも似たようなことがあることに思い当たりました。 例えば、洗濯物。特に干し終えて取り込んだ洗濯物を畳んで
不思議なISBN-[結] 2006年5月 - 結城浩の日記
目次 2006年5月31日 - 作業ログを書くために大切な、たった一つのこと / 2006年5月30日 - プログラミング言語の勉強日記 / 2006年5月28日 - 今日の一日 / 2006年5月24日 - 多忙 / 2006年5月22日 - 新連載「簡単実装で学ぶWeb技術2006」 / 誤植 / 2006年5月20日 - 失敗 / 2006年5月19日 - 掲示板spam / 2006年5月18日 - 誤植 / 2006年5月17日 - JSON::Hatchet / 2006年5月16日 - CGIでブラウザのキャッシュを無効にする / 2006年5月15日 - 仕事 / 2006年5月12日 - タイプタイプ / 2006年5月11日 - 仕事 / 2006年5月10日 - タイプしながら考える / 2006年5月8日 - 書きながら考える / 2006年5月5日 - 数学姉 /
コーディングや設計で難所に出くわした時にすること - higepon blog
仕事や趣味でコードを書いているとき、設計をしているときに難所に出くわすことがあります。 そんなときに僕が意識的に心がけていることを紹介します。 もっと良い方法があったらぜひ教えてください。→皆様。 難所に出くわす前に「もうすぐ難所だな」と気づいているときは、すでに冷静な状態で心構えができています。 この場合はきちんと対処ができることが多いです。 何度も考えがループしていたり、難しすぎて他の事に逃避しているときは集中力がないか、難所にさしかかっているサインなので、難所の場合は以下の5つを順番に試しています。 絵を描く 人に言葉にして説明する 思考の流れをテキストにする 散歩する 次の日に持ち越す 絵を描く 設計やコーディングに関して、分かっていることを絵や図にあえて描いてみます。 分からないところは箱を描いて中に? とでも書いておけば良いです。 絵を書く過程で、自分がどこが分かっていないかが
はてなに入った技術者の皆さんへ （jkondoの日記より）
最近はてなの社内では新しい技術を勉強したり、フレームワークや言語を移し変えようかという話も出ていたりして活気が出てきています。技術者も10人を超えて、色々な考え方をする人同士が刺激を与え合いながら切磋琢磨していて素晴らしいなあと思います。そういう中で、僕が技術について思う事を少しまとめてみました。 アウトプットを出す 新しい技術を習得したり、時間を掛けて作り上げた結果は、何かのアウトプットとして出さなければほとんど意味がありません。知識や結果を自分の中に残すだけで終わるのは、それを活かしてサービスを作りたくさんの人が使えるようにする事に比べると驚くほどちっぽけな仕事です。 また、3日間で作り上げた素晴らしい仕組みをそのまま1週間寝かせてしまうのは、4日目に他の人が使えるようにしてから1週間を過ごすことに比べると随分見劣りしてしまいます。 当たり前ですが、どれだけ素晴らしい仕組みを作っても、
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Object Modelling
川村渇真の「知性の泉」