日本のITはなぜ弱いのか？ 日米でこんなに違うプログラマーの扱い - まぐまぐニュース！ 確かにその通りで、やはりエンジニアは言われたものを作る職業という認識をされているケースが多いです。最近のエンジニアが主体となったベンチャー企業などでは変わってきているとはいえ、業界の割合でいえばごく一部といえると思います。 上記の記事にもある通り、サラリーマン経営者による個人の責任を極限まで減らした意思決定を行いそれによってプロジェクトが遂行されることが正義とされてしまうと、どうしてもエンジニアとしてのクリエイティビティを出すチャンスは減らされてしまいます。これに対してどう向き合えばいいのかを考えてみました。 なお、英語学んで海外に行けばいいじゃないかという個人にフォーカスした視点はいれません。 IT人材の人数は2019年がピーク IT人材の育成（METI/経済産業省） こちらのデータを見る限り、20
ottiee.hatenablog.com 同僚のデザイナーが良いことかいてました。最近は採用活動には携わっていないのですが、以前に似たようなことを採用において感じたことがあったので書いてみようと思います。 不慣れな人ほど落とす 私自身も面接官トレーニングというものをちゃんと受けたことがあるわけではないので、いわゆる「正しい面接」というものをできているかどうかはわかりません。 ただ、過去にやっていた採用活動においてまずよく起こるのが面接に不慣れな人ほど簡単に人を落としてしまうということでした。 なぜそうなってしまうのか。理由としてはシンプルで、通すことよりも落とすほうが簡単だからです。相手の嫌な部分やダメな部分なんて自分が思い込んでしまえば簡単に作ることができるので、落とす面接は簡単に仕上がってしまいます。場合によっては単純な好き嫌いだけで合否を決めてしまうこともある。1の良いところをみつ
anond.hatelabo.jp コメントも含めこれを読んで思ったことを書いてみようと思います。 業務改善を求めてはいけないのか？ まず、業務改善は上司だけの仕事ではありません。そもそも上司といってもチームによって期待されているロールが分かれているんで一概に言えないと思います。 そして業務改善は現場の協力無しでは出来ないので、何らかの協力を仰ぐことは必須です。ただ、問題はどこまでを上司が行ってどこからを現場で行うのかという点なのかなと思いました。例えば以下のような方法です。 人が辞めてしまい、業務負荷があがっている リソース不足ではあるが、あきらかに業務効率が悪い点があった ○○の問題を解決したいので、それを実現するための方法は何かないだろうか？ というような話の流れであれば、返答のパターンは以下の3つくらいだと思われます。 その方法を試したいので、○○という手法を導入したらどうか そこ
最近また管理画面に近いものをつくったりしていて感じたのですが、事業会社において管理画面がどのタイミングで実装されているかというのがすごく重要だなと感じたのでちょっと書いてみようと思います。 社内向けの管理画面の実装って割と後に回りがちで、最後に仕方なくなんとか実装するようなケースが多いと思うんですよね。そして、ある程度発生してきたオペレーションの実態に合わせて実装するみたいな流れになるのではないかなと。 それはそれで一つの実装の手法だと思うのですが個人的には逆のほうが良いのではないかなと思っています。 管理画面からオペレーションを設計する まず、以下の理由から管理画面ありきでオペレーションを設計したほうが良いと思っています。 既存のオペレーションありきで管理画面の要件を出すため、イノベーションがうまれづらい 組織の最適化より管理画面の最適化のほうが合理的に行える エンジニアの合理的な思考が
nobkz.hatenadiary.jp 昨日だが、このエントリーがバズっていて僕自身もtwitterでいくつか言及した。twitterってその場の思いを素早く伝えるのは非常に便利なんだけど、コンテキストが重要なものが説明しづらいとか、フロー的な情報という問題もあるため改めてブログに書いてみる。 率直な感想 まず、彼自身がCTOじゃなく１人のエンジニアとしてこの会社にジョインしていたのであればまぁわかるよという内容だ。エンジニアとしての美学を追求し続けたけど、それじゃビジネスが立ち行かなくなった。俺のことをわかってくれるVCが日本にはいない！ まぁここまではよくある話だと思う。誰もが失敗はするし、最初からうまくいく人なんてごく少数だと思う。問題は、この事自体を環境のせいにしているということだと思う。 技術的負債を早く返しすぎたのが失敗と書いてあるが彼がそう感じているのであればそうなんだ。た
すでにメディアで取り上げられているのでご存じの方もいると思いますが、本日このような発表をいたしました。 http://nanapi.co.jp/news/133 変わること 「変わることと」表現していますが、我々がもともとやろうとしている「What」の部分が変わるわけではありません。あくまで「What」を叶えるための「How」の部分が変わるだけです。 株式会社nanapiは「できることをふやす」というミッションを掲げています。そのミッションをいかにして達成するのかを考えた結果、もっとも最適な選択肢として今回の結果になりました。 http://www.syndot.jp/ 変わらないこと 連結子会社となっていますが、株式会社nanapiとしては基本的にやることは変わりません。我々が運営するnanapi.jpやアンサーに関しても今までどおり運用し続けますし、これからもよりよいサービスになるよう
社内の情報共有で困っている会社は多いみたいですね。でも実は、nanapiという会社ではそこまで困っていなかったりします。元々文章を扱う会社というのもありますし、ドキュメント化して共有しようという風土が染み付いているからだと思います。 そういったこともあり最近登壇するときなど、社内の情報発信などについて話す機会が増えました。弊社では社内における情報共有のツールとして、Qiita:Teamを使用しています。 生産性を向上させる情報共有ツール - キータチーム（Qiita Team） 全員がMarkdownで文章を書く 実際にnanapiではQiita:Teamを導入してから、現在ではエンジニアだけでなくアルバイトも含めた全社員がここに様々なドキュメントを投稿しています。 Qiita:TeamはMarkdownで書けるようになっています。つまり、社内のメンバーは全員がMarkdownで文章を書く
【StartupWeekendTokyo x DevLOVE】イケてるスタートアップの開発現場の話が聞きたい！ - スタートアップウィークエンド東京 | Doorkeeper というわけで、話してきました。資料はこちら！
個人的なShellTipsをまとめてみた - UNIX的なアレ 以前に話題になったネタでこんなエントリーを書きましたが、どうならもっといろいろな人の話を聞いてみたいよね、というわけでid:sotarokと話しててこの勉強会をやることになりました。 もともとのコンセプトとしてはshellのウルトラなテクニックを紹介するというよりも、なんかイマイチ使いこなせてない感がある人とか、めんどくさい作業をめんどくさいと感じずにやっている人向けな内容です。 そんなわけで、私が発表した内容は以下のスライドです。 なんか途中からemacsの話してるんですけど、emacsは概念だしレイヤーが違うので特に問題はありません。なおやさんもemacsの話してたし。 その他、当日の資料が上がっていますのでまとめてみました。 当日の資料 当日の発表内容はこんな感じです。全体的にすごく興味深い話でした。まず今日からzaw使
5/16(金)にCTOによるCTOのためのこんなイベントで話してきました。 http://peatix.com/event/33718 前半のプレゼンテーション CTOという立場である以上、自分自身が技術者としてどうあるべきかだけでなく会社の風土をどうしていくべきか。そしてその風土に合わせてどういう人を採用していくべきかという仕事が出てきます。 今回はそのあたりに焦点を絞ってお話をしました。第一部でつかった資料はこちらです。 他社さんの事例もすごく興味深かったです。特に、cookpad舘野さんのエンジニアの評価基準の話はすごく具体的で参考になりました。 後半はパネルディスカッション 後半は、パネルディスカッションです。他社さんの事例がいろいろ聞けたのは個人的にもすごく勉強になりました。 「めんどくさいおじさんにならないようにしよう」「成功体験おじさんにならないようにしよう」みたいな感じです
若干釣り気味のタイトルです。CTO募集すること自体は悪くないんだけど、その内容についていろいろ思うことがあったのでちょっと書いてみます。 やたら見かけるCTO募集 wantedlyとかみるとですね、とにかくCTO募集している会社が多いわけですよ。そりゃITな会社つくるとしたらCTOはいた方がいい。 でもね、多くの社長が話すCTO像って別にCTOを求めてる訳じゃないんですよね。要するに、なんでもできるエンジニアが欲しいというだけのパターンが多い。 とくに募集要件みてもピンと来ないんですよ。別にそれってCTOである必要ないでしょ？と思ってしまう。例えば、 アーキテクチャの設計ができて スマホアプリできて サーバサイド開発もできて インフラもひと通りできて マネージメントできて イケてる提案もしてくれる あと、言うことは聞いてね みたいなことを考えてる人が多い。すごく多い。まずね、いないよそんな
ITに携わる人たちの間で、エンジニアが大切でエンジニアを中心とした組織づくりをしようとしている会社がすごく増えてきました。実際にいま存在感がある会社はどこもエンジニアが活躍している会社です。 なぜ非エンジニア向けに技術を学ばせるのか nanapiでは非エンジニアむけの技術研修を毎週実施をしていて、コードのかけない人はいないようにすることを目標にしています。これはコードを書けることでそれを普段の業務に活かせるようにしようというだけではなく、技術そのものに対してリスペクトしてほしいという思いがあります。 nanapiのエンジニアはコミュニケーション能力が非常に高いので非エンジニアのレベルに合わせて技術の話をすることができますが、実際はエンジニアが遠慮せずに話してそれを非エンジニアの人が理解しようとするほうが圧倒的に仕事のレベルは上がるはずなです。やっぱり普段の仕事の会話は高いレベルに合わせたほ
naoya_itoの火を噴いたシェルtips - Togetter これを読んでふと書きたくなったので。ちなみに僕はbash使っています。 CTRLを使った便利系 まず、UNIXな操作あたり。 キーバインド 意味 CTRL + s キー入力を受け付けなくする 画面出力抑える CTRL + q 上記解除 CTRL + z バックグラウンドに. fgで戻る CTRL + l 画面をクリア。clearと同等 CTRL + c 現在の処理を停止 CTRL + d exitと同等 CTRL + r historyからコマンド検索 emacsっぽいやつ どっちかというとキー操作に近い。基本はemacs。metaは僕はoptionに割り当ててる。とりあえず触りたい人はESCでOK。 キーバインド 意味 CTRL + a 行頭 CTRL + e 行末 CTRL + f → CTRL + b ← CTRL
少し前の話になってしまうのですが、4/7(月)にKDDIさん主催のイベントで話してきました。実は、グロースハック系のイベントでの登壇は今回が初めてです。 nanapi×VASILY×ランサーズ グロースハック大勉強会！！【グロースハックを支えるチームづくりと実践手法】｜IT勉強会ならTECH PLAY［テックプレイ］ グロースハックという単語は、ここ最近のバズワードになってきていますがnanapiなりの解釈を話すことができました。具体的には、データ解析は重要だよーという話がメインです。 どうでもいい話なのですが、今回一緒に登壇したメンバーはもともと知っているメンバーで、全員バンドマンという面白い共通点がありました。 講演の様子 60名ほどの参加者で、ほぼ会場は満席だったと思います。ざっくりアンケートをとった感じだと、技術者の方は1/3くらいだったでしょうか。 この後の懇親会でも感じましたが
AWSなど様々な環境でサーバを管理してくると、すべて同一の監視ツールを使うのがなかなか難しくなってきます。そんなこともあり、私も定期的にいろいろな監視ツールを試しています。 http://nanapi.co.jp/blog/2013/09/11/monitor_nanapi_servers/ nagiosとクラウドの相性が悪い！ 監視するには様々なツールがありますが、その中でも特に有名なツールはnagiosでしょう。古くから使われているツールで、プラグインも数多くあり様々な監視を行うことができます。 クライアント側にnrpeをインストールすることで、各ホストの詳細の状態まで監視することができますし、うまく活用すればかなり細かい監視までできます。 しかし、AWSのようなクラウド環境で使うには非常に使いづらいです。というのも、nagiosはサーバ側にどのホストを監視するのかという情報を持たなけ
些末なコードレビュー - naoyaのはてなダイアリー なおやさんのエントリーを読んで改めて感じました。これはコードレビューについての話ですが、言いたいことは本質的なことについて話せるかどうかという点だと思います。 いい加減、「コミュ力」という単語で片付けるのはやめよう 「エンジニアはコミュ力がない」とかいわれますが、コミュ力とかいう単語１つで片付けてほしくないです。少なくとも普段の会話におけるコミュニケーションと仕事におけるコミュニケーションって別物ですよね。 先ほどのコードレビューの話ですが、仕事においてのコミュニケーションってどれだけ本質について話せるかなんですよ。要するに、情報を整理して正しく相手に伝えるということ。となると、仕事におけるコミュニケーション力って職種とは直接的に関係してこないと思っています。 「コミュニケーション能力」の意味の違い 「仕事におけるコミュニケーション能
cookbookを書くときの冪等性 cookbookはインストール時だけでなく、何度実行しても同じ状態に保たれることが重要視されます。 chef業界ではこれを冪等性（べきとうせい）と読んでいたりします。これは設定ファイルやパッケージのインストールなど、すべてに当てはまります。 例えば、パッケージシステム経由でvimをインストールするようば場合のrecipeは以下のようにして書きます。 package 'vim' このようにすることで、それぞれのディストリビューションにあったパッケージシステムをつかってvimをインストールしてくれます。当然、二重にインストールされることはありません。 sourceからインストールするcookbook たとえばCentOSにphpをパッケージ経由でインストールすると、ちょっと古いバージョンのものがインストールされてしまいます。 新しいバージョンを使いたい場合は
いろいろな略称が多い！ コマンドやディレクトリ名など、UnixなOSはとにかくいろいろな略称が多いです。特にさわりはじめの人はこの略称がいみわからずに心が折れてしまうことは多いと思います。実際にSchooでUnixの授業をやったときもこの略称を説明しました。 というわけでまとめてみました。なぜ略称が多いのかが気になる人はこちらを読んでみてください。 UNIXという考え方―その設計思想と哲学 作者:Mike Gancarzオーム社Amazon ※ちなみに、Linuxにもほぼ通用すると思いますがMacをベースに書いているのでUnixという表記にしています。 ディレクトリ名 名称 本来の意味 備考 usr User Services and Routines これは若干怪しめです。Userという説も var Variable ログやメールの情報など、変わりうる情報を扱うもの tmp Tempor
情シス担当者なんていない 現在、nanapiは社員数30名弱くらいの会社規模です。アルバイトさんを含めると70名くらいになりますが、そのうちエンジニアは私を含めて8名。このくらいの会社の規模だと、まだ情シス的な仕事を専門的にやるような人はいません。 当然、ネットワークの専門家もまだ弊社にはいないので必然的にエンジニアの誰かがこのあたりを担当することになります。ベンチャーにおいてだいたいの場合、こういった技術的な行き場の分からない仕事ってのはCTOがやるもんです。 しかし、情シス的な仕事って本当に難儀な仕事。動いてて当たり前、高速で当たり前、ちょっとでもネットワークが遅くなるものならその時点ですでに障害です。 外注するという選択肢もありますが、何かしら社内でネットワークのトラブルがあれば少なくともその瞬間はたぶん僕が対応するなり調査するなりすることになります。どうせそうなるのであれば、自分で
はじめに 今回紹介する本は玄人向けではなく「データ分析が重要そうだけど、なんだかよくわかんないと思っている人」向けです。 昨今ではデータマイニングという単語がエンジニアやマーケティング担当者のものだけでなく、経営レイヤーでも重要視されてきています。 ビッグデータというバズワード的なものも頻繁に言われ始めて、めんどくさい上司とかはとにかく口にし出すような状況ではないでしょうか？（想像です） 勉強しないと！と思いはするものの、統計やらHadoopやらRやら、それにまつわるものが多すぎて何から手をつけていいのかわからないもの。 というわけで、私が最近読んだ中でも「何ができるものなのか」という浅く広いテーマについて触れている本をいくつか紹介します。 統計学 統計学が最強の学問である 作者:西内 啓ダイヤモンド社Amazon cakesの連載をまとめた本ですが、統計学がどういった分野に使われているの
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く