タグ

workstyleに関するaonosanのブックマーク (7)

  • 『忙しい人』と『仕事ができる人』の20の違い

    『忙しい人』と『仕事ができる人』の20の違い 私の周りには、『忙しい人』と『仕事ができる人』がいます。忙しい人は、いつも「忙しい、忙しい」を口癖のようにしています。他人が見ると、何でそんなに忙しいのかが分からなかったりするのですが(仕事の成果から見ると)、人は忙しいのでしょう。忙しいと言うことが、その人のモチベーション理由のように感じるくらいです。 それと比べると、仕事ができる人は、他人から見ると何かゆったり、自分のペースで仕事をしているように見えるが、結果として大量の仕事を行ったりしている。みなさんの周りにもそんな『忙しい人』と『仕事ができる人』はいないでしょうか? 『忙しい人』と『仕事ができる人』は何が違うのかという事を、仕事の仕方の違いを通してまとめてみました。(今回は、忙しい人にならない為の時間管理術は省いた内容です。それは、このエントリが好評でしたら、また別のエントリでご紹介さ

  • ほぼ日刊イトイ新聞 - シリコンの谷は、いま。

    カレーといえばインド。 おしゃれといえば、パリ。 というように、 コンピューターといえば、シリコンバレーですよね。 いつごろからか、それは常識になってしまったようですが。 そこでいま何が起こっているのか、どんな場所なのか、 知ってるようで知らないと思いませんか。 雑誌やで読むと、なんだか野心的で活気があって ものすごい場所のように思えるんだけれど、 実際、どうなんでしょうか? けっこう気になるITやら起業やらのメッカのことを、 そこに暮して仕事をしている人に聞いてみましょう。 2年半前に、場シリコンバレーで仕事がしたくて、 日から単身乗り込んだ、 ソフトウェアエンジニアの上田ガクさん、 よろしくお願いします。 第50回 読んでくださってありがとうございます! もう一度、あらためてお知らせを。 「シリコンの谷は、いま。」も 今回で50回を迎えることができました。 この連載を書き始めた頃

  • 組織を腐らせる「キャンサー」の見抜き方:日経ビジネスオンライン

    (Part3へ) 職業としての「社長」を自ら選び、活躍している人をお招きし、将来、経営層を目指す人々に、ご自身の経験を語っていただくトークセッション「Road to CEO」。今回は、世界最大の組織・人事マネジメント・コンサルティング会社、マーサー・ヒューマン・リソース・コンサルティングの日法人を率いる柴田励司氏をゲストに迎え、組織運営の秘訣と人事の課題について語っていただいた。最終回では、会場との質疑応答をお送りする。 司会、山中(以下Y) この辺で皆さんからの質問に移らせていただきます。挙手をお願いいたします。 【Q】 私自身も人事を十数年やっていまして、人事の仕事って、給与計算をやる業務から、ヒューマンリソースという資源をどう再設計するかというところに行きました。 最後に柴田さんがおっしゃられた問題は、ヒューマンリソースという立場を超えていると思うんです。だから何というタイトル(名

    組織を腐らせる「キャンサー」の見抜き方:日経ビジネスオンライン
  • ITエンジニアとしての道を究めるには(1)

    さまざまな困難をどう乗り切ればいいのか ITエンジニアとしての道を究めるには 第1回 スランプを脱出する方法 萩順三(豆蔵取締役) 2003/10/29 読者の皆さんは、スランプに陥ったことがないだろうか。中には慢性のスランプに陥り、「もうこの業界は嫌だ」と考えている人も多いだろう。私もこの業界に長年いる中で、非常に優秀な技術者なのにこの業界についていけなくなり転職してしまったり、病んでしまったりするケースに出くわした。 実は、私も幾度となく激しいスランプに陥ったことがある。いやスランプというのは、日常茶飯事であるが、もうこの業界では駄目ではないかと思ったことが何度かあるものだ。 私のスランプの原因は下記のようなものであった。

  • CNET Japan

  • @IT - スキル創造研究室 - 全記事一覧

    デジタル化やDXといえば、仕事の「見える化」や「効率化」など、目に見えて分かりやすい効果を期待することが多い。だが、変革の質は「想定していなかったこと」にあるのかもしれない。(2024年9月6日)

  • 開発現場で学べること(4)

    エンジニアは日々現場で学ぶ 開発現場で学べること 第4回 最良のシステム設計書とは? クロノス 山野寛 2004/1/28 エンジニアにとって最も大切なことの1つが、開発現場での経験だ。それがエンジニアに多くの知識と勘をもたらす。そんな開発現場で若きエンジニアが失敗し、そこで何を学んでいくか。それを毎回紹介したい。 ■要求定義から開発フェイズへ移行 前回(「第3回 システム開発の真の目的を見失わない 」)までわれわれの開発チームは、ある某サービス業を営む企業Aの要求定義をまとめる作業を行ってきた。その作業も3カ月間でようやく無事に終了し、いよいよ格的な開発フェイズへと移行した。 開発フェイズではまず初めに、設計手段の統一化を図るため、メンバー全員で設計書の標準化を行うミーティングを実施した。われわれはこのミーティングで、クラス間の静的な関連の記述にはクラス図を、また動的な関連の記述にはシ

  • 1