有償のITカンファレンスに参加する意味を考える - Qiita
自分自身も、自分の周辺も、比較的有償のITカンファレンスに参加している人は多いです。国内・海外のものでも少し違いますが、お金という観点ではそれなりの金額がするものが多いですね。なぜこのようなカンファレンスに参加するのか、会社がお金を出すとしたらどんなことを考えてコストを出して送り出せばいいのかなど、考えを書いておきます。 そもそもセッション受講が目的なのか？ 最近のITカンファレンスのほとんどで、最終的に資料の共有や動画の公開があります。そう考えると、なぜ有償で参加する意味があるのかとも思いたくなるところですが、個人的にはセッション参加はITカンファレンスに参加する目的の１つではなく、比重の大きなものではないと考えています。そもそも、たくさんのトラックがあるカンファレンスにおいては、全てのセッションに参加することは不可能です。いずれにしても、参加の後で公開情報を元に継続学習することはセット
デザインを言葉で説明するの難しい問題 - 分解、検証、翻訳｜しばた / Fenrir Inc.
フェンリルのプランナーの柴田です。 デザイナーではない人にとって、デザインの良し悪しを判断するのは難しいものですよね。「なんとなく良い」「ピンとこない」まではわかるのですが、「なぜ良いのか」「なぜピンとこないのか」を言葉にするのは、それなりの経験と知識が必要となります。 しかし、そこをきちんと言葉にできないとデザイナーへのフィードバックは難しく、適当な指示で無駄な作業をお願いすることになります。何よりプランナーは自分でプレゼンすることが多く、デザインの魅力をクライアントに十全に伝えることができなくなります。この「デザインを言葉で説明するの難しい問題 」は、最もありふれていながら対処が難しい問題です。 今回はデザインの勉強もしていない僕が、どうにかデザイナーさんやクライアント様に対してデザインを言葉で議論する時の方法論を整理してみたいと思います。 デザイナーもデザインを説明するの難しい実はデ
LINE青田努さんの考え方が勉強になりすぎる！神パワポまとめ
青田努さんとは、人材業界出身者は知らない人はいないのではないでしょうか？ 私が青田さんを知ったキッカケはオンラインスクール「Schoo（スク―）」で講師を務められていたのがきっかけです。 青田さんのご経歴は早稲田大学大学院卒業後、リクルート、アマゾン、「日本の人事部」を運営しているアイ・キューなど様々な企業をへて、現在はＬＩＮＥにて人事を担当されていらっしゃいます。 まじでこれやと思ってます。 pic.twitter.com/gpyiyl7L1R — 融子 (@kinyuuchan) June 17, 2018 そんな、青田努さんの考えがツイッターでも10万程のイイネを集めている大旋風を巻き起こしています。ビジネスマンが是非とも知っておきたい学び、個人的メモの意味も込めて今回は簡単にまとめてみました。 青田さんのツイッターはコチラ 教え方がうまい人は何をしているのか？お客様、上司、部下に物
【保存版】Googleも採用する目標管理「OKR」を徹底解説！導入事例や運用ツールも紹介 | SELECK [セレック]
GoogleやIntelといった名だたる企業が導入し、書籍化もされたことで爆発的に広まった、「OKR」という目標管理のフレームワークを知っていますか？ 今回は、OKRって何？という初心者向けの解説から、その運用のコツ、企業における具体的な導入事例、さらにOKR向けのツールまでを、まとめてお届けします。 マネジメントや経営管理に課題をお持ちの方は、ぜひ、参考にしてみてはいかがでしょうか？ ＜目次＞ 【OKRとは？】OKRの仕組みや考え方を理解しよう 【OKRのメリットとは？】「MBO」との違いを知ろう 【OKRの運用事例】国内企業の事例を参考に、OKRの運用方法を知ろう 【OKR運用に役立つ海外ツール5選】効率的にOKRを管理しよう 【SELECKからの特典】「OKRパーフェクトガイドブック」 【OKRとは？】OKRの仕組みや考え方を理解しよう OKRとは、「Objectives and K
![【保存版】Googleも採用する目標管理「OKR」を徹底解説！導入事例や運用ツールも紹介 | SELECK [セレック]](https://cdn-ak-scissors.b.st-hatena.com/image/square/6d90cadc3d5ec1bb06c89545c30c658cac04c5e8/height=288;version=1;width=512/https%3A%2F%2Fdpd29bjwmgbr8.cloudfront.net%2Fwp-content%2Fuploads%2F2018%2F06%2F06192232%2F5087a4f1-b8a7-44ee-8be5-10fb8bb773ca.png)
プロジェクトをリードする技術 - kakakakakku blog
今日，社内勉強会で話す機会があり，過去1年間を振り返りつつ「プロジェクトをリードする技術」というタイトルにした．今回は参加者がエンジニアだけじゃなく，ビジネスチームのメンバーもいたため，できる限り，技術的な用語を使わないようにした．質疑応答とディスカッションもあり，1時間非常にワクワクした時間だった． 関連する領域 僕がプロジェクトをリードするときに意識しているのは，スクラムなど特定のプラクティスに依存しすぎないことで，チームの特性によって，関連する様々な領域からプラクティスを集めている．ザッと挙げるだけでも，こんなにたくさんある． チームビルディング ファシリテーション マネージメント 3.0 アジャイル (スクラム / カンバン / XP) 組織論 育成 心理学 メンタリング プロジェクトマネジメント 資料 過去1年間に取り組んだことを全て詰め込んだ！プレイングマネージャーとして頑張っ
IoTやめた
アー、今はDucaのアイの庭を聴いています。みなさんも聴きましょう。 仕事やめた IoTというのがあります。ご存知ですね。アレです。 IoTというのをやるのをやめたので、その話をします。 しないつもりでしたが、僕よりも数ヶ月早く辞めた人が退職エントリを書いていて、これはどう見ても続いていく流れだったので、やります。社名は出しません。 会社自体は決して悪い会社ではありませんでした。 福利厚生は充実していたし、（主に総務部の）社員の方々はとても活き活きと仕事をしていて、毎日ほぼ定時に帰宅している、そういう会社でした。各現場はまあ別ですが、これは会社の責任では全くありません。 IoTやめた IoT、アツいですよね、みなさんIT Proとか読んで大興奮してるでしょう、IoT業界はマジでフロア温まってます。 京都というか関西圏は大手製造業がメチャ多くて、既に売れるモノは持ってて、でも上司から新しいア
アプリの個人開発の終焉と新たな可能性 - ボクココ
ども、@kimihom です。 今回は私が今まで開発して来た個人開発と、そこで学んだ次の可能性について記していく。 個人で開発したアプリで食っていく 今でもちょくちょく個人開発をしている方をよく見かける。安定した仕事に勤めていた頃、私もその個人開発者のうちの一人だった。週末や空き時間があれば、ひたすらスマホアプリを開発し、私が作ったアプリの合計は十数個にのぼる。最初はゴミみたいなアプリを量産してたわけだけど、経験を積むにつれていいアプリを作る感覚を持てるようになって、１つだけ当たったアプリ(個人開発で15万DL 超えのアプリ)を作ることができた。この"当たるアプリを作る感覚"ってのは、アプリのアイディアそのものであったり、開発だけでないデザインやストアに掲載する文言やSEO、シェアされる仕組み、その他運用テクニックなど多様なものだ。 個人開発を可能にした背景に、スマートフォンアプリの流行が
コードレビューにこそ、コーチングのアプローチを適用するべきかも - little hands' lab
3つのコミュニケーションパターン 会社でコーチング研修があり、(主に部下と1on1を想定して)コミュニケーションパターンが以下の3つに分けられるという話がありました。 コーチング： 「答え」は相手の中にある 相手の話を聞く/問いかける/人となりを認める ティーチング： 「答え」はこちらにある 知識ややり方を教える/相手が理解してないことを説明する フィードバック： 成長を促すために、周りからどう見えているか、思われているかを伝える ポイントは 「いつもティーチングで自分が思うことばかり言ってしまってないか？アプローチには種類があることを認識し、適切に使い分けていこう」 という話でした。 これだけでもとても面白い話だったのですが、「これ、コードレビューでも同じではないか？」と思ったのです。 レビューにおけるティーチングとコーチング ティーチング ティーチングはいわゆる「指摘」です。 プルリク
「エンジニアリング組織論への招待」はいろんな立場の人に読んで欲しい - $shibayu36->blog;
最近メンタリング制度のことや、技術組織のことについて興味がある。最近「エンジニアリング組織論への招待」という本が出版されて話題になっていたので読んでみた。 エンジニアリング組織論への招待 ~不確実性に向き合う思考と組織のリファクタリング 作者:広木 大地技術評論社Amazon この本は、エンジニアリングで重要なのは「どうしたら効率よく不確実性を減らしていけるのか」ということと述べている。その考え方に従って、思考方法、メンタリング、チーム運営、組織運営といったプログラミング以外でのやるべきことについて、様々な背景も含めて教えてくれる。 全部読んでみたところ本当に良い本であった。メンタリングや組織運営といった、なかなか汎用化や言語化がしにくい分野を、納得のできる形で言語化されていて本当にすごい。僕は最近はメンタリング制度について考えているので、特にChapter2のメンタリングの技術の章が一番
Gaijin Engineer in Tokyo
Being a foreign software engineer in Tokyo has its ups and downs. If you work in a company of foreigners you’re mostly shielded from the experience, but if you work in an actual Japanese company there’s going to be some things that will shock you, some things that will amuse you, and doubtless many things that will frustrate you. This is a run-down of my own personal experiences. As with anything,
「CNNに目をつけられ、Appleが調べにやってきた」82歳のプログラマーのシンデレラストーリー | HRナビ by リクルート
Excelのマスに色を塗って、日本古来の文様を描きうちわやブックカバーを作っていた「パソコン手芸」の達人、若宮正子さん。 2017年2月に公開したiPhoneアプリ「hinadan（ひなだん）」がCNNに取り上げられ、6月にはAppleの主催する開発者イベントWWDCの基調講演にゲスト出演。そして2018年2月、ニューヨークの国連本部の会議へも招かれ、堂々と英語でスピーチを行った。あれよあれよという間に、シンデレラのような出来事が若宮さんに起こっている。 パソコンに出会ったのは退職後であるという若宮さん。遅いスタートのように思えるが、何が彼女の原動力になっているのか。これまでのITとの関わりとシニアが抱えるIT問題について話を伺った。 退職金でパソコンを購入。NIFTY-Serveでインターネットの世界へ ――初めてパソコンを買ったのはいつ頃ですか？ パソコンを買ったのは、40年以上勤めて
提案：エンジニアに気軽に「バグ」というのはやめませんか？ - worker experienceの日記
もしかしたら私だけかもしれないです。ずれているかもしれません。 一般論ではないかもしれません。 でも、同じような気持ちになっているエンジニアがいるかもしれないので、 代表して言わせてください。 エンジニアに、気軽に「バグ」と言うのをやめませんか？ 最近立て続けに以下のようなことが起こっており、私と同僚が消耗しています。心がすり減ってます。ワーカーエクスペリエンスが低下しています。。。 ～～～～～～～～～～～～～～～～～～～ 「○○さん、この数値がバグなんだけど直してもらえる？」 →調べたらその週は祝日影響で、営業日が少ないだけだった。 「あのデータのバグはいつ直りますか？」 →データの集計定義の変更の依頼があり、変更前の状態をバグと呼ぶ 「この前入ってなかったバグなんだけど、次の開発に入れてもらっていい？」 →スコープ外のこと（担当がそれを忘れていた）をバグと呼ぶ ～～～～～～～～～～～～
ジュンク堂書店池袋本店の長田さん！ いま、どんなコンピュータ書が売れているんですか？ - GeekOutコラム
ジュンク堂池袋本店の2017年販売冊数ランキング（太字が2017年内の刊行） ── 今でも『リーダブルコード』がランキングの上位に入っているあたりは、さすがですね*1。8年連続でCPU大賞を受賞された売り場だけあって、顧客はやはりコアなエンジニアの方が多いのでしょうか。 長田 ありがとうございます。ジュンク堂の売り場では、年間ランキングのような数字で追える売上だけでなく、ロングテールの部分をより重視しています。端的にいえば、「ほかの書店では品切れしていても、ジュンク堂に行けば置いている」という状態を目指して売り場づくりをしています。 これはコンピュータ書に限ったことではなく、ジュンク堂は経営理念に「愚直なまでに”本と文具”の品揃えにこだわります」ということや「“図書館よりも図書館らしい”店づくり」を掲げていて、ジュンク堂でしか買えない本を置くことを意識しています。 とくに池袋の場合、駅近の
「中年の危機」ど真ん中のオッサンがWEBサービス作ってみた。 - Qiita
自己紹介 こんにちは。 Hirozといいます。 タイトルにある「中年の危機」は、かっこよく言えば「ミッドライフ・クライシス」と言うそうです。 私は、そんな中年の危機ど真ん中の文系非エンジニアのアラフォーおっさんです。 35歳くらいから「このままでいいのか」と思うようになり、葛藤の迷宮に入り込んでしまいました。 今もまだ抜け出せていません、たぶん。 その過程で「組織の肩書きによらない素の自分の力でやってみたい」、「直接人の役に立つ実感が得られることがしたい」と思うようになり、それを具現化する手段としてWEBサービスを造ってみたいと思うようになり、2017年12月にWEBサービスをリリースしました。 自分でプログラミングを習得しながら作るぞと思ったのが2017年の2月。 開発環境作りなどのトラブルに翻弄され、本格的にコードを書き始めることができたのは2017年の5月末。 そこからコツコツと開発
エンジニア歴20数年の私が、設計書を書く際に心がけていること - Qiita
はじめに 時の経つのは早いもので、私がIT業界に身を置いて四半世紀になってしまいました。 その間、膨大な数の「設計書（仕様書）」を書いて来ましたが、未だに悩み・迷いは尽きません。 それでも、亀の甲より年の劫とも申しますので、私なりの経験則を「個人」と「チーム」の両観点でまとめてみました。 本稿のテーマは、「主に設計書を想定した、開発ドキュメントの書き方」です。 本稿で前提とする設計書は、ExcelやWordで書かれた、フォーマルな（≒納品物になりえる）設計文書、です。 したがって、自社サービス開発よりも受託開発、アジャイルよりもウォーターフォール、を前提として読んでいただいた方が、しっくりくると思われます。 ＜ご注意＞ 本稿の内容は執筆者独自の見解であり、所属企業における立場、戦略、意見を代表するものではありません。 個人的に心がけていること 当該文書の作成目的や位置付けを冒頭に記載する
僕は僕にどういう教育を授けたか - 怠惰を求めて勤勉に行き着く
まえがき 会社の若い子に「情報系出身でもないのに一体どうやって勉強してきたんですか？」と聞かれたのでランチを食べながら「こんな本読んだ。これもタメになった。あ、これもタメになった」とKindleを広げながらリストアップした。思い返せばたくさん本を読んだ。その中には役に立ったものもあれば時間の無駄だったものもある。すると「あ、役に立った本だけ抽出したら有益かもしれないな」と思ったのでエントリにする。 僕は文章を簡潔に分かりやすくまとめる才能が致命的にないのでこのエントリもげっそりするほど長い*1が、2017年も暮れなのでここはひとつ日本酒でもかっ喰らいながら自分の人生を振り返ってみようと思う。 無理やり要点をまとめるならば、 TCP/IPの知識 Linuxの知識 なにかひとつプログラミング言語 なにかひとつGUIシステムの理解 アルゴリズムとデータ構造 強運*2 を身につけたらどんなに低く見
深く考える訓練、その1｜深津 貴之 (fladdict)
大学の授業用のサブ教材として、生徒に「深く考える」トレーニングの資料を作ってる。 思考力というのは、トレーニングで伸ばすことができる。トレーニングでは、まずは自由な思考よりも、フレームワークを使い倒すことが重要だ。数をこなせば、考えることが苦ではなくなる。それが一番重要だと思う。基本的なトレーニングができていない状態で、自由に発想させても、大半の人は途方にくれてしまう。 ここでは何回かのシリーズを通じて、段階的に複雑なことを思考するためのフレームワークを紹介していく。 まず第1回目は、シンプルで誰でもつかえるフレームワーク、The Five Whys（5つのなぜ？） だ。 「5つのなぜ？」ものごとについて、5回「なぜ？」と深堀りをする。 The Five Whys（5つのなぜ？）は、たったそれだけのシンプルな思考ツールだ。 大抵の人間は、2〜3段階深く以上ものごとを考えられない。いままでの
なぜ製品仕様を合議制で決めてはいけないのか。
プロダクトマネジメントにおいて「製品仕様を合議制（多数決）で決めてはいけない」というルールがあるが、それは何故なのか。そして、だとしたらどのように人の意見を取り入れるのが良いのか、を考えてみた。 なぜ製品仕様を合議制で決めてはいけないのか。合議に参加している人たちは、その問題の責任者ほど制約条件や問題の背景を深く理解をしていないから。合議制や多数決で物事を決めると、必ずその結果に満足している人たちの方が満足していない人たちよりも多くなる。これは素晴らしい手法だ。 しかし、製品開発の目的は社内の人を満足させることではない。正しい製品をつくることだ。製品にとっての正しさとは、「その製品を顧客（市場）が求めていること」であり、これを満たすためには様々な調査や知識が必要だ。 製品仕様のように、問題の複雑さが一定を超えると、知識を持っている人と持っていない人の意見に違いが出始める。世の中（「社内」と
仕事に役立つ軍事ドクトリン｜深津 貴之 (fladdict)
軍事ドクトリン（原則）や戦略書、兵器の変遷史などを読むのが好きです。 戦争が好きなわけではなく、とても勉強になるからです。戦争というのは、有史以来、全文明がもっとも真面目に研究し、アップデートを繰り返してきた分野です。なので、最も合理的かつ実践的なノウハウが詰まっています（軍事が合理的でない国は、だいたい滅びました）。 これらの知識を、応用ができることはいっぱいあります。限られた時間やリソースでの意思決定や、ライバルとの競争、団体競技などなど… 以下は、ジョン・フレデリック・チャールズ・フラーという、英国陸軍の人が提唱する陸戦原則。この原則は、世界中の陸軍教練に広く取り入れられています。デザインやビジネスなどでも、非常に使い勝手良いかなと感じています。 （上のリストは、厳密にはフラーのオリジナルでなく、彼のセオリーから米軍が作った改訂版「1986年版の米陸軍の野戦教範100-5」ベースの、
勉強会聴講：「エンジニアとしてこの先生きのこるために」 - Qiita
この記事は JustSystems Advent Calendar 2017 の 19日目の記事です。 初めに この記事は、サポーターズCoLab主催イベントの和田卓人先生の講演「エンジニアとしてこの先生きのこるために」の聴講記録です。 主催：サポーターズCoLab 講演者：和田卓人さん(@t_wada さん) 題目：「エンジニアとしてこの先生きのこるために」 聴講のきっかけ：新人研修で一度紹介して頂いていて講義内容に興味をもっていたため 参考資料 私が研修中の時は、スライドが公開されていませんでしたが、今年の6月5日に以下で資料が公開されています。 講義スライド このスライドだけでももちろんためになるので、講演中にあった補足の話を中心に記述していこうと思います。 テーマ1：エンジニアとしての基本姿勢とは？→「学び続ける姿勢」 原則は現役（いつでも使える）、ただし要素は廃れていく 同じもの
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
