タグ

2015年5月25日のブックマーク (13件)

  • 100分の1秒を争うエアレース・パイロット、室屋義秀さんが実践する自己管理術【判断力の身に付け方】 | ライフハッカー・ジャパン

    初開催となる世界最速のエアレース『レッドブル・エアレース千葉2015』が5月16日、17日に開催されます。最高時速370km。最大負荷10Gの苛酷なレースで操縦桿を操る世界屈指のパイロットは14名。そのなかで、アジア勢で初にして唯一の日人パイロット、室屋義秀(むろやよしひで)さんが参戦します。 そこで、母国初開催で注目を集める室屋さんに、エアレース・パイロットとして、世界で戦うトップアスリートとして欠かせない自己管理術について聞いてみました。今回のテーマは「判断力」。極限の世界で求められる判断力をいかにして培い、実行しているのか。それは私たちの日常生活にも通じることでした。 世界最速のモータースポーツ『レッドブル・エアレース』とは ▲レッドブル・エアレース2014アブダビ大会で飛行する室屋さん Predrag Vuckovic/Red Bull Content Pool まず、判断力

    100分の1秒を争うエアレース・パイロット、室屋義秀さんが実践する自己管理術【判断力の身に付け方】 | ライフハッカー・ジャパン
    gm_kou
    gm_kou 2015/05/25
    “判断するときは、誰しも自分の中に答えがあると思っています。「自分は何がしたいのか」「自分の基軸になるものは何か」”
  • 『理科系の作文技術』の「序章」を読み返す | シゴタノ!

    私がこの書物の読者と想定するのは、ひろい意味での理科系の、わかい研究者・技術者と学生諸君だ。これらの人たちが仕事でものを書くとき──学生ならば勉学のためにものを書くとき──役立つような表現技術のテキストを提供したい、と私は考えている。 「わかい研究者・技術者と学生諸君」でなくても__たとえばブロガーであっても__、書から汲み取れるものがたくさんありそうです。 何かを説明する文章を書く上で、一体何が大切なのか。書を通して読めば、その要諦が掴めます。 特に冒頭の「序章」には、要点が濃縮されています。11ページほどしかありませんが、赤線を引いてある箇所が一杯ありました。 今回は、私が赤線を引いた部分を中心に書の「序章」を紹介してみましょう。 読者を想定する力が、書き手の力である 「理科系の仕事の文書を書くときの心得」として以下の2点があげられています。 (a) 主題について述べるべき事実と

    『理科系の作文技術』の「序章」を読み返す | シゴタノ!
  • サンプル例に見る機能仕様書の基本的な書き方&読みやすくする7つのテクニック (1/3):プロジェクト成功確率向上の近道とは?(2) - @IT

    サンプル例に見る機能仕様書の基的な書き方&読みやすくする7つのテクニック:プロジェクト成功確率向上の近道とは?(2)(1/3 ページ) ITシステム開発の問題点の一つであるコミュニケーションの失敗。連載では、これを防ぐ方法としてお勧めしたい3つのドキュメントを紹介していく。今回は、Joelの機能仕様書を日人向けにカスタマイズされたものを例に、機能仕様書の基的な書き方、読みやすくする7つのテクニック、仕様書作成ツールは何を使うべきか、誰が書くべきかなども解説します。 連載目次 連載の第1回の前回「ドキュメントは最強のコミュニケーションツールである――Joelの機能仕様書入門」では、ITシステム開発がビジネスに貢献していくためには、まずは開発の成功が出発点になること、そしてITシステム開発におけるコミュニケーションの重要性、そしてコミュニケーションにおけるドキュメントの重要性について説

    サンプル例に見る機能仕様書の基本的な書き方&読みやすくする7つのテクニック (1/3):プロジェクト成功確率向上の近道とは?(2) - @IT
  • ドキュメントは最強のコミュニケーションツールである――Joelの機能仕様書入門

    ドキュメントは最強のコミュニケーションツールである――Joelの機能仕様書入門:プロジェクト成功確率向上の近道とは?(1)(1/2 ページ) ITシステム開発の問題点の一つであるコミュニケーションの失敗。連載では、これを防ぐ方法としてお勧めしたい3つのドキュメントを紹介していく。今回は「Joelの機能仕様書」のポイントを解説する。 連載目次 はじめに 連載では、ITシステム開発がビジネスに貢献していくために必要な、最も基的な条件である“システム開発の成功”につながるいくつかのポイントを紹介します。 筆者は、さまざまなコンピューターシステム開発に長年携わってきたソフトウェア技術者ですが、この連載では、あえて技術的ではない話題を中心に述べます。というのも、技術論だけではシステム開発が成功する条件としては不十分ですし、すでにたくさんの優れた技術論が各方面で展開されています。あらためてそこ

    ドキュメントは最強のコミュニケーションツールである――Joelの機能仕様書入門
  • 周囲の生産性を上げた影の功労者を、正当に評価しよう | 戦略|DIAMOND ハーバード・ビジネス・レビュー

    組織のパフォーマンスは、従業員どうしの交流が盛んであればあるほど向上することがウェアラブル機器のデータから実証された。そしてコミュニケーション活性化施策で重要となるのは、交流によって他者を助けている従業員に損をさせないことだ。誌2015年3月号の特集「オフィスの生産性」関連記事。 職場における従業員の最も重要な行動は、他者との交流だ。これは私がグレッグ・リンゼーおよびジェニファー・マグノルフィとの共著でHBRに寄せた特集論文、「仕事場の価値は多様な出会いにある」の主要テーマである。確証のない一般論、あるいは誇張に満ちた学説と思われるだろうか? さにあらず、これは企業で働く人々に装着してもらったセンサーから得た知見である。 我々はウェアラブル機器を通して、従業員がお互いにどのように対話の機会を持つのか、誰がどの相手と会話するのか、オフィス内をどのように動き回るのか、そしてどこで時間を過ごす

    周囲の生産性を上げた影の功労者を、正当に評価しよう | 戦略|DIAMOND ハーバード・ビジネス・レビュー
  • 新人や未経験者を入れることの驚くべき3つの効果 | 戦略|DIAMOND ハーバード・ビジネス・レビュー

    チームに新人や未経験者を入れることのメリットは予想以上に大きい。驚くべき3つの効果――①外部の専門家を巧みに活用する、②新たな領域に果敢に挑戦する、③機敏に動き、より多くのアイデアを出す、を紹介する。 企業にとって新人は長期的な財産になるが、短期的には重荷になる――そう考える採用担当マネジャーは少なくない。仕事を教え、訓練を施す必要があり、一人前になるまでは簡単な仕事しか与えられない新人は、必然的にチームの足を引っ張る存在だと思われがちだ。 しかし、それは必ずしも正しいとはいえない。私は経験の乏しい者が困難な課題にどう取り組むかを研究している。そして新人が(新卒者であろうと、他の企業や部門のベテランだった新任者であろうと)、驚くほど優れたパフォーマンスを上げる例を数多く見てきた。 新人は知識やスキルが大きく不足しているため、注意深く、敏速に、賢明な判断をしながら働く。熟練したスキルが必要な

    新人や未経験者を入れることの驚くべき3つの効果 | 戦略|DIAMOND ハーバード・ビジネス・レビュー
  • デスマーチが起きる理由 - 3つの指標

    Your system administrator has blocked your computer or device. Please contact the system administrator.

  • 2015年、こんなエンジニアは生き残れない:日経ビジネスオンライン

    コラムではこれまで、エンジニアの生存戦略についてさまざまな角度から書いてきたが、今回は最近耳にすることの多くなった「フルスタックエンジニア」というキーワードから、2015年に求められるITエンジニアについて考察してみたい。 まず、フルスタックの「スタック」(stack)とは何かから説明しよう。一般的にシステム開発におけるインフラより上位のアーキテクチャ全体(OS、Webサーバー、データベース、プログラミング言語)を指して「ソリューションスタック」(Solution stack)と呼ばれている。 これはOS、Webサーバー、データベース、プログラミング言語と、各レイヤーを上に積み重ねていく概念「積み重ね=スタック」になぞり、ソリューションスタックと呼ばれるようになったと考えられる。 Webシステムでの代表的なソリューションスタックは、OSにLinux、WebサーバーにApache、データベ

    2015年、こんなエンジニアは生き残れない:日経ビジネスオンライン
  • 炎上案件に突如ディレクターとして投入されたときにやってみたこと - Qiita

    ぼんやり1メンバーとして眺めていたプロジェクトが、リリース1週間前になって「あれも足りない!これも出来てない!どうすんじゃゴラァ」となったときに突如ディレクターとしてぶっこまれ投入されたときにやってみたことのメモ。 一次対応 とにもかくにもPJTに投入されて最初にやったこと。 コミュニケーションルールをみんなで確認して、守ってもらうようにした 誰が何の情報を持ってて、そして誰から誰にどんな指示が出てて、それらがどんなステータスか、、、 もうぐっちゃぐちゃになっていた。 ディレクターは一度死ぬが、一旦全部ディレクターに報告させて、ディレクターから適切な人に指示を出すことにし、メンバー同士でのダイレクトなコミュニケーションをいったん、原則禁止した。 (ディレクターがAさんとBさんで直接やって、と指示を出すときもあるが、それもやりとりの結果をAさんから必ずフィードバックさせるようにした。) ただ

    炎上案件に突如ディレクターとして投入されたときにやってみたこと - Qiita
  • 受注型ビジネスにおける業務量の予測法 | タイム・コンサルタントの日誌から

    前回述べたように、ビジネスの基形態は大きく、見込型と受注型に分かれる。別の言い方をすれば、「Push型」と「Pull型」という風にも考えられる。市場の需要に対するスタンスが、前者の見込型では、自分から需要を想定して事前準備(生産)し、市場に対して"Push"していくのに対し、後者では実際の顧客の注文を起点として、製品やサービスをつくり提供していく、受け身("Pull")的な動きをする訳である。もちろん、別にどちらがよい、わるい、という事ではない。市場と製品の性質にしたがって、適不適があるだけである。客の注文を聞いてから魚を釣りに行く料理屋はないし、先にプラントを建ててから買い手を探すエンジニアリング会社もありえない。そして住宅のように、建売と注文住宅が共存するような市場も存在する。 ところで受注型ビジネスにおいては、見込型ビジネスに比較して、一点、難しいところがある。それは、先々の受注量

    受注型ビジネスにおける業務量の予測法 | タイム・コンサルタントの日誌から
  • 最も曖昧な言葉、それは「ソフトウエア」:日経ビジネスオンライン

    抽象度が高い外来語は様々な定義が可能であり、その定義は人によって色々である。同じ言葉を使っていても定義が異なるならば当然、議論は噛み合わない。 思いついた外来語を順不同でいくつか挙げてみよう。コンセプト、パラダイム、フレームワーク、ビジョン、ストラテジー、ミッション、マネジメント、テクノロジー、イノベーション、いくらでも書けそうだ。 こうした中で最も曖昧な言葉は「ソフトウエア」ではないか。コンピューターの上で動かすプログラム(コードとも言う)を指す言葉だが、それ以外の物事にもこの言葉は使われている。 「ハードウエアとソフトウエアの関係は相対的である。(中略)したがってソフトウエアに言及する際には定義を明示したほうがよい」。 これは3月9日に公開した拙文『1969年、丸ノ内に「ソフトウエアの工業地帯」があった』の一節である。 「関係は相対的」の例をいくつか挙げてみよう。ハードウエアをコンピュ

    最も曖昧な言葉、それは「ソフトウエア」:日経ビジネスオンライン
  • おっぱいドリブン言語学習 - 当たってくじけろ式中国語会話 - 今日学んだこと

    更新がしばらく空いてましたが、ずっと中国に出張だったので…というのが半分、帰国後どうもブログを書くモチベーションが上がらなかったので…というのが半分な感じです。 その意味深なタイトルは何? 中国出張って、駐在でなければ基長くて2週間だったりします。ビザ不要なので。 今回、諸々の事情で1ヶ月という長期間な出張となったので、いっちょ気合入れて中国語学んで、現地のオネーチャンと仲良くなれないかな?と不純な動機を元に学習を始め、たどたどしくもコミュニケーションが取れるまでに至ったので、そのノウハウを公開してみようかな、と。 今回僕が行った地域だけなのかもしれませんが、平均的にみなさん大きいです。 細身で背が高くておっぱい大きい子がマジ多い。題しておっぱいドリブン中国語会話。始まりです。 なお、今回は中国語ですが、他の言葉でも現地に行く事があるのであれば、同じ様にしてコミュニケーションが取れる様に

    おっぱいドリブン言語学習 - 当たってくじけろ式中国語会話 - 今日学んだこと
    gm_kou
    gm_kou 2015/05/25
    おっぱいドリブンすごすぎる
  • 普通の開発者を讃えよう | readwrite.jp

    Djangoの主たる貢献者、ジェイコブ・カプラン=モスは偉大な人物だ。だが、人は自分自身を「英雄的プログラマー」ではないとしている。 PyConの基調講演で彼が語ったように、スーパープログラマーか、弱小開発者か、という二分法は全くの間違いだ。 しかも、それは害悪ですらある。開発者を「一流」か「三流」かで判断しては、その中間の存在を無視することになると彼も述べている。その結果、優秀な開発者は長時間にわたって酷使させられ、一方では劣等プログラマーには仕事が与えられず、業界でのキャリアを積めないという状況はよく起きている。どちらも好ましいことではない。 人はみな並の人間だ世間の評判通り、カプラン=モスをDjangoの発案者、あるいは共同開発者とするのは、実は適切ではないかもしれない。しかし、多くの人は彼を素晴らしいプログラマーと評し続けるだろう。 実際には違う。少なくとも、彼自身の基準ではそう

    普通の開発者を讃えよう | readwrite.jp