タグ

考え方に関するtorazukaのブックマーク (73)

  • リモートワークに対する考え方

    自分の中でリモートワークに対する考え方をまとめておくことにする。 そもそも自分自身はリモートワークをするのはかなり難しい、職種的に人と会って話すことを求められる事が多いためだ。 ということで、ここでの考え方というのは、自分が一緒に働く仲間がリモートワークを行う場合の考え方とする。 まずリモートワークに対する考えだが積極的に採用していきたい、という方針だ。ただしその人がリモートワークに向いており、一緒に働く仲間がリモートワークでも良いと思えるのであれば、という条件付き。 そのため、誰も彼もがリモートワークに向いているとは思っていない。リモートワークを希望し、さらに向いている人のみがリモートワークを行うべきという考えだ。 身近なリモートワーカーまず、自分がどんなリモートワーカーと一緒に働いているのかを書き出してみた。一人は自社役員、もう一人はフリーランサー。 自社の CTO完全フルリモート。

    torazuka
    torazuka 2017/04/29
    "この辺を埋められるようにリアルタイムなビデオ通話がもっと簡単になると良いなという思いで、自社製品を作ってたりする" おぉぉ。
  • Facebook is a growing and unstoppable digital graveyard

    The social network is changing how we experience death (Credit:Getty Images) At some point, there will be more dead Facebook users than living ones – and for those left behind, it is transforming how we experience the death of those around us. The day after my Aunt’s passing, I discovered she’d written me a lovely note on the front page of the Shakespeare collection she’d given me. “I know how imp

    Facebook is a growing and unstoppable digital graveyard
  • 【フォーカス】スポーツ×デジタル -感動の共有をもっともっと!- : 富士通総研

    2016年2月10日(水曜日) 【フォーカス】シリーズでは、旬のテーマに取り組むコンサルタントを対談形式で紹介します。 B.LEAGUE発足や東京オリンピックなどスポーツが盛り上がって行く中で、どのような課題があるでしょうか?また、ICTに期待されることは何でしょうか? 対談では、「スポーツ×デジタル―感動の共有をもっともっと!―」というテーマで、日プロサッカーリーグ(以下、Jリーグ)の中西常務理事、出井マーケティング部長、ジャパン・プロフェッショナル・バスケットボールリーグ(以下、B.LEAGUE)の大河チェアマン、富士通株式会社の小口氏、株式会社富士通総研(以下、FRI)の松シニアコンサルタントに語っていただきました。進行役はFRI流通・生活サービス事業部の今村事業部長です。 1. Jリーグの百年構想「スポーツで、もっと、幸せな国へ」 【今村】 今秋のB.LEAGUE発足や20

    【フォーカス】スポーツ×デジタル -感動の共有をもっともっと!- : 富士通総研
  • データで示す

    データで示す 客観的な評価のためにはデータを数字で示すことが重要だと思う。Amazonでは、データで定量的に示すものと、定性的にビヘイビアで示すもの、大きなところではリーダーシッププリンシパルに基づくか、の2つを評価軸として持っている。これは年間の評価だけではなくて、様々な点でこの評価軸を用いた。その結果として、別々のビジネスラインで、ビジネス状況は異なるようなメンバーでも、企業内での文脈がある程度同一にできていて、これが企業競争力につながっているように思う。個人としても学ぶべきものが多かったし、発見も多かった。 個人としては、データは大きく分けてオリジナルデータを極力そのまま掲載するものと、グラフ化して加工したものでは別々にしたほうがよいと思う。データはどこまで収集しておりどうなっているか、とそのデータをどう見たか、は全く別の話だからだ。正直にいうと、かなりの数のデータは加工されたものだ

    torazuka
    torazuka 2016/03/01
    生データは背景を確認し、加工データは意図を推測する。そもそもデータを使うのは前にすすむ意思決定をするためだよね、という素晴らしい記事!
  • はてな

    自動的に移動しない場合はをクリックしてください。

    はてな
  • Software engineers should write | Shubhro Saha

    In elementary school, there were “math kids” and there were “English kids”. You were classified by the other kids’ impression of your prowess in each subject. I was a math kid. So I majored in computer science and set off to be a software engineer. Along the way, though, the “math kid”/”English kid” designation never really wore off. If anything, it got stronger. The engineers I meet today cringe

  • 不作為の罪:『なぜ、システム開発は必ずモメるのか?』 - ミックのブログ

    システム開発というのは、トラブルの集積です。例外なく。大から小まで、パッケージ開発からマイグレーションまで、もめることのないプロジェクトは存在しません。 みんなそれなりに頭もいいし、人間的にもまともな人たちが集まって仕事をしているはずなのに、「なんでこんなことになっちまったのかな・・・オレたちはただ、幸せになりたかっただけなのに」と敗戦後の焼け野原を見たときのような呟きが漏れてしまうことは、日常茶飯事です。 それぞれのプロジェクトには、固有の難しさと失敗の原因が存在するでしょう。いわく、新しい技術エンジニアが慣れていなかった。いわく、客のキーマンがモンスターカスタマーだった。いわく、オフショア先の品質が低くてメチャクチャなコードが上がってきた――これらはいずれも嘘ではありません。「幸福な家はみな同じように幸福だが、不幸な家の不幸には独自性がある」というトルストイの言葉通りです。 しかし、

    不作為の罪:『なぜ、システム開発は必ずモメるのか?』 - ミックのブログ
    torazuka
    torazuka 2015/03/02
    "プロとして客に注意を促し、コストと便益を情理を尽くして説明し、体を張ってシステムを守らなければならないのだ、と"
  • 技術系ブログを書いてくれてる人に申し上げたいこと6つ

    はじめにいつもお世話になってます! 助かってます! ありがとうございます! 解説サイトの人は特にありがとうございます! How to doは多いけど、Why I did in this wayで書かれてる記事が極端に少ないことたぶん備忘録として書いている人が多いと思うんだけど、マニュアルのような書き方が多い気がします。いやまあマニュアルがないよりは遥かに嬉しいことなんですが。重ね重ねいつもありがとうございます。 『AしてBしてCすると、コレができる! かんたん!』で終わっていることが多いです。多いというか、ほぼこれです。 『ほげほげのためにA、もげもげのためにB、FUBARのためにCすると、コレができる』というように書いてくれると相当嬉しいです!別に『これこれをクリックして…』とか『bashとはうんたらかんたら』とか詳細を書かなくてもいいので、こういう目的のためにやったと書いてくれると嬉し

    torazuka
    torazuka 2015/02/12
    こういうふうにリクエストをまとめて提示されると、なるほどと感じる。対応するかどうかは書き手の自由なんだから、クレクレ乙とかカリカリしなくてもいいと思う
  • インフラコストを削減する その1 - mikedaの日記

    過去2回ほど、20%~30%程度のサーバ削減をやったことがあって、 その時のメモが出てきたので、考え方とかやったことをザックリまとめてみる。 まず例えば、不要なサーバを削減してインフラコストを月額10万円減らしたらどうなるか。 これは運用コストも解約リスクも無い、恒久的な利益になる。 裏返すと以前は恒久的な損失が発生していたということなんだけど、情報をまとめないとだれも気づかない。 なのでどこまでやるかは状況次第だけど、情報をまとめることは最低限必須だと思う。 ということで、『効率化する』、『安く買う』についてはまた次回にして、 今回は『情報をまとめる』、『ポリシーを決める』、『適切なサーバ台数を維持する』ことについて。 基的にオンプレ環境を前提として考えます。 情報をまとめる まずは最初に言ったように、必要な情報をまとめる。 そしてだれでも見れるようにする。 これをしないと自分が思いつ

    インフラコストを削減する その1 - mikedaの日記
    torazuka
    torazuka 2015/01/19
    これはありがたい記事。
  • 小さいライブラリを採用する - mizchi's blog

    僕がJavaScriptでライブラリを選定する際、迷ったら小さいものを使う。その理由について。 前提 前提として、枯れた環境で大きいフレームワークができるのは理解できるし、メリットも大きい。あるいは言語それ自身と区別できないぐらいに発達したフレームワークに依存するのも理解できる。RubyにとってのRailsとか、ErlangのOTPとか(いや、これは詳しくないけどそうなんだろうなっていう予想なんだけど)。 危険信号 今のJS界隈は動きが早すぎて、何に依存するのも危ない。とくにフレームワークと銘打たれたものは、でかすぎてどれも危険信号を放っている。 数年後、廃れてしまったフレームワークで開発し続けるのは、僕個人としてもあまり関わりたくないし、現場の離職リスクとして数字に出るだろうし、採用後の教育コストの問題になる。だいたいそういうものは元の設計者もいなくなるものだ。プロダクトの死を意味する。

    小さいライブラリを採用する - mizchi's blog
  • 「失敗を活かす」を実現する仕組みづくり - ワザノバ | wazanova

    http://vimeo.com/94950270 1 comment | 2 points | by WazanovaNews ■ comment by Jshiike | 約2時間前 ミスを許さない組織って嫌ですよね。月曜日の朝に会社に行くのがとにかく苦痛だった時期があります。しつけ的な規律をもたらすという一定の効果はあったかもしれませんが、ミスをしないように、しかられないようにするために仕事の進め方が最適化されていって、顧客がどう思うかよりは、上司の顔を伺うところに皆が全力を注ぎはじめます。 そんな会社は反面教師に。また最近は、blameless postmortem(個人批判をしない建設的な障害の振返りミーティング)というのも流行言葉。「そうだそうだ、もっと前向きであるべきだ。」と思いつつ、しかし難しいのは、ユーザに悪影響を与えるものを減らそうとする気持ち。その気持ちを持つことが

    torazuka
    torazuka 2014/09/23
    "迷ったら上司に決めてもらうのではなく、試してみる。必ず事前に仮説をもち、失敗しても成功しても、何を学んだか、次はどうするかが重要"
  • 毎朝5時に起きてコードを書くソフトウェアエンジニア - higepon blog

    毎朝5時に起きて出勤前にコードを書くという習慣を始めた。2週間経ったのでまとめてみようと思う。この記録が小さい子持ちの30代パパ・ママエンジニアに役立つとうれしい。多分独身で若い人には役に立たない。 始める前に抱えていた問題 好きなコードを書きたい。勉強したい。そう思っても以下の理由により以前とは比べられないほどに時間がとれなくなってしまった。 子供に可能な限り時間を使いたい。結果的に自分の時間は減る コードを書く自由時間が極端に少ない 1人になれる時間がほとんど無い 家で10分以上集中できない。こどもが遊ぼう!って誘ってくるとか 子供に話かかられたり質問されたら出来る限り応えたい とにかく疲れやすい 以下のような典型的な1日。 朝は 6:30 頃に早起きの息子に起こされる。1人で起きて絵などを読める歳だが、静かに起きることは稀だ。トイレに行きたいとか。何かが見つからない。何だかんだで同

    毎朝5時に起きてコードを書くソフトウェアエンジニア - higepon blog
    torazuka
    torazuka 2014/06/24
    お子さんとの時間をできるだけ取るっていう方針に合わせて最適化したらこうなったんだろうな。すごい。人生の選択の問題な気がした。
  • 【インタビュー】『テルマエ・ロマエ』作者ヤマザキマリさんが語る、とらわれない生き方とは? - ライブドアニュース

    ●好きなことと、生きていくための仕事は分けて考える『テルマエ・ロマエ』『スティーブ・ジョブズ』など数々の作品を世に送り出している漫画家ヤマザキマリさんが、このほど『とらわれない生き方 悩める日人女性のための人生指南書』(KADOKAWA/メディアファクトリー)を刊行した。日とイタリアを始め世界中を行き来して活躍する同氏に、仕事と生き方への思いを伺った。 ○「仕事とプライドを融合させない」 --「好きなことと生きていくための仕事は違う」という話が出てきますが、仕事を選ぶときに意識されていることはありますか? 気が進まない仕事は山のようにやってきましたが、人生で初めての仕事がちり紙交換だったので、後の仕事はどれを取ってもあの地道な肉体労働に比べたら楽だし優遇されている気分になります。意識しているのは、お金を稼ぐ目的で選んだ仕事とプライドを融合させないこと。生きるために選んだ仕事に対しては、

    【インタビュー】『テルマエ・ロマエ』作者ヤマザキマリさんが語る、とらわれない生き方とは? - ライブドアニュース
    torazuka
    torazuka 2014/05/30
    かっこいい。
  • 実況・実験ノート - うさうさメモ

    最近なにかと話題の「実験ノート」。実験をすることがある人には身近なものですが、そうでない方にはあまり馴染みのないものですね。うさじまも仕事でこういったノートを書くことがあります。今回、お料理を実験に見立てて実験ノートをつけてみることにしました。「ごちそうさん」でも、「料理は科学」と言っていましたしね。 なお、実験ノートの取り方については施設や研究室で色々なルールがあり、求められる厳密さもさまざまです。うさじまの場合、後に論文を書くとか、特許が…というより、「自分が再度実験するときのためのメモ」として書いている側面が大きくなっておりますので、「こんなの不十分だよ!!」と言われてしまうかもしれません。あくまで一つの例として寛大な心でご覧頂きますよう、お願いします。 実験ノートは誰にでも買えます 実験ノートと言っても、決まった書式があるわけではありません。が、改ざんや不正がしにくいように工夫され

    実況・実験ノート - うさうさメモ
  • 研究室リテラシー教育スライド

    研究室で新たに研究活動を始める学生への導入教育用スライドを数年使用しているものをアップロード。2014年度版。pptxだとpreviewでレイアウトがみだれるのでpdf版に差し替えました。Read less

    研究室リテラシー教育スライド
  • モヒカン宣言 - モヒカン族

    はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28

    モヒカン宣言 - モヒカン族
    torazuka
    torazuka 2014/03/26
    本物
  • 人前で発表するために声に出して100回練習してみた - nohdomi's blog

    人前でしゃべるのは当に緊張します。 そういう意識が生まれたせいか、年々、人前に立ったときの緊張がひどくなってきている気がします。 「いいことしゃべろう」「いい評価をもらおう」とする気持ちが、そうさせるんでしょう。 「相手にわかりやすくしゃべろう」として、そこに注力すれば、そんなの気にならないらしいですが、やっぱり、よく思われたい。(というか悪く思われたくない) なんでそんなことしたの? そんな人前で話すことが苦手な私に、また発表の機会がやってきました。 第3回「考える大人になるー教育のためのTOC」シンポジウム 200人近い人の前でしゃべります。(少人数でも緊張するんですけどね) コミュニティ活動の事例発表、その導入部だけなので3分程度ですが、何もしなければ、間違いなく番で緊張します。 発表のスライドが8割方できたところで、どうしたら番で緊張しない準備ができるか、 この辺(↓)を参考

    人前で発表するために声に出して100回練習してみた - nohdomi's blog
    torazuka
    torazuka 2014/02/27
    おつかれさまでした! / 量で心配を吹き飛ばせるんだ。ヤバそうな時はマネしよう。
  • ヒゲモジャのギークが提案する技術習得戦略

    先月、Dbtech Showcaseで松信さんがデータベース技術の羅針盤という講演をされた。残念ながらプレゼンそのものを観に行くことはできなかったが、その前の日に松信さんと一緒に昼飯をべたとき、講演のあらすじについては伺っていた。その際にも同じようなことを松信さんには言ったのだが、スライドを見直した上で改めて自分の意見をまとめておこうと思ったので筆をとることにする。 なお、このエントリではスライドに書かれているトピックについて語るので、まだ松信さんのスライドを見てない人は先にスライドに目を通してからエントリを読んで欲しいと思う。結論は全く違った方向に進んで行くが、その点は了承して頂きたい。 あなたに選択肢はあるか?ひと握りの天才なら自分の興味のある分野を開拓することができるだろう。あるいはすでに成功を収めた人であれば転職に困ることはないので、成功しそうな会社に乗り換えることもできるだろ

    ヒゲモジャのギークが提案する技術習得戦略
    torazuka
    torazuka 2013/12/03
    熱い! 自分も精進しよう。
  • 結城浩さんの「学ぶ姿勢」のはなし - Togetter

    結城浩 / Hiroshi Yuki @hyuki Twitterはとても楽しいんだけど、ずうっと眺めていると、物事の表面だけを見て「それ、知ってる」錯覚に囚われる。ヘッドラインだけ見て理解したつもりになる。自分の主戦場以外ならそれもいいけど、主戦場ではまずいよね。時間かけて資料やを読み込んで自分で試して考えていかないと。 2013-11-17 18:11:09 結城浩 / Hiroshi Yuki @hyuki 「時間をかけて」と書いたけれど、時間をかければいいというものではない。しかし、「時間がない」を理由にしてサボるのはよくない。必要とあらばたっぷり時間をかけることが何事につけ大事だと思っている。「お金は時間を買うために使う」のがよいと常々思っている。 2013-11-17 18:16:32

    結城浩さんの「学ぶ姿勢」のはなし - Togetter
  • 初心者レベルの言い訳をしない: 柴田 芳樹 (Yoshiki Shibata)

    出来上がったコードの可読性も含めた品質の悪さを、時間がなかったとかプロトタイプだからと言い訳する人がいます。スキルが高い人の場合は、同じ時間制約でも高い品質のコードを書きます。それは、ある程度無意識になるまで、訓練を重ねているからです。無意識になるまで意識して普段から活動するのです。 ソフトウェア開発ではないですが、熟練者と初心者の差を比較するために短時間でどれだけの成果が出るかを競うテレビ番組を時々見かけることがあります。必ず熟練者の方が量も質も圧倒的に初心者を凌駕しています。つまり、時間がなかったとかプロトタイプを言い訳にした時点で、経験年数に関係なく、初心者レベルだということです。 1988年に米国への赴任前の送別会で今は亡きS.Uさんに言われたのは、「与えられた仕事をこなして初めて次の難し仕事が与えられる」と言われたことがあります。逆に言えば、できないと判断されたら、仕事を与えない

    初心者レベルの言い訳をしない: 柴田 芳樹 (Yoshiki Shibata)
    torazuka
    torazuka 2013/09/11
    サンプルだからと例外処理を省いたコード見せたら「習慣としてその時点で書ける最高のコードを常に書け」ってじっちゃに怒られたの思い出した。とほほ…