タグ

考え方に関するkei_yam1209のブックマーク (49)

  • ロシアの天才ハッカーによる【新人エンジニアサバイバルガイド】 - Qiita

    弊社に5年間在籍していたロシアの天才ハッカーが先日退職しました。 ハッキング世界大会優勝の経歴を持ち、テレビ出演の経験もある彼ですが、正直こんなに長く活躍してくれるとは思っていませんでした。彼のようなタレントが入社した場合、得てして日の大企業にありがちな官僚主義に辟易してすぐに退職するか、もしくはマスコットキャラとして落ち着くかのどちらかのケースがほとんどなのですが、彼は最後まで現場の第一線で活躍してくれました。 そんな彼が最後に残していった退職メールがなかなか印象的だったので、その拙訳をここに掲載します(転載について人同意済み。弊社特有の部分は一部省いています。) ああ、なんという長い旅だったろう。この会社で5年間もセキュリティを担当していたよ(諸々の失敗は許してくれ) 俺は他の退職者のように面白いことは書けないが、私のこの退職メールを読んでくれている人、特に新人エンジニアのために、

    ロシアの天才ハッカーによる【新人エンジニアサバイバルガイド】 - Qiita
  • アイデア大全ー57の発想法/思いつくことに行き詰まった時に開く備忘録

    「アイデアの作り方」が気になるのは、普段とは違ったアプローチが必要になる時、つまり、いつものやり方では間に合わない時/行き詰った時だ。 以下のリストは、そうした行き詰まりに突き当たった際に眺めてみる備忘録として作成した。 同じアイデアを作るといっても、どの段階にいるかによって必要な手法は異なる。 すでに方向性が決まっている場合や、まるで何も思いつかない場合、数だけはたくさん出たがどうやってまとめるのか途方にくれている場合など、一口に「アイデアの作り方」といっても、それを適用する場面もそれに使う手法もいろいろである。 そんなわけで、段階順に整理したほうが、使いやすいリストになると考えた。 以下ではアイデア作成プロセスの段階に応じて、アイデアの作り方を分類して配列した。 大きくは、前半にアイデアを増やしていく拡散系ツールを置き、後半に増えた(増えすぎた)アイデアをまとめ/しぼりこんでいく収束系

    アイデア大全ー57の発想法/思いつくことに行き詰まった時に開く備忘録
  • 起業して10年たったので、重要だと思ったことを記念に書きたい

    10年前起業をした。 通常は、企業の生存率は10年で10%位だろうか。 私は、どちらかというと綿密に事業計画書を書いて起業をしたというより情熱に動かされて起業をした。 いうまでもなく緻密に計画を立てて起業をしたのではないから、起業した初年度に役所からくる初めて見る諸々の納付書など、送られてくるたびにまた支払いがあるのかとビクビクしたものだ。 時にはキャッシュフローについて日夜考えすぎて、頭がハゲて、病院嫌いにもかかわらず皮膚科に行き、やる気のない態度の悪い医者にハゲ薬をもらい、治したことも今となっては微笑ましい思い出だ。 もともと自分自身には才能があるとは思わない。だが、起業をしてかつ継続するにあたり 大切だと思ったことを記念に書いておきたい。 ■■信念 やはり一番重要なのは信念(Faith)だと思う。 なぜかというと、クライアントの要望やプロジェクトメンバーの意見など常に相対的で、移ろい

    起業して10年たったので、重要だと思ったことを記念に書きたい
  • IT企業10社に聞いた、マネジメントを学んだ「良書」とは | nanapi [ナナピ]

    2020年8月31日(月)をもちまして、nanapiに関わるすべてのサービスは終了いたしました。 nanapiは、2009年のサービス開始より「みんなで作る暮らしのレシピ」という考えのもと、ユーザーの皆さまに生活に関する様々な「ハウツー」を投稿していただく投稿型ハウツーサービスとして運営してまいりました。 約11年間にわたって皆さまからご支援をいただきサービスを継続できたこと、nanapi編集部一同、心より御礼申し上げます。 掲載されていたコンテンツなどのnanapiについてのお問い合わせは、nanapi@supership.jp までお願いいたします。 長きに渡りnanapiを応援してくださり、当にありがとうございました。

    IT企業10社に聞いた、マネジメントを学んだ「良書」とは | nanapi [ナナピ]
  • 俺が考える最強の新規サービス開発フロー - 小さなお城

    インターネットサービスを想定した理想を書いてます。 エンジニアリングに特化した話ではなく、アイディアを思いついてからリリースするくらいまでの浅く広い話で、個人的な趣向であり、組織や環境によっては合わないかもしれません。 とりあえず、リーン・スタートアップとアジャイルサムライ−達人開発者への道−は、すごくいいで勉強させていただきました。 アイディアを整理します 実現したいアイディアが解決するユーザプロブレム、提供する価値を整理します。 例えば、 ● ユーザプロブレム: お腹いっぱい美味しいものをべたい! ● 提供する価値  : 安くて美味しくて腹持ち良いべ物屋さん アイディアの簡単なペルソナを想像します ペルソナとは提供するサービスの一番の顧客になってくれる人の人物像です。 例えば、 G太、小学1年生男児。体重40kg。 頭はおにぎりのような形をしており、10円ハゲがある。 小学校では

    俺が考える最強の新規サービス開発フロー - 小さなお城
  • ブレストをやめて、ペイン・ストーミングを始めよう - 小さなごちそう

    問題解決をスムーズに行うために、ソリューションではなく問題構造を明らかにしようという記事を書いた。まず顧客課題を明らかにしないと、ソリューションが適切かどうか判断することができない。 とはいえ人間の習慣はなかなか変えられないので、複数のメンバーでブレストをしているとどうしてもソリューションのアイデアを出し合う場になってしまう。 そういう時は、ペイン・ストーミング(Painstorming)を試してみよう。 ペインストーミングは次の4つのステップで問いかけを行う。 ※ペイン(PAIN)の頭文字になっている。 Person 誰の課題を解決するのか。 Activities 彼らは毎日行っていることは何か、そしてその結果はどうなるのか。 Insights 目的達成のために次善策として工夫していることは何か。彼らが仕方なく行っている行動やプロセス、仕方なく使っているツールは何か。 Needs 顧客の

    ブレストをやめて、ペイン・ストーミングを始めよう - 小さなごちそう
  • ふりかえりで初心者が陥りやすい落とし穴 〜 性格も実力も急に変えられないが行動は改善できる | Social Change!

    私たちソニックガーデンでは、現場での人材育成の手段として個人の「ふりかえり」と、そのレビューを行っています。それを「ワークレビュー」と呼んでいますが、仕事の進めかたや、仕事に対する姿勢についてふりかえった内容を、メンターがレビューすることで行動の改善と成長を促します。 進めかたとしては、まずは対象者が一人で良かったこと(Keep)や問題(Problem)について洗い出しを行うのですが、ふりかえりに慣れていない初心者がつまづいてしまう様子を何度か見てきました。この記事では「ふりかえり」で、よく陥りやすいパターンと、その解消法について書きました。 自分の内面のことを問題にしてしまう ふりかえりをして問題を洗い出すときに、慣れていないと、ついやってしまうのが自分の内面や性格のことを問題としてあげるケースです。 たとえば、思っているよりも成果を出せていない、それは躓いたときに先輩に相談できてないか

    ふりかえりで初心者が陥りやすい落とし穴 〜 性格も実力も急に変えられないが行動は改善できる | Social Change!
  • エンジニアの「できない」という言葉の裏側 - Konifar's WIP

    「ここ、こんな感じにできませんかね?」と言われたエンジニアが、「うーん、それはちょっと厳しいですね。できないです」と返すみたいなやりとりは結構見かけます。 この「できますか?」⇒「できない」というやりとりなんですが、「できない」という言葉にはいくつか裏が考えられます。言葉足らずだっただけでちょっとした調整をすればできるよね、というケースもあるので、「できない」という言葉の裏側をまとめておこうと思います。 先に補足しておくと、「エンジニアの人の言葉が足りなすぎるでしょ」という意見ももちろんあると思います。こういうコミュニケーションは、お互いの信頼度によっても変わってくるので難しいところです。お互いが相手に伝わるように意識すべきだと思うんですが、 エンジニアから「できない」と言われた時にどういう意味で言ってるのか想像しやすくなればいいなという思いで書いておきます。 ちなみに、「(できるけどやり

    エンジニアの「できない」という言葉の裏側 - Konifar's WIP
  • エンジニアの為の、アイデア効率化 - Qiita

    今回は、サービス作成作りのための効率的なアイデアメイキングということで書きたいと思います。 今までのハッカソンの中での経験から、アイデア出しの手法について共有したいと思います。基的にはWebに載っているものが多いですが、独自の手法や既存の手法を改造したものなどもありますので、ぜひチェックしてみてください。 また、今回はお金がかからずに、すぐできる手法を集めました。各アイデア出し用のアイデアシートも作成したので活用してみてください! アイデアメイキングとは? アイデアメイキングは、アイデアの種を思いつくところから、具体的なアイデアとして醸成するところまでをいいます。 主なアイデア出しの段階をあげると、以下のようなものがあります。人によってアイデアの出し方の順番は前後しますが大体下のようなことを知らないうちに考えていることが多いです。 アイデアメイキングの段階 種探し テーマ探し 発散 収束

    エンジニアの為の、アイデア効率化 - Qiita
  • マイクロサービスアーキテクチャとは何か - arclamp

    マイクロサービスアーキテクチャ(以下、MSA)という言葉を聞くようになりました。きっかけはファウラーのブログ「Microservices」(2014年3月)ですが、昨年10月のJavaOne SFでも多くの講演でMicroservicesという言葉を聞かれ、多くのエンジニアがすぐに共感していたことが分かりました。今後、日でも広く知られる言葉になることでしょう。 一方でMSAは誤解を招きやすいバズワードとも言える気がします。というわけで、僕なりのMSAについての考えをまとめてみました。 MSAは「優れたウェブサービスを観察したところ同じようなアーキテクチャだったので、それをマイクロサービスアーキテクチャと名付けた」というものです。逆に言えば「大きなウェブサービスを作ろうと思ったときの定石」といえます。「各要素を疎結合に構成し、連携する」「それぞれの要素に適した技術を使う」といったアイデアは

    マイクロサービスアーキテクチャとは何か - arclamp
  • 「これって、ドメイン駆動設計?」という資料を公開しました。 - GoTheDistance

    いくら人の話を聞いてもピンと来ないし、DDDを読んでも全然頭に入らないので、自分なりに解釈してまとめることにしました。よろしければ、どぞ。 これって、ドメイン駆動設計? from Michitaka Yumoto www.slideshare.net ドメインからモデルを抽出→モデルの振る舞いと情報を定義→サービスに汎化させる、という流れを取っています。行間多めです。さーせん。 ドメインというのは、どうも2つの性質を持っている言葉のようだと思いました。 その世界で現状行われていること 行われていることに対する希望や不平不満からくる要求(関心事と言うらしい) 上記の定義がだいだいあってるとすると、「その世界で現在進行中の物事及びそれに付随する要求をキチンと実装できる設計にしようぜ」って話がドメイン駆動設計の総論で良いのでは、というのが1つ。 で、ドメイン(特にいまやってる物事)を抽象化す

    「これって、ドメイン駆動設計?」という資料を公開しました。 - GoTheDistance
  • 7年働いた時点での私の仕事の極意 - Kengo's blog

    最重要 実行に重きを置く やらないで後悔するよりも、やって反省する。 反省は成長を産み生産的だが、後悔は精神の無駄な消費。 時間は有限で貴重な資源だが、たぶん今の段階では行動する前に得るものや結果を予測するのは難しい。 正しい反省の方法とは何か、考え続けること。 「正しく反省するために、何を記録しておくべきか」実行前に明らかにしておくこと。 反省の結果は組織的な何かに落としこむ。組織構造、戦略、静的解析、自動テスト、教育など。意識しないでも巨人の肩に乗れる状況を作ることが、組織の成長につながる。 Done is Better Than Perfect ただし、思考停止の言い訳にしないこと。詰めの甘さを擁護する言葉ではない。詰めの甘さは立場や考え方が違うひと3人くらいに意見を求めればだいたい炙り出せる。 長期的視野を持ちつつ、それに引っ張られない。進展を作ること、現状を少しずつ変えることを意

    7年働いた時点での私の仕事の極意 - Kengo's blog
  • ○○したら受託開発が180°変わった(10分版)

    以前XP祭りでLTしたものの10分版。 「せっかく作った物が喜んでもらえない」 「仕様だ、バグだ、の不毛な争い」 「振り回されて疲弊するエンジニア」 など、受託開発でうまくいかない局面は多くあるが、ある一つのことを意識的に行うようにしたら、自分たちの受託開発が180°変わった、という話。

    ○○したら受託開発が180°変わった(10分版)
  • 「リーン」について : 「何を作るか」よりも「何を作らない」か - naoyaのはてなダイアリー

    2013年に「リーン・スタートアップ」という書籍が出版されて、それからリーン (LEAN) という考え方に注目が集まるようになった。LEAN とは「無駄のない」とか「ぜいにくのない」とかそういう単語らしい。 書籍リーン・スタートアップには「スタートアップやその類が新しい事業を始めるときに普通にやってるとだいたい失敗するから、潜在顧客や顧客からのフィードバックをこまめに集めて軌道修正しながらゴールを見極めるやり方が良い」とか、雑にまとめるとそういうことが書いてる。 仮説を立ててフィードバックをもらって検証するということを短いイテレーションで繰り返す・・・というのを "フィードバックループ" と呼んでいて、それを細かくやる場合、製品を作り込んでからフィードバックをもらうのでは遅いし、例えばペーパープロトタイプをするとかそういう実験的なことで欲しいフィードバックが得られるならそれが一番いい ─

    「リーン」について : 「何を作るか」よりも「何を作らない」か - naoyaのはてなダイアリー
  • 【社会人必見!】世界トップクラスの成功者が、初対面で必ず行う7つのコト

    成功者。 彼らに共通するのは、優秀であること、努力家であること、それぞれの分野で道を究めていること、そして、運も味方につけられること――。 成功者たちはまた、往々にしてビッグネームにふさわしい威風堂々たるイメージを持ち合わせている。 しかし、その成功者の中でも、歴史に名を残すようなトップの中のトップたちに初めて出会った時に受けるのは、実は全く違った印象だ。 もっとフレンドリーで、自然体で、そして、頼りなげでさえある。 いわゆる「成功者」が自身だけの力でその地位をつかみ、偉業を成し遂げるのであれば、「トップ成功者」たちは、多くの人たちの力を借りて、更に大きな偉業を成し遂げる。 「成功者」がその道の天才ならば、「トップ成功者」はその道の秀才でも凡人でさえもいい。しかし、人を巻き込む大天才である。 そう、まぎれもなく、トップ成功者たちが持っているのは、 ・人を共感させる力、 ・圧倒的に周りを吸引

    【社会人必見!】世界トップクラスの成功者が、初対面で必ず行う7つのコト
  • MMORPGで考えるゲームデザイン(2014年改訂版)

    (株)Aimingの社内勉強会のスピーチで使用したスライドです。公開に当たって画像を削除しております。ご了承ください。 ・目次 1 MMORPGの成立 Ultima Online、Ever QuestからWoWまで、MMORPGの成立とゲームシステムの変遷 2 行動のデザイン プレイヤーの動線で考える→システムとコンテンツの配置 時間軸で考える→ゲームの成長曲線 成長スピードの緩急/プレイタイムからの逆算 3 今日的なMMORPGの形(←2014年版追加) 今日のスマホのゲームMMORPGのデザインがどのように生かされているか ・概要 ネイティブアプリのリッチ化や、「剣と魔法のログレス」などのヒットにより、MMORPGや常時接続型のオンラインゲームが再び今日的なテーマとして脚光を浴びています。 そこで、オンラインのゲームデザインのエッセンスが詰まったMMORPGというジャンルを分解し、そ

    MMORPGで考えるゲームデザイン(2014年改訂版)
  • programming - コードを書き続けるためにやってること - Qiita

    プログラミングの生産性を上げるには - Cside::Private とても面白かったのでマネしてみた。人それぞれあると思うので自分のスタイルを。 といっても、かなり不真面目なので参考にはならないと思う。 1 . README.rst を書く まず最初に何がしたいのか、どんなことをしたいのかを書く 概要、ゴール、実装方法、使用ライブラリ、TODO などを書いていく そして README.rst に擬似コードを書き始める コンパイルが通る必要は無い コメントもガンガン書いていく とにかく issues とか使わず全て README.rst に書いていく 一通り出来てきたら Trello にタスクを移す 2 . 擬似コードでプロトを書く コードを書いてみないと分からない事が多いのでまずはコードを書く よく iPhone でコードを書いているのだが、オレオレ言語で書いている Erlang っぽい

    programming - コードを書き続けるためにやってること - Qiita
  • モデルやメソッドに名前を付けるときは英語の品詞に気をつけよう - Qiita

    はじめに 他の人が書いたコードを読んでいるときに時々気になるのが、英語の間違いです。 特に動詞、名詞、形容詞の使い分けが間違っていたりすると、かなり違和感を感じます。 そこで今回はモデル(=クラス)やメソッドに名前を付けるときの基的な原則をまとめてみます。 また、英文法的に正しい品詞が選べるようになるための習慣についても最後に説明します。 想定する言語/フレームワーク この記事の説明ではRuby/Ruby on Railsを想定しています。 ただし、基的な考え方は他の言語でも同じように使えるはずです。 モデルの名前は名詞にする 例: 「支払い情報」を表すモデルを作りたい場合 × Pay ○ Payment 「支払う = payか。よし。」でモデルを作ってはいけません! payは動詞で、payの名詞形がpaymentです。 Payモデルではなく、Paymentモデルを作りましょう。 例:

    モデルやメソッドに名前を付けるときは英語の品詞に気をつけよう - Qiita
  • 【UNITE JAPAN 2014】「コンセプト⇔ゲームデザイン どう合わせる?」…ゲームにおける「面白さ」を分解して、様々な角度から見つめ直す本講演 | gamebiz

    【UNITE JAPAN 2014】「コンセプト⇔ゲームデザイン どう合わせる?」…ゲームにおける「面白さ」を分解して、様々な角度から見つめ直す講演 ユニティ・テクノロジーズ・ジャパン合同会社は、2014年4月7日、8日の2日間にわたり、Unity 最大のカンファレンスイベント「UNITE JAPAN 2014」を、ホテル日航東京で開催した。当日はプロの開発者を対象としたものから、ビギナー向けの簡単なものまで、Unityに関する30以上の講演が実施。 稿では、ユニティ・テクノロジーズ・ジャパン合同会社の簗瀬洋平氏が登壇した、「コンセプト⇔ゲームデザイン どう合わせるか?」の模様をレポート。ゲームにおける「面白さ」を分解して、様々な角度から見つめ直す講演内容となった。 ■「面白い」って? 講演を務めるゲームデザイン研究者の簗瀬氏は、これまで多くのシミュレーションRPGのほか、人気アクショ

    【UNITE JAPAN 2014】「コンセプト⇔ゲームデザイン どう合わせる?」…ゲームにおける「面白さ」を分解して、様々な角度から見つめ直す本講演 | gamebiz
  • 仕事がうまくいく人は、この8つのムダ思考を捨てている | ライフハッカー・ジャパン

    習得れば家具も作れる! 自宅でDIYを実現してくれるCNC加工ロボット「Cubiio」を使ってみた 『たった5秒思考を変えるだけで、仕事の9割はうまくいく』(鳥原隆志著、中経出版)の特徴は、「思考を加える」ではなく、「思考のムダを捨てる」という観点から仕事の仕方を解説しているところ。「発想しすぎの思考や能力を引く」考え方にシフトし、仕事の成果を変えていくことを提案しているのです。 ちなみに基盤となっているのは、「インバスケット(案件処理演習)」の考え方だとか。第3章「たった5秒で成果が出る『インバスケット』」に目を向けてみましょう。 1.「どう思われているか?」を捨てる 体裁に力を入れすぎると、来するべき仕事ができなくなるもの。たとえばメールのタイトルに多くの時間をかけても、内容がわかりづらかったり、ファイルを添付し忘れていたりしたら台なしです。大事なのは、体裁よりも内容だということ

    仕事がうまくいく人は、この8つのムダ思考を捨てている | ライフハッカー・ジャパン