人を集めたからといってすぐ機能するわけじゃないという話 | Ryuzee.com
日々採用や組織がうまく動くように苦労しているみなさんこんにちは。@ryuzeeです。 ひとりで色々な物事を完結できればこんな楽なことはないのですが、特にシステム開発においてそのような規模のものは多くなく、たいていの場合複数人を集めてプロジェクトを遂行することになります。特に案件ベースで体制を作るシステムインテグレーターなんかを思い浮かべて頂くとわかりやすいかもしれません。 さて、そうやって集められた「人たち」はいきなりうまく機能して、プロジェクトのゴールに邁進できるようになるのでしょうか？というと残念ながら答えはノーです。 以下の図は、心理学者のタックマンが提唱する「タックマンモデル」と呼ばれるチーム(集団)の進化形態をあらわしたものです。 これによると、チームは以下のようなステップを経て変遷していきます。 形成期とりあえず人が集められた段階でお互いのことを知らない。なぜ集められたのか、自
スキルマップ作成のすすめ
チームでの開発って大変だけど楽しいと思ってるみなさんこんにちは。@ryuzeeです。 チームは共通の目標に向かって日々の仕事に取り組んでいくことになりますが、そのためにはメンバーそれぞれが必要なスキルをもっている必要があります。このスキルを見える化するテクニックの1つとしておすすめなのが、スキルマップです。 作り方は簡単で以下の図のように横軸に必要なスキルを、縦軸にチームメンバーの名前を入れます。それぞれのマスでは、その人のスキル度合いを表す印を入れていきます。ここでは、★：エース、◎：得意、○：一人でできる、△：助けがあればできる、空欄：できない、・：今後習得したい、というようにしていますが、この記号はチームで好きに決めて構いません。 このスキルマップの効用と運用について見ていきましょう。 効果：スキルの見える化長い間同じチームで働いていれば、誰が何をできるのかはだんだん分かっていきます
クラウドエンジニア採用のTIPS
人材流動性の高まりのまっただなかにいる@ryuzeeです。こんにちは。 AWSの中の人がクラウドのエンジニアを採用するにあたっての質問集や見るべきポイントを紹介していたのでご紹介します。 Hiring a Cloud Engineer? Questions to Ask and What You Should Hear これからクラウドベンダーに転職したい人や、クラウドベンダーの中で採用を担当している人はみておくと良いかもしれませんね。 以下参考までに勝手訳です。 クラウドエンジニアを雇いたい場合の質問と聞くべきポイントこのブログポストでは、あなたのスタートアップやスモールビジネスの助けになる経験豊富なクラウドエンジニアを採用する際のTIPSを紹介する。 ここでいう「クラウドエンジニア」とはポジションの説明や肩書ではなく、質や長所を表す言葉として使っている。 この手の人をCTOで雇うか一エ
プロジェクトが失敗する10の兆候
今年こそは失敗プロジェクトをなくしたいと思っているみなさんこんにちは。ryuzeeです。 先日海外のサイトを見ていたところ、10 Signs When Projects Are Doomed to Failureという面白い記事を見つけたので、10の兆候それぞれをご紹介しつつ私の私見を述べておきたいと思います。 なお、アジャイルなのかウォーターフォールなのかは関係なくあてはまります。 失敗プロジェクトの兆候(1) プロジェクトメンバーが自分たちのタスクをこなすよりもプロジェクトの悪い状況について話し合いをするのに時間を使っている よくあるパターン。 たとえばなかなか仕様が決まらないので見切りで発射してみたら、途中で色々な仕様変更がおこったり考慮漏れが出てきたりして常に対策会議をしなければいけなくなったり、 品質が悪すぎて品質改善のための会議を頻繁におこなうことになったりといった状況。 タス
2015年のふりかえり
大晦日に寿司をたらふくたべているみなさんこんにちは。我が家も寿司です。 いよいよ2015年も最後の日ですので今年1年を整理しておきます。 トピック 10月末でAWSを退職して、現在絶賛サバティカル中 [PR] 2016年1月と2月にスポットで支援できると思うのでお気軽にお声がけください(すいませんが長期のコミットはまだできませんのでご了承ください)。なおご支援の例としては以下のとおりです。 スクラムやアジャイル、DevOpsに関する集合トレーニングの実施(このような資料を使います) スクラムやアジャイル、DevOpsに取り組んでいる現場でのオンサイトコーチング 改善を必要としている現場での問題の整理や改善の流れの立案 クラウド導入に関するアーキテクティングや標準化の支援 社内勉強会や相談会の実施 その他チームビルディング・採用・評価などに関するコンサルティング ブログ 2年半前に会社が変わ
採用プロセスを真剣に考えろという話
人材流動性の高まりを日々感じているみなさんこんにちは。 最近いろんな会社にお呼ばれしていて、その中でエンジニアの採用の話になることがとても多いのでちょっと整理しておきます。 ポイント▼「面白いプロダクトもないし、仕事内容は面白いとは思えないし、よい給与は払えないし、仕事環境にも自由はないけど、良い人雇いたいんだけど、どうしたらよいですか？」悪いが諦めろ。良い人は当然のことながら複数の会社が興味をもつことになるし、働く場所を自分で選択します。Pros/Consを見極めて選ぶことになるので、Prosがない場所で働く理由がありません…だとあまりに冷たいので、もしあなたが次に転職するとして、それでも今の会社に入るのであればあなたを惹きつける理由が何かあるはずで、それをアピールしよう▼「入社してから期待値にあっていないことが分かる、ってことが多いんだけどどうしたらよいですか？」期待値を明文化している
アジャイルプロジェクトの危険な兆候
みなさんこんにちは。@ryuzeeです。 タイトルのとおりなのですが、過去の個人的な経験で「こういうのをみたら深掘りしろ」というポイントをシェアしておきます。 アジャイルがあわないプロジェクトへの適用アジャイルプロジェクトの経験がない、または非常にすくない企業の文化がアジャイルの考え方とあっていない組織が大きすぎて動かない従来型のやり方に従わせる圧力がかかる納期とスコープの強い圧力マネジメントのスポンサーシップがない必要なアジャイルに関するスキルが足りていない技術支援チームの支援など、必要な支援が得られていないトレーニング不足立ち上げ時の準備不足アジャイルでやれば必ず成功すると思っている関係する人たちへの説明不足(期待値コントロール)いきなりプロセスをカスタマイズしたり何かを省略しているプラクティスの目的を理解せず表面的に真似だけしているチーム内のコミュニケーションがとれていないチームがチ
Webサイトを作るときに便利に使えるフリーのBootstrapテーマ
ちょっとしたウェブサイトを作るときに困るのがデザインです。なかなか見栄えの良いものをイチから作るのは普通のエンジニアにとってはしんどいので、そういうときに使えそうなテンプレートを紹介します。フリーなものを集めていますがライセンスはそれぞれ違うので利用の用途にあわせて確認するのが良いと思います。またテンプレートによっては有償プランが用意されていて少額を支払うとサポートが受けられるものもあります。(なお、有償のものも多数あって安いものは数ドルからあるので、時間効率という観点ではそういうのを買ってしまうのも早いです) 探す時は、以下のサイトあたりがオススメです。 {wrap} bootstrapShapeBootstrapStart BootstrapBootsnipp (ちょっと毛色が違って色々なコンポーネントのコードサンプルが入手できる)こういうのは見てるだけで楽しいですねー。 Corlat
Rails4でスライド共有アプリを作りなおした話
RubyKaigiで寿司が出るなら行けば良かったと思ったみなさんこんにちは。 最近登壇した際に使ったスライドはSlideshareやSpeakerdeckではなく自作のスライド公開用Webサイト（https://slide.meguro.ryuzee.com/）で公開しています。 それについては以前の記事で書いた通りなのですが、最近時間がある(察してください…)ので、CakePHPで作った初期バージョンを勉強がてらRuby on Rails4で作りなおしてみました。 いままでRuby自体はChefのCookbookを書いたり、Serverspecのコードを書いたり、使い捨てプログラムを書いたりしていたのですが、初めてのRailsで「Railsを勉強しています!!」状態なのでやった内容を整理しておこうかと思います。 ■初心者向けのメモ自分が感じた初心者向けのポイントは以下のような感じです。
【小ネタ】Railsアプリ開発用のVagrantfile
人材流動性の高まりを感じているみなさんこんにちは。 比較的時間があるので今までCakePHP2.7で作っていたアプリケーションをRails4に移行しているのですが、その開発開発環境としてはVagrantを使っています(みなさん、VagrantとかDockerとか使っていると思います)。 そこで今回は、僕が使っているVagrantのベース部分をシェアします。 特に難しいことはしていないのですが、以下のような仕様になっています。肝は共有フォルダの設定だけです。 ソースコード自体はローカル側のMacで編集したいのでVagrantとディレクトリを共有しますただ共有の際に、VagrantのSynced Folder機能だとファイルやディレクトリのパーミッションがローカル側のものになってしまい不都合が多い(たとえばgemのNative Extensionが権限の理由でビルドできない)ので、NFS共有機
外部の技術コンサルタントの雇い方
新しいものを導入したり、困っていることがある場合に外部の技術コンサルタントを雇う例が増えていると思います。 一方で、外部の技術コンサルタントを使うとお金もかかりますし、その分の成果もきちんとあげなければなりません。 あくまで私見ですが、以下に僕がお客様とか相談してくれた人に推奨している技術コンサルタントの選び方を書いておきますので参考にどうぞ。なお、技術顧問はちょっと毛色が違うので全部は当てはまりません。 コンサルタントは銀の弾丸ではないので、雇ったら「なんだか良く分からないけどすごーくうまくやってくれる」なんてわけはないことを認識すること。発注側も実行をコミットする必要があるコンサルタントを使うことを検討する前に、自分たちが何に困っているのか明らかにすること。視点は単なる技術視点でなく、ビジネスレベルでも考えること何に困っているか明らかにするとき、関係者それぞれの課題が同一とは限らないと
【我流】プレゼンテーション資料の作り方
全国100万人のブリよりワラサ好きのみなさんこんにちは。先日強いチームの作り方を公開したのですが、何人かの知り合いからこういうスライドの作り方教えてほしい、というリクエストを受けたので以下にダンプしておきます。 参考書籍以下にあげる本は一度読んでおいて損はないです。プレゼンテーションZenは、ピアソンが技術書の取り扱いやめてしまい絶版かと思ったけど第二版が出て何より。 ガー・レイノルズ シンプルプレゼンプレゼンテーションZEN 第2版プレゼンテーションZENデザインこれらの本の中でも出てきますが、「プレゼンテーション」と「ドキュメント」は明確に分けた方がいい。 よく会社で経営方針とか数字とかをパワーポイントで作って配りますが、単にデータや説明を見せるならそれこそワードでやった方が読みやすいしコンパクトです。 トヨタがA3用紙1枚でまとめる(最近そうでもないらしいですが)と聞きますが、それと
【資料公開】強いチームの作り方 | Ryuzee.com
2015年11月10日に某社の社内勉強会で、「強いチームの作り方」というテーマで話をしたのでその際の資料を公開しておきます。 内容自体は、WEB+DB PRESS 83号に書いた内容なので興味があればそちらを参照ください。 最近DevOpsの文脈ですぐに「インフラ自動化しないといけない」とか「ツール使って効率化」みたいな話を頻繁に聞きます。 が、端的にいえば、「実際のところ、ソフトウェア開発上の問題の多くは、技術的というより社会学的なものである」というデマルコの一節の通りであり、 DevOpsの本質もツールではなく、CLAMS(Culture、Lean、Automation、Measurement、Sharing)であって、土台となるのはやはり組織やチームの文化になります。 一度自分たちのチームや組織について考えてみるとよいと思います。 アジャイルコーチングやトレーニングを提供しています株
マイクロサービスに関する資料のまとめ
世の中マイクロサービス・マイクロサービスうるさいのでちょっとこれ読んでおけという資料をまとめておきます。 はっきり言ってマイクロサービス化しようとすると、組織構造の話、エンジニアの責務の話など技術的な課題以外の領域にもいろんなチャレンジがあるので、普通のプロジェクトでも苦労する組織が取り組むとか、設計だけして開発を委託しているけどDB一極化がやばいので取り組むとかは止めておいた方がよいと思います。 概念Twelve Factor Appマイクロサービスの話ではないが、モダンなアプリケーションを作りたければ開発チーム全員に叩き込んでおくべき内容MicroservicesMartin Fowlerによるマイクロサービスの解説。2014年5月に公開Martin Fowlerのブログは翻訳が可能で、日本語訳を公開してくれている人がいる。こちら単純に言えば、「マイクロサービスとは単一のアプリケーショ
オープンソースのAPI Gateway「Kong」
全国100万人のモノリシック巨大アプリケーションに苦しむみなさんこんにちは。 世の中猫も杓子もマイクロサービスだ!!とかAPIだ!!とか言っていますが、実際にマイクロサービス環境にしようとすると、どのようにしてAPIのサービスを取りまとめるかが課題になります。 一般的には以下のようなやり方になります。 複数のサービスに分散しているAPIを統合するゲートウェイを用意するそのゲートウェイでは以下のようなことをおこなうクライアントからのアクセスのシングルエンドポイントの役目を果たすAPIの実体へのルーティング認証アクセス記録の収集スロットリング(過度なアクセスの抑止)実体がダウンしている場合のデグレーションこのようなAPIゲートウェイの機能は既にAWSではAmazon API Gatewayとして提供されていますが、オープンソースでもいくつかのプロダクトがあります。今回はそのうち一番開発が活発そ
アジャイルトピックカード
Jimmy Janlé氏が書かれた“Agile Topics card deck”という記事が面白かったのでご紹介。 端的にいえば、アジャイルに関連するものをカード化して現場で活用してみるという内容です。 議論やアイデア出しのときに絵の入ったカードを使うというのは開発に限らず一般的なテクニックです。人はそれぞれ知識や思考方法に差があったり、議論の内容ややり方を自分の居心地のよい場所に収束させてしまう傾向にあるためマンネリ化しやすかったりもしますが、ちょっとしたツールのサポートがあればそれを多少防ぐこともできます。 たとえば、智慧カード、ブレスター、アイデアトランプなんかはその分野のものになります。 自分も過去にAgile Buffet Cardというのを作ってみました。こういうのがあると新しいアイデアが浮かんだりもしますし、見ているだけでも楽しいと思います。 以下参考和訳です。詳細は“Ag
Electronでデスクトップアプリを簡単構築
全国5000人のエンジニアをやめて寿司職人になろうと思っているみなさんこんばんは。 前回までスライド共有用のアプリケーションを趣味(リハビリ)で作っていたのですが、折角なのでデスクトップクライアントも作ってみました。 構築にはElectronを使ったのですが、結構簡単にできたので記録としてまとめておきます。 Electronって何？GitHubが開発するクロスプラットフォームで動作するアプリケーションを開発するためのフレームワーク。コードの記述はHTML5とNode.js。その範囲であれば既存のWeb開発技術が使いまわせる。例えばjQueryとかAngularなんかを使うのも可能Chromeブラウザのオープンソース版のChroniumのエンジンを内蔵例えばAtom・Visual Studio Code・Slackクライアントや、日本だとKobitoあたりがメジャー作り方あちこちに記事があが
(続々)スライド公開用のアプリケーションを作っている話
全国100万人の刺身マニアのみなさんこんにちは。 前回の、(続)スライド公開用のアプリケーションを作っている話の続きです。 粛々と色んな機能を追加したり寿司スライドをUpして（・∀・）ﾆﾔﾆﾔしたりして楽しんでいるのですが、何人かの知り合いから自分の環境で動かす簡単な方法を要求されたので、AWS上で簡単に動作させられるようにCloudFormationのテンプレートを作ったので晒しておきます。 Cloud Formation Template 利用上の注意としては、 AWSの東京リージョンだけしか動きません(面倒なので)動作させると新たにVPC、サブネット4つ、IAMロール、S3のバケット2つ、SQSのキュー1つ、そしてt2.largeのインスタンスを1台起動します。その分お金がかかりますインスタンス起動時にChef Soloを使って自動で環境設定を行ないます。ChefDKを始め、それなり
(続)スライド公開用のアプリケーションを作っている話
全国1000万人の寿司職人のみなさんこんばんは。 昨年の12月28日に公開した、AWSを使ってスライドを公開するデモアプリを作ってみた話の続きです。 どんなアプリかは、デモ環境を見ていただくと早いと思いますが、端的にいえば、 SlideshareとかSpeaker Deckのようなサービスのオープンソース版たぶん自分だけのスライドを公開したり、社内用に使えたりするCakePHPとjQueryを使いまくっているAWSの機能をかなり使っており、SPOFのない高可用性アーキテクチャパワーポイントとPDFに対応アップロードしたファイルや変換済ファイルは全てAmazon S3に保存Flash Playerなしで表示ムダに国際化対応済ムダにフルResponsiveなのでiPhoneとかでもいけるMITライセンスコードはGitHubにおいてあるという感じのものです。以下のようにサイトのスライドを埋め込む
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
【資料公開】The Basics of DevOps
