タグ

仕事術に関するh-yanoのブックマーク (14)

  • あなたの人生を変える、たった7つの魔法の質問 | P O P * P O P

    「毎週、日曜日の夜に次の7つを自問しましょう」という記事がありました。 よくある自己啓発系の記事ではありますが、確かにこういうのは必要・・・と思ったのでご紹介。 人生はコツコツと積み重ねていくことが大事ですよね。そのためにも定期的に「自分が今どこにいるのか?」をチェックしておきたいところです。 これらの質問からはじめて自分だけの進捗チェックリストを作ってみてもよいのではないでしょうか。 さてそのたった7つの魔法の質問は以下のとおり。 来週は何を改善すべきだろうか? 今週誇れることは何だろうか? 今週の最大の達成は何だろうか? 人生の目標に近づくために今週自分がしたことは何だろうか? 今週自分にとって難しかったことは何か?その理由は? 今週一番時間の無駄だったのは何だろうか? 今週恥ずべきことは何だったろうか? もちろんこれらの質問が完璧なものでもないでしょうし、人それぞれに違った質問が必要

    あなたの人生を変える、たった7つの魔法の質問 | P O P * P O P
  • 小野和俊のブログ:持続可能な成長を実現する「ラストマン」という自分戦略: 八百屋になりたい人が肉屋に入ってしまったらどうするか?

    私はその戦略をラストマン戦略と呼んでいる。 大学を卒業してサン・マイクロシステムズに入社してすぐにわかったことは、Java を生み出した会社でソフトウェア開発をやろうと思って入社したのに、日サンはソフトはほとんどやっておらず、ほぼ100%ハードウェアを販売するための会社だったということだった。 野菜を売りたくて八百屋に入ったつもりなのに、間違えて肉屋に入ってしまった。このようなときにどのように行動すればよいか? 1. 肉屋に入ったのだから、とりあえず肉屋を目指す 2. 八百屋への転職活動を開始する 3. 肉屋の中で野菜についての No.1 を目指す 一番多いのはパターン1の人で、入社の直前直後は熱くソフトウェア開発を語り合った同期の多くは、今ではハードウェアのスペシャリストへの道を目指している。 ラストマン戦略とは、ある所属組織内で自分が一番(最後に立っている人 = ラストマン)になれそ

    小野和俊のブログ:持続可能な成長を実現する「ラストマン」という自分戦略: 八百屋になりたい人が肉屋に入ってしまったらどうするか?
  • 「マイ締め切り」で間際のバタバタをなくす【解決編】

    誰しもが経験のある、締め切り間際になって追われるように取り組んでいる仕事。この“追われるモード”から脱却し、仕事を“追いかけるモード”にシフトする方法を解説します。 コツ:「マイ締め切り」を設定する 【問題編】では、締め切り間際になって追われるように取り組んでいる仕事を何とかする──という課題が浮かび上がりました。現状を分析すると、以下のようになります。 締め切り間際まで忘れている 一気に終わらせる必要があるため「気合い」がいる まとまった時間がいる まとまった時間が取れないと窮地に立たされる → 余裕をもって取り組めるようになりたい まず、現状で注目すべきは「一気に終わらせる必要がある」ことです。5分や10分で終えられるような比較的小さなタスクであればさほどプレッシャーにはなりませんが、おおむね30分以上かかる大きなタスクになってくるとプレッシャーが生まれ、「よし、やるか!」という気合い

    「マイ締め切り」で間際のバタバタをなくす【解決編】
  • POLAR BEAR BLOG: 優れたブレインストーミングのための8ヶ条

    週末なのでサラッと。「出されたアイデアを批判するな」「(アイデアの)質より量を目指せ」など、ブレインストーミングに関する Tips は既に数多く存在していますが、最近の Business Week でもこんな記事が出ていました: ■ Eight Rules To Brilliant Brainstorming (Business Week Online) "Eight Rules"ってことで8つの提言がなされています。曰く: アイデアを出すだけならブレインストーミングは時間の無駄(「目安箱」でも設置しておけば十分!)。出されたアイデアをつなげてみたり、ふくらませてみたりする場にせよ。 いくらブレインストーミングが「何を言っても許される場」だったとしても、毎年従業員の10%がリストラされるような職場では、自由な発言など望めない。そのような環境でのブレインストーミングは諦めよ。 創造性は、一人

  • プロトタイプを重視するカルチャー

    最近、UIEJのメンバーの間で「うみがめ」というGoogleの「20%ルール」に相当するルール作りの話が盛り上がっている。ルール作りはおおいに結構なのだが、「なぜうみがめが必要か」というプリンシプル(相当する良い日語がないが、あえて選ぶなら「筋」-詳しくは「プリンシプルのない日」参照)を見失って「ルールのためのルール作り」に陥らないで欲しい、というのが私からのお願いである。 そこで、今まで私がプロトタイプ作り、ベータ版サービスの重要性に関して言って来たことをまとめてみた。 1.UIEのような会社にとって何よりも大切なものは、賢くてクリエイティブな人。そんな人たちが働きたいと思うような、そして彼らがクリエイティビティを最大に発揮できるような環境を提供することが大切。 2.当のイノベーションはごく少人数でおこすもの。一人とか二人とかのクリエイティブな人が、「こんなもの作りたい」という情熱

  • 小野和俊のブログ:徹夜をしてはいけない理由

    どうしても昨日までに仕上げなければならない仕事があったので、一昨日は徹夜で開発をした。一人で飲んだり、人と飲んだり、布団の中で考え事をしたり、徹夜をすること自体は悪いことではない。しかし、徹夜で仕事をするのは可能な限り避けた方が良い。 ベンチャーを始めてからの最初の2年は、年末年始を含めて365日1日も休まず仕事をした。徹夜なんて当たり前である。そんな私だったが、会社が3年目に入る頃に休息の重要性を痛感し、以来、できるだけ徹夜はしないようにしている。それは、徹夜がもたらす作業時間よりも、悪影響の方がずっと大きいということに気づいたからだ。 私の経験では、徹夜が常習化するにつれ、個人/組織には次のような症状が出てくることがある。特に、影響力のある人がこのような状態になると、組織全体が影響されて深刻な症状にかかりやすい。

    小野和俊のブログ:徹夜をしてはいけない理由
  • 写真でわかるGTD(導入2カ月後)

    2カ月前にGTDをはじめたITmediaスタッフのWさんとMさん。はじめての週次レビューも順調にこなすことができましたが、現在はどうでしょうか。「写真でわかるGTD」シリーズ最終回は、GTD導入から2カ月後の彼らの様子をリポートします。 「人を待つのが苦にならなくなった」(Wさんの場合) 比較的順調にGTDを実践できていたWさんに、まずはお話を伺いました。 「実は先週、週次レビューをサボってしまったんですよ」 いつもは土曜日の午前中に週次レビューをこなしていたWさん。先週もいつものように週次レビューをこなそうとしたらしいのですが、部屋の掃除をしていたらいつの間にか時間がなくなり、レビューをサボってしまったようです。 「週次レビューをサボったので、今週はすっきり感がなくて困りました。しょうがないので、週の途中に週次レビューをすることにしました。」 Wさんは週の途中にレビューすることで、なんと

    写真でわかるGTD(導入2カ月後)
  • @IT:ITエンジニアにも必要な国語力 第12回 個条書きを過信してはいけない

    コミュニケーションスキルの土台となる図解言語。だが筆者によると、実はその裏に隠れた読解力、国語力こそがITエンジニアにとって重要なのだという。ITエンジニアに必須の国語力とはどのようなものだろうか。それを身に付けるにはどうしたらいいのか。毎回、ITエンジニアに身近な例を挙げて解説する。 ■個条書きは相互の関連を表さない 連載第9回「メタ情報とサマリーで『伝わる』ビジネス文」、第10回「複雑な条件を文章で書くべからず」、第11回「階層と名前の不一致に注意する」にわたって、「こんな説明では分からない」10種類の失敗パターンを以下のように列挙した。 (1)メタ情報の欠落 (2)要点の分からない見出し (3)複雑な条件の文章表現 (4)分類を表さない名前 (5)過剰な言い換え (6)対称性のない表現 (7)指示代名詞の多用 (8)相互関連の分からない個条書き (9)時系列の乱れ (10)語感と実感

  • 大量のメモをうまく整理できなくて困る(1)【理論編】

    リスト形式というのは身の回りでもよく目にしますし、仕事をしていれば箇条書きのチェックリストを作ったり手順を整理したりするというシーンが少なくないでしょう。比較的なじみ深いフォーマットといえるでしょう。 この形式の良い点は、文字通り1項目に1内容というシンプルながらもフォーマットが決まっているところにあります。逆に悪い点としては、量が増えてくるとリストが長くなり、項目間の関連性や構造が見えづらくなってくることでしょう。 当は関連性が強いにも関わらずリスト上で離れた位置にあれば、それを見落としてしまいがちです。また、関連性というのは常に1対1であるばかりでなく、1対多であったり多対多であることもあるため、これを表現し構造として把握する上ではリスト形式では難しくなるわけです。 ここまで書いてきたところを図にまとめてみました。 この図を眺めると、「メモを集める」「メモを整理する」という大きな2つ

    大量のメモをうまく整理できなくて困る(1)【理論編】
  • 困ったら、最初の一歩を踏み出してしまう | シゴタノ!

    ちょっと前の記事ですが、日経ビジネスアソシエ・2006年6月20日号に 「仕事から逃げたくなった時に効く!気持ちを切り換える30の方法」 が紹介されていました(アクセス・ビジネス・コンサルティング代表の八幡紕芦史氏によるもの)。 1つ1つは「なるほど!」と思えることばかりで、身につまされることも多かったのですが、30個というのはあまりにも多いため、たぶん覚えられないだろうなぁ、と感じました。 そこで、「マジックナンバーオブセブン」あるいは、「7±2の法則」と呼ばれるルールに従って整理してみることにしました。30個あるので、5~6個ごとにグループ分けして、5~6個のカタマリにすればいいわけです。 「7±2の法則」については、こちらの記事で以下のように解説されています(佐々木正悟氏による)。 32199887654 この数字は11桁で、簡単に分かる規則性がありますが、それでも一度で記憶するのは

  • 紙を使った発想法

    新しいプロジェクトを立ち上げたり、困難な案件を乗り越えたりするために必要な創造性やアイデア。なかなか出てこないアイデアを生み出す方法など、創造性を高めるさまざまな方法を紹介していく。 創造性を高めるためには、一言でいうと“リソースフル”な状態になることが大事です。 “資源”という意味の“リソース”と、“リソースフル”というのは全然違う意味です。リソースの場合、資金がある、道具がある、人材がある……というように、外にものがあることを「リソースがある」といいます。逆に、スタッフがいない、資金もない、何もない、というのはリソースがない状態です。リソースがないとキツイですよね。 このように、リソースは外側にあるものなので、その有無に影響されます。必要なものだし悪いわけではありませんが、創造性を発揮するにはリソースに頼るのではなく、自分自身が“リソースフル”になることが大事です。 何でもリソースに変

    紙を使った発想法
  • 島国大和のド畜生 次世代くん:576 仕事の伝え方

    やって見せ、言って聞かせて、させてみて、誉めてやらねば人は動かじ。(by山五十六) そこまでやるなら、 自分でやった方が早い ので困る。 (でも自分でやっちゃうと、いつまでも仕事は減らないワ、誰も育たないワで結果的に苦労するんだけど) web漫画投票:投票する 結局アレだ。仕事を教えるってのが先ず不遜なのかも知れぬ。 出来る奴はほって置いても出来る。 定型処理とその理由を教えれば後は自分で考えて動ける奴が強い。 思い返すに、自分程度の人間ですら、今手持ちのスキルは結局自力で得たもので、人から教わったものは無いに等しい。(立ち振る舞いは師匠筋のを見て、覚えたけど) 例えば、時間が有ったらもっとプログラムを覚えたい、絵を練習したいとか言う人いるけど、それ根的に違うから。 当に出来る奴は、時間が無くてもそれを趣味としてやってる。 自分はプログラムも絵も仕事に必要な基礎スキルは趣味の段階で覚

  • 「とりあえずググる」を卒業!TOPエンジニアの検索術/Tech総研

    「あの情報、絶対にあったはず!」とわかっていても、ネット上にもPC内にも見つからないという経験は誰にでもあるだろう。そんなヤキモキ解消テクニックを、検索ツール活用の達人に聞く。 さまざまな情報がネットにあふれるこの時代。ちょっとした調べ物で、検索エンジンにキーワードを入れてみたら、何千件もヒットしてしまい、手に負えなかったりする。逆に、どこかに必ずあるはずの情報にたどり着けなくてもどかしい思いをすることもある。 また、自分のPCの中に蓄積される情報も、増える一方。ストレージの容量は幾何級数的に伸びていき、その管理もますますややこしくなっていく。 データが少なかった昔なら、用途別にきちんとフォルダを区切り、さらにそれを階層分けして、整然としたツリー構造に……などということも可能だったかもしれない。しかし今や、そんな手法が通用しない情報の氾濫にさらされているのである。 情報管理は「分類・階層化

  • ITエンジニアを続けるうえでのヒント

    将来に不安を感じないITエンジニアはいない。新しいハードウェアやソフトウェア、開発方法論、さらには管理職になるときなど――。さまざまな場面でエンジニアは悩む。それらに対して誰にも当てはまる絶対的な解はないかもしれない。連載では、あるプロジェクトマネージャ個人の視点=“私点”からそれらの悩みの背後にあるものに迫り、ITエンジニアを続けるうえでのヒントや参考になればと願っている。 ■ITエンジニアの経験年数と悩みとの関係 ITエンジニアとしてのキャリアは何年になりますか。連載の第1回の冒頭としては乱暴か書き方かもしれませんが、皆さん、いかがですか。 3年以下であれば、悩みはまだ少ないでしょう。石の上にも3年とはよくいったものです。まずは3年を目安に無我夢中でキャリアを磨いてください。3年持たない人はエンジニアに向いていないのでしょう。多くのITエンジニアを私は見てきました。その中で、ITエン

  • 1