スキルマップ作成のすすめ
チームでの開発って大変だけど楽しいと思ってるみなさんこんにちは。@ryuzeeです。 チームは共通の目標に向かって日々の仕事に取り組んでいくことになりますが、そのためにはメンバーそれぞれが必要なスキルをもっている必要があります。このスキルを見える化するテクニックの1つとしておすすめなのが、スキルマップです。 作り方は簡単で以下の図のように横軸に必要なスキルを、縦軸にチームメンバーの名前を入れます。それぞれのマスでは、その人のスキル度合いを表す印を入れていきます。ここでは、★：エース、◎：得意、○：一人でできる、△：助けがあればできる、空欄：できない、・：今後習得したい、というようにしていますが、この記号はチームで好きに決めて構いません。 このスキルマップの効用と運用について見ていきましょう。 効果：スキルの見える化長い間同じチームで働いていれば、誰が何をできるのかはだんだん分かっていきます
発注側から見て、困った開発をどうするか。 島国大和のド畜生
・2023年03月 (1) ・2023年02月 (1) ・2023年01月 (2) ・2022年12月 (1) ・2022年11月 (3) ・2022年10月 (1) ・2022年09月 (1) ・2022年08月 (1) ・2022年07月 (1) ・2022年05月 (2) ・2022年04月 (1) ・2022年03月 (1) ・2022年02月 (1) ・2022年01月 (1) ・2021年10月 (1) ・2021年08月 (1) ・2021年07月 (2) ・2021年05月 (1) ・2021年04月 (1) ・2021年03月 (1) ・2021年02月 (1) ・2021年01月 (1) ・2020年12月 (1) ・2020年11月 (1) ・2020年10月 (1) ・2020年09月 (1) ・2020年08月 (2) ・2020年06月 (2) ・2020年04
プロとしての行為 Act as Proffesional
1．一般的なコーディング規約に目を通し、エレガントなコードを知るエレガントなコードを書くためには、エレガントなコードを知らなければならい。その土台を築いているコーディング規約について、オープンソースではどのようなものが使われているのか理解しておこう。入社する予定の会社が採用している言語については必ず目を通しておこう。 PHPPEAR 標準コーディング規約symfony CodingStandards Perlperlstyle Ruby クックパッド株式会社のRubyコーディング規準 Matzスタイル NaClで採用している規約 Python PEP 8そして、あなたの身近にあるオープンソースのコードを実際に読んでみよう。この時点でコードの仕組みや設計が理解できなくても良い。コードがエレガントかどうか？を感じ取って欲しい。こう書いた方が、良いのではないか？など、考えてみよう。
少人数開発に役立つ5つのまとめ
if ( $blog == " Webエンジニアのためのライフハック " ) { print " 1-byte.jp "; } ホーム1-byte.jpとは 書いてるヒトは ここ2ヶ月間で気になる記事がたくさん上がっていました。 特に少人数チームにおける開発に関する記事です。 昨日、書き上げた”1年間の技術的負債を返すために読んだ3冊の本“にある通り、お知らせメールでは1年間の技術的負債を返そうとしています。 そのためには今まで曖昧だった箇所を浮き彫りにし、改善する必要があります。 また、せっかくなので新しいモノも取り入れたい。 こうしたことを考えながらの2ヶ月だったので、自然と目に止まった記事が3つありました。 スタートアップ企業で8年間Webの開発をしてみての反省点いろいろ 複数人(2-3人)でウェブサービスを開発するコツ A successful Git branching m
あるゲームプログラマの送別会 - GAME NEVER SLEEPS
まだ日本にいた頃、当時プロジェクトで一緒に仕事をしたX君という人物がいる。彼は新卒で入社して1年とちょっとが過ぎたくらいのプログラマで、僕がタッグを組んだのは、プロジェクトの途中から、しかもたったの半年ほどだったが、誰に言われずとも黙ってユーザービリティを向上してくれるサービス精神と、独断でバグ満載しかもメモリをバカ食いする超ド派手な演出をしれっと入れてみせる若者らしいムチャを兼ね備えた貴重な戦力だった。リードプログラマがひとしきり彼の暴走をいさめた後、あごに手をあて「待てよ……、あれをこうしてこうしたら……。んー、イケるな……。」と独りごちるのを何度も見たものだ。 そんな彼が会社を辞めるという。 当時、会社は激動の時期で社内のチーム合併を繰り返していた。そんな会社に不安を覚える者、新しいチームになじめない者。僕が入社してから辞めていった人数の、倍以上の人々がたった数ヶ月のうちに去っていっ
2010-03-20
なんでもかんでも、お疲れ様。メールの挨拶も、「お疲れさまです。hyoshiokです」朝でも昼でも夜でも「お疲れ様です。hyoshiokです」。飲み会で乾杯するときも「お疲れ様で〜す」、ジョッキをがちゃーん。会社でプレゼンする時も「お疲れさまです。開発部のhyoshiokです」。そして退社するときも「お疲れさまです〜〜」。飲み会での最後の挨拶も「お疲れ様でした〜」 みんな、お疲れなんだなあ。大変なんだなあ。そんなにお疲れしないように、肩のチカラ抜きましょう。もみもみ。凝ってますね〜皆様。 コードはHOW、テストはWHAT、ドキュメントはWHY。 先日のソースコードリーディングワークショップ2010でそんなようなことをお話した。 これは文字通りの意味だ。コードは実装の詳細HOWを表現している。どのように問題を解いたか。プログラマの数だけ表現がある。一方テストはWHATだ。何を実現するかを表して
カプコンに学ぶデスマーチにならない仕事術 - teruyastarはかく語りき
ほんとにヤバくなってギリギリになるまで相談しない人々: 切込隊長BLOG（ブログ） Lead‐off man's Blog http://kirik.tea-nifty.com/diary/2010/03/post-1da9.html いつも予防線が突破されるので、いずれにせよ年がら年中修羅場になってるわけだが、 修羅場をこなしているうちに、常在戦場みたいな組織が出来上がって、 毎日ラットレースをしている敗戦処理のエキスパート軍団ができちゃう。 戦況だけ見ると実に見事に負けてるんだけど、 担当した局地戦だけはどうにかなっちゃってるというような。 そういう組織は、人が内部から壊れていく。鬱になったり、病気になったりする。 まあ、発展性のない業務に長時間据えられて、 強いストレスに晒されながら安い給料で働くわけだからねえ。 一個一個のデスマーチは、マーチである限り終わりはあるわけだけど、 デス
むしろ初心者におすすめ「プロフェッショナル・プレゼンテーション」
既に[ レビュー ]したが、もう一度ほめておこう、「プレゼンテーションZen」は良い本だ。シンプルで、ヴィジュアルで、眠くならない（←これ重要）なプレゼンをするための必読本――なのだが、これは上級者向けだろう。コンテンツの作り方やストーリーラインの決め方、さらにデリバリーの基本といったプロセスの解説はほとんどない。そういうことは分かっている人向けに、取り組み方とか心構えといったスタンスを説くものだから。 では、そうしたプレゼンの基本のキを知るためには何を参考にすれば――という視点で、一冊選んだ。アイディア出しからロジックの組み立て、ヴィジュアル化、チャートへの落とし込み…といった、プレゼンの基礎手法が網羅されており、新入社員や、プレゼンは初めてといった人にとって必要十分な知識を得られる。 たとえば、「キーとなるメッセージは、プレゼン後に聴衆の心に残したいものだ」とか、「キーメッセージは相手
ググるな危険：プログラマで、生きている：エンジニアライフ
だいぶ前の話になりますけど、「新人にデータ移行ツールのコーディングを任せるので、面倒をみてやってくれ」と頼まれたことがありました。 その新人はやたらとGoogle検索に頼る人で、とにかくわからないことがあると、わたしに聞かずにGoogle先生に尋ねるんですね。 検索サイトにはわたしもかなりお世話になっていますし、昔に比べるととても使い勝手がよくなっていますけれど、その人の技術レベルに対応して検索結果を出してくれるほど高機能なわけではありません。 そのため新人の書いてくるコードは、つぎはぎというかちぐはぐというか、身についてない知識に振り回されてる感が満載でした。 そういう弊害を気にしつつも、自分で調べようとする気持ちは尊重するべきなのかなあ、と思ってとりあえず黙認していたんですが、あるとき「ちょっと考えが甘かった」と思い知らされるトラブルが発生しました。 その新人が「Windowsのレジス
はてなグループの終了日を2020年1月31日(金)に決定しました - はてなの告知
はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28
Naughty Dog の Gameplay Programmer 採用基準 - minahitoの鯉日記
ここ数週間、今後のゲームプログラマとしての方向性を色々考えていました。 現場の開発には楽しいことも苦しいことも山積みで、その山を崩していくだけで毎日忙しいし、正社員である以上、会社は給料をくれるし、プログラマであり続けることができる日本的なシステムの下に自分はいます。 プロジェクト契約や一年契約で働いている方々と比較すれば、口では何を言おうと、この状況に甘んじることは可能です。いつか破滅が身に降りかかってくる日までは。 ただ、自分たちの未成熟さが問題をややこしくし、手順を複雑化させとるんだとすれば、忙しい忙しいといってエネルギーを消費する我々は、どっかの公務員以上の給料泥棒であると言えるし、なによりゲームを作る舞台で「世界的勝者」に近づくことはなかなかできないでしょう。この言い方は問題あるけど……別に与えられた役割をほどほどにこなして無難に給料貰う人生を送るためにわざわざ田舎から東京に出て
"自分がやったほうが早い"はダメ! マネージャがやってはいけない5つのミス | 経営 | マイコミジャーナル
マネージャの仕事の中でも重要なものに、部下に適切に仕事を任せる、というものがある。英語では"delegating(権限の委譲)"という。仕事を丸投げしたり、介入しすぎたりしては部下も思い通りの仕事ができないことは容易に想像がつく。U.S.News & WORLD REPORTに「部下に仕事を任せる際の5つの間違い(原題: 5 Ways Managers Fail at Delegating)」という記事が載っているので紹介しよう。 1. 共通の認識を持たない 仕事が成功裏に終了した時のゴールは何かということを事前に部下と確認しなかったため、最後に出てきたものがあなたの期待したものと違っていたということはよく起こる。 2. 進捗管理をしない プロジェクトの最初に話をするだけで、計画通りに仕事が進む……なんてことはない! プロジェクトに関与し続け、チェックすることはマネージャの有効な武器だ。進
ダメ社長の妄言「頭を使うな」 - カレーなる辛口Javaな加齢日記
http://blog.livedoor.jp/kensuu/archives/50895112.html プログラマーの人がよく言う言葉として、車輪の再発明はするな、という言葉があります。すでに発明されたものをゼロから初めても意味ないよね、ということです。車輪を発明する手間をかけるなら、その時間をもっと新しくクリエイティブなことに使ったほうが有益なわけです。 で、優秀な人ほど自分の頭で考えようとする。とりあえず自分の頭で考えるというやり方をするのです。 本当に優秀な人は調べて分かる程度のことはとっくに調べてる．ネットでの調べ物も駆使する．そしてその上で自分の頭脳も使うのだ． 調べ物のうまさも仕事のテクニックのうちだが，それが全てではない． 「車輪の再発明」についてもこの社長さんは，ちゃんと理解して発言しているのだろうか．再発明を避けることは，実際には素人が考えるほどには簡単ではない．平た
会社側から待遇改善を勝ち取る交渉テクニック - 分裂勘違い君劇場 by ふろむだ
不況のせいか、長時間＆高ストレス労働で身体をこわしてしまう人が増えているようなので、 そうなるまえに、個人で行える待遇改善交渉の事前準備とテクニックを整理してみました。 トピックハイライト 知識もないのに考えても無駄。本とネットで知識をゲットするのが先。 自分1人で考えてると独り善がりになりがち。情報交換＆相談できる仲間をゲットするのが先。 素人がヌルいこと考えてても愚かな対応をしてしまう。餅は餅屋。専門家に相談するのが先。 上司や会社側の、どの弱みに、どうつけ込み、どう使いこなすか。 上司や会社側の利害構造を、どう把握し、どうハックするか。 交渉のリスクは他人に押しつけ、自分は安全圏にいて、その果実だけを収穫する方法。 額に銃口を突きつけられながら(=失職→家計破綻)では交渉に勝てるわけがない。会社側の武器を無効化するのが先。 ヤクザが賠償金を脅し取るときに使う武器が有効。 上司や会社を
内定式（？）で入社前に予習した仕事のエッセンスが感動的だった件 - ミームの死骸を待ちながら
人生に一度きりしかない経験はいくつかあって、「新卒入社」もその一つに数えられる。10月の頭には内定式が行われる企業が多く、僕の内定先でも御多分に漏れず内定式があった...ことはあったんだが、かなり他とは毛色の違う内定式だったようだ。 社員さんや外部の社会人のお話などを聞いたものの、"式"の比率は全体の10%程度で、残りは1日かけて外部講師を招いた"研修"を受けていた。これが今回の題材である。ちなみに内定者は3人なんだけど、若手社員さんも加わっての研修ということで、新人研修的な側面もあったようだ。 本来は数日かけて行う内容を1日に詰め込んでいるし、とにかく厳しいよと事前に脅されていたので最悪の事態を色々と想定していた。肉体的に辛いのか（どこかの外資金融みたいにロッククライミング）、脳味噌的に辛いのか（とりあえず今日1日でサービスリリースしてね）、精神的に辛いのか（貴様ら内定者ごときにウジ虫ほ
自分のハートをココに込めたとわからせろ - GoTheDistance
さまざまなめりっとで取り上げてもらったので、もうちょい掘り下げて書いてみる。いつもあざーす！ ほとんどのヒトが、自分がありがったがっているもの、価値があると思っているものがなぜ大切なのかを、自分の言葉で語れない。 デザイン力の欠如 - さまざまなめりっと - はてなグループ::ついったー部 このPOSTは元々はハウツー本ってリクツを論じているだけだからつまんないなんだよな、っていう所から端を発しています。理屈を論じても、そこには発見が無いことも多い。だから｢ところで、なんでそれが大切なの？｣っていう質問に対して外から理屈や理論を持ってくる。いや、理由を聞いているのに理屈を持ってきてどうするのよ、と。理由は論理で無ければ構築できない。理由を理屈で返し続けるような会議は大抵泡のように浮かんでは消える。特に何かPUSHしている理由が理屈の場合は不幸の始まりだったりするので、気をつけたいところです
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
http://atnd.org/events/13324
優秀なエンジニアはどこにいて、企業はどうすべきか？
Prezi
自分戦略研究室 ― ＠IT自分戦略研究所