スキルマップ作成のすすめ
チームでの開発って大変だけど楽しいと思ってるみなさんこんにちは。@ryuzeeです。 チームは共通の目標に向かって日々の仕事に取り組んでいくことになりますが、そのためにはメンバーそれぞれが必要なスキルをもっている必要があります。このスキルを見える化するテクニックの1つとしておすすめなのが、スキルマップです。 作り方は簡単で以下の図のように横軸に必要なスキルを、縦軸にチームメンバーの名前を入れます。それぞれのマスでは、その人のスキル度合いを表す印を入れていきます。ここでは、★：エース、◎：得意、○：一人でできる、△：助けがあればできる、空欄：できない、・：今後習得したい、というようにしていますが、この記号はチームで好きに決めて構いません。 このスキルマップの効用と運用について見ていきましょう。 効果：スキルの見える化長い間同じチームで働いていれば、誰が何をできるのかはだんだん分かっていきます
プロジェクトが失敗する10の兆候
今年こそは失敗プロジェクトをなくしたいと思っているみなさんこんにちは。ryuzeeです。 先日海外のサイトを見ていたところ、10 Signs When Projects Are Doomed to Failureという面白い記事を見つけたので、10の兆候それぞれをご紹介しつつ私の私見を述べておきたいと思います。 なお、アジャイルなのかウォーターフォールなのかは関係なくあてはまります。 失敗プロジェクトの兆候(1) プロジェクトメンバーが自分たちのタスクをこなすよりもプロジェクトの悪い状況について話し合いをするのに時間を使っている よくあるパターン。 たとえばなかなか仕様が決まらないので見切りで発射してみたら、途中で色々な仕様変更がおこったり考慮漏れが出てきたりして常に対策会議をしなければいけなくなったり、 品質が悪すぎて品質改善のための会議を頻繁におこなうことになったりといった状況。 タス
採用プロセスを真剣に考えろという話
人材流動性の高まりを日々感じているみなさんこんにちは。 最近いろんな会社にお呼ばれしていて、その中でエンジニアの採用の話になることがとても多いのでちょっと整理しておきます。 ポイント▼「面白いプロダクトもないし、仕事内容は面白いとは思えないし、よい給与は払えないし、仕事環境にも自由はないけど、良い人雇いたいんだけど、どうしたらよいですか？」悪いが諦めろ。良い人は当然のことながら複数の会社が興味をもつことになるし、働く場所を自分で選択します。Pros/Consを見極めて選ぶことになるので、Prosがない場所で働く理由がありません…だとあまりに冷たいので、もしあなたが次に転職するとして、それでも今の会社に入るのであればあなたを惹きつける理由が何かあるはずで、それをアピールしよう▼「入社してから期待値にあっていないことが分かる、ってことが多いんだけどどうしたらよいですか？」期待値を明文化している
AWSを退職します
私事ですが、AWS(Amazon Data Services Japan)を10月31日付けで退職いたします。本日が最終出社日でした。 入社したのが2013年4月1日ですので、在籍期間は2年7ヶ月ということになります。 前回転職した時に知り合いはみんなもって半年とか1年と言ってくれたのですが、その期待は裏切ることが出来ました。 在籍期間中は非常に多くの方にお世話になりましたこと厚く御礼申し上げます。 AWSでやったこと 思い返せばAWSで仕事をすることになったのはひょんなキッカケでした。 2012年10月にアジャイル関連の講演をするために、札幌のJava Festa 2012というイベントにお邪魔させていただきました。 その講演会場の控室にいたところ、当時すでにAWSで仕事をしていた旧知の玉川憲さん(いま飛ぶ鳥を落とす勢いのSORACOMの代表ですね)から、日本でAWSのコンサルティング部
Electronでデスクトップアプリを簡単構築
全国5000人のエンジニアをやめて寿司職人になろうと思っているみなさんこんばんは。 前回までスライド共有用のアプリケーションを趣味(リハビリ)で作っていたのですが、折角なのでデスクトップクライアントも作ってみました。 構築にはElectronを使ったのですが、結構簡単にできたので記録としてまとめておきます。 Electronって何？GitHubが開発するクロスプラットフォームで動作するアプリケーションを開発するためのフレームワーク。コードの記述はHTML5とNode.js。その範囲であれば既存のWeb開発技術が使いまわせる。例えばjQueryとかAngularなんかを使うのも可能Chromeブラウザのオープンソース版のChroniumのエンジンを内蔵例えばAtom・Visual Studio Code・Slackクライアントや、日本だとKobitoあたりがメジャー作り方あちこちに記事があが
オープンソースのTrelloクローン Libreboard | Ryuzee.com
Trelloは、https://www.trello.com で提供されているオンラインのタスク管理サービスで、利用している人も多いと思います。僕自身も以前書いたSCRUM BOOT CAMP THE BOOKの執筆の進捗管理や、Regional Scrum Gathering Tokyoのタスク管理などで使っていました。 このTrelloのオープンソース版のクローンが登場したので紹介します。 LibreboardLibreboardは、こちらで開発が進められているオープンソースソフトウェアでMITライセンスで提供されています。2014年の頭に開発が始まり、最初の開発ペースは早くありませんでしたが、昨年末くらいから急激に開発速度が上がってきているようです。 技術的には、NodejsのフレームワークであるMeteor(メテオ)を利用しています。 Meteorの詳細については以下を参照すると良
5分で分かるDockerのキホン
全国100万人のImmutable Infrastructure職人のみなさんこんにちは。 もう誰も彼もがDockerなので、あんまりブログに書こうという気にもならなかったのですが、知り合いからリクエストを貰ったので、5分くらいで分かるようにかいつまんで概略を説明します。 Dockerとは詳しくは本家サイト見ればだいたい分かる。仮想化技術コンテナ単位でパッケージングVirtualBoxとかと違って高速、オーバーヘッドが少ない。chrootに近い。LXCには依存しなくなっているコンテナごとにIDが振られるコンテナは差分保存なのでロールバックも簡単一回作ればどこでも動く。JavaっぽいDockerfileでコンテナを作成するDockerfileの1行ごとにコンテナIDがフラれる動作環境Linux Kernel 3.8以降 64bit OSMacの場合はVirtualBoxの中で動かす形になる→
vagrant-lxcで軽量仮想環境を手に入れる
Vagrantは標準ではVirtualBoxを仮想環境として利用しますが、とにかく遅いのが難点です。 Test-Kitchenを使ってChefのCookbookのテストをしたり、これらを継続的インテグレーションしようとしたときにこの遅さはたまりません。いくつか手段はあってお金持ちの皆様であれば、大富豪アプローチということで、仮想マシンを動かす母艦にXeon E5-2697 v2を積んだ高性能マシンを使ったりもできるのですが、普通に考えれば、VirtualBoxよりも軽量な仮想環境を使うのが有力なアプローチです。 今回はLXCを使って軽量な仮想環境を手に入れる方法を紹介します。 LXCのインストールLXC自体の説明はこの辺とかこの辺を参照ください。 インストール対象の母艦はUbuntu 12.04 LTSです。 sudo apt-get install lxc sudoの設定変更sudoのバ
Agilar Taskboard(かんばん)を使ってみた
Agilar TaskboardはFrancisco Tufro氏が開発しているオープンソースのかんばんアプリケーション。 Railsを利用して作られている。 Visual management Blogというサイトを偶然見ていて発見した。 面白そうなので試してみた。 インストール ソースコードはgithubに置かれている。 git clone http://github.com/agilar/taskboard.git Rcovのインストール http://rubyforge.org/frs/download.php/28271/rcov-0.8.1.2.0-mswin32.gem から rcov-0.8.1.2.0-mswin32.gem を入手し gem install rcov-0.8.1.2.0-mswin32.gem --local RMagickのインストール http://
Vagrantで簡単仮想マシン構築
VagrantはOracle VirtualBoxを利用した仮想マシンをコマンドラインから作成してくれるソフトウェアだ。 設定ファイルをRubyで書くことができ、Chef等とも連携できるので、開発環境をコマンドライン一発で作成することができる。更にはCapistranoと組み合わせてアプリケーションのデプロイも一括で行うことで完全自動でいつでもテスト環境をつくれたりもする。 仮想マシンを捨ててしまってもいつでも再構築できること、誰のところにでもすぐ同じ状態に展開できることは開発を進める上で非常にメリットがある。 以下ではまずはVagrantを利用した簡単な仮想マシン構築の手順を説明する（本当に説明したい内容はもっと違う話なのだが追って別のエントリで書いていくことにする） Oracle VirtualBoxのインストールhttps://www.virtualbox.org/にアクセスし左ナビ
【資料公開】ワンクリックデプロイ 〜いつまで手でデプロイしてるんですか〜
みなさんこんにちは。@ryuzeeです。 2013年2月15日に目黒雅叙園で行われたデブサミ2013で登壇してきましたので、その際の資料を公開します。 「いつまで手でデプロイしてるんですか？」ってキャッチーなタイトルにしたのは、公募セッションの申し込みの時に目につくようにしたかったためで、会場でアナウンスしてくださる方にこのセリフを言って欲しかったわけではないので念のため。 デプロイの自動化を進めていくのは正直なところ大変です。 今の現状からいきなり明日デプロイを自動化できるわけでもないし、誰かがいきなりデプロイを自動化してくれるわけでもありません。 その前に考えなければならないこともたくさんあると思います。 でも現実にAmazonやFlickrを始めとしてそれを実施している会社は多数あるし、日本にもそういう会社は多数あるわけです。ちょっとずつカイゼンしながら本当に利益に繋がるところに時間
Jenkinsでビルド・パイプラインを作る
Jenkinsのプラグインでビルド・パイプラインを作ることができるので紹介。 ＃12月20日のワンクリックデプロイ勉強会の発表のネタバレっぽいのですが。 ビルド・パイプラインとはビルド・パイプラインとは、継続インテグレーションのプラクティスの１つで、テスト等を複数の単位に分割し、順番に流していくものである。一般的には継続的インテグレーションを利用していれば、SCMにソースコードをコミットした段階ですぐにユニットテストを走らせ、以降に、静的解析や結合テスト、受け入れテスト、ステージング環境へのデプロイ、本番環境へのデプロイという形で進んでいくことになり、その単位でパイプライン要素を分ける。 当然パイプラインの途中で試験に不合格であれば、その後のプロセスには進めない。 これによって、例えばコミット時には即座にユニットテストレベルの結果を返して開発者のペースを阻害しないようにすることができる。（
【書評】手動デプロイからの卒業指南書「継続的デリバリー」
継続的デリバリー 信頼できるソフトウェアリリースのためのビルド・テスト・デプロイメントの自動化著者／訳者：David Farley、Jez Humble、和智 右桂、高木 正弘出版社：KADOKAWA/アスキー・メディアワークス発売日：2012-03-14大型本：544ページISBN-13：9784048707879ASIN：4048707876 レビューに参加させていただいた縁でアスキー・メディアワークス社様より献本いただきました。和智さん、高木さんの黄金コンビによる翻訳です。 デプロイ自動化に関する話を網羅的に扱った本はこれがはじめてでしょう。 上級技術者向けと書かれているように内容は結構ハイレベルで、構成管理、CI、テスト戦略についての前提知識が求められるように思いますが、アジャイルなプロジェクトの中で日々改善を繰り返している人たちにとっては理解しやすいのではないかと思います。 デプ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
