タグ

ブックマーク / daipresents.com (12)

  • 後輩がGitHub採用疲れの話をしてくれた

    たしか、採用面接の方針を話していて、それぞれの採用に関する価値観を聞いたときのこと。ある後輩が「GitHub採用つらい」という話をしてくれました。聞いてみると、たしかにすんなり納得できない部分もある気がします。 GitHub採用とは 最近のエンジニア採用では、応募者のGitHubアカウント情報が流れてくるようになりました。同様に、LinkedInアカウントも流れてきますね。書いてきたコードや経験がオープンになってきたということなのでしょう。 情報がオープンになり、人材の流動性が高まるのは、個人的にはうれしいことです。なぜなら、いろんなことをいろんな場所で経験できることに魅力を感じるからです。一つの会社でいろいろできるのも魅力的ですが、土台となる文化が同じだと、体験に差が生まれそうですし。また、景気に影響を受けるとはいえ、クビになっても仕事を見つけやすくなるかもしれない。 一方で、マネージャ

    後輩がGitHub採用疲れの話をしてくれた
    nakaji999
    nakaji999 2016/04/23
  • プログラミング経験年数って全然意味ないよね

    採用関係の勉強がてら、Webサービス開発をしている企業の、採用案内を調べたり比べたりしていてふと思いました。たまに見かける「Java開発経験年数3年以上」などの表記。これは応募者のスキルチェックに使っているのかなぁと思うのですが、全然意味なさそうです。 経験年数 = 実力とはいえない 仕事内容やその人のモチベーションにもよりますが、経験年数が多いほど実力が高いわけではありません。たとえば、 なんとなくこの業界に入って、なんとなく過ごしている人の3年 プログラミングが大好きで、休日も自前のアプリ開発に熱中している意識高い系の3年 は、多分「厚み」が違うはず。かといって「経験年数ゼロでも歓迎!」なわけではありません。 こう考えてみると、経験年数がその人を評価するときの「ものさし」として、ふさわしくない気がするんです。 職務経歴書もあてにならない そもそも、経験年数のような自己申告型の情報だけで

    プログラミング経験年数って全然意味ないよね
    nakaji999
    nakaji999 2015/05/22
  • ソフトウェア開発会社に未来なんてない、つーか滅びろ

    『「納品」をなくせばうまくいく』を読み終えました。このはソニックガーデンという、とあるドメインで話題のソフトウェア開発会社の話が書かれています。著者の倉貫さんとは何度か遊ぶ機会があり、以前からいろいろお話を伺っていたのですが、今日は書を読んだ感想を交えながら、自分なりに感じたことをぼろくそに書いてみようと思います。 システムインテグレーターというカースト制度を学ぶ 僕は新卒で中堅のSIerに就職しました。ほとんどが2次受けで、外資系のSIerに常駐してシステムを作ってました。その現場は、想像していたのとはちょっとちがって、X次受けという透明なカースト制度がありました。 「これ作っといて」みたいな感じで仕事を丸投げする人や、ろくにシステムもつくれないのに上流工程とやらで論理破綻した仕様書を作る人など、プロフェッショナルってなんだっけ? と考えさせられることばかりです。 また、1次受けだと

    ソフトウェア開発会社に未来なんてない、つーか滅びろ
    nakaji999
    nakaji999 2014/07/04
  • 詳説!Redmineを使ったスマートな開発プロセス改善(画面キャプチャ付き)

    最近は、課題管理システム、チケット管理システムがメジャーになっており、私もこの種のツールをサービス開発、ソフトウェア開発で利用し、開発プロセス改善を試みています。 今回は、Shibuya.trac第12回勉強会 ~チケット管理システム大決戦 第二弾~で紹介させていただいた、Redmine利用事例の詳細解説を、共有させていただこうと思います。上記、勉強会の資料は、こちらに公開されています。各種ツールの事例が詰まった内容ですので、ぜひご確認ください。 Redmineプロジェクト画面 上記が自社のRedmineプロジェクト画面です。私のチームは「A-Team」といい、すべての作業は「A-Team」プロジェクトで管理しています。トップページには、勤怠の連絡や、Redmineを利用するときのルールなどがまとめてあり、資料を見ていただければわかると思いますが、プロジェクトメニューにはたくさんのモジ

    詳説!Redmineを使ったスマートな開発プロセス改善(画面キャプチャ付き)
  • アジャイルなレビューをサポートするツールを5つ

    Agile2010のリサーチセッションで、アジャイルソフトウェア開発におけるレビューをテーマに発表をしている方がいらっしゃいました(資料はこちら)。発表者はMario Bernhartさんだったと思うのですが、彼は発表の中で、Continuous Changeset-Based Review(CCBR)という言葉を使っており、開発の最後でレビューに時間をかけるのではなく、コミットごと(Changesetベース)のレビューという戦略を考え、CCBRを実践するためのツールとしてReviewClipseを紹介していました。 開発におけるレビューのコストは大きいと思います。アジャイル開発だけでなく、通常の開発もサポートする効率的なレビューツールを探してみました。 Mylyn Reviews (ReviewClipse) BernhartさんおすすめのReviewClipseはMylyn Revie

    アジャイルなレビューをサポートするツールを5つ
  • Redmine Backlogsで簡単スクラム!スクラムマスターや開発チームとして使う編

    Scrum Process via Lakeworks in the Wikipedia 前回はプロダクトオーナとしての使い方を調べてみた。今回は、スクラムマスターの使い方をRedmine Backlogs :: Usage Scrum Masterを元に調べてみる。 スプリントバックログは、プロダクトバックログの上からチームのベロシティ分選択していくだけでよく、選び出されたストーリーにポイントを付け、スプリント内でストーリーが消化されるようにチームを支援するのがスクラムマスターの仕事になる。上の図だと全体にかかわるお仕事なのだが、Redmine Backlogsではスプリントバックログやスプリントが、舞台の中心になるのだと思う。 スクラムマスターとして使う ストーリーの調整はプロダクトオーナーともチームとも相談する必要がある。Backlogsではスプリントごとのベロシティも簡単に確認する

    Redmine Backlogsで簡単スクラム!スクラムマスターや開発チームとして使う編
  • Redmine Backlogsで簡単スクラム!プロダクトオーナーとして使う編

    前回、インストールまで終わったので、使い方を考えながら調べてみる。僕は認定スクラムマスターではないので、間違った認識があれば教えてくれるとうれしいです。 その前に、最近日語化ファイルを作ってくださったかおるんさんのロケールファイルをRedmineのBacklogsプラグインを使ってみた via かおるんダイアリーからGet! まずは、Redmine Backlogs :: Usage Product Ownerを参考に、プロダクトオーナーとしてのRedmine Backlogsプラグインの使い方を調べてみる。プロダクトプロダクトオーナーの役割についてはこちらを参照のこと。下の図でいうとプロダクトバックログの整備がメインの運用となる。 Scrum Process via Lakeworks in the Wikipedia プロジェクトメニューのBacklogsをクリックするとMaster

    Redmine Backlogsで簡単スクラム!プロダクトオーナーとして使う編
  • 私は日本を信じている – Agile Japan 2011に参加しました

    Agile Japan 2011に参加してきました。今年で2回目の参加です。今年は社内研修で使ったKPTボードを持ってきて、ポスターセッションで参加させていただいたのですが、朝にリンダ・ライジングさんが遊びに来てくれました。ちなみに、写真はリンダさん、@kappa4、@kawagutiの貴重な3ショットです。 リンダさんからいくつか質問を頂きました。 ProblemとTryにはどういう関係性を持っているか? => 新人研修なので結びつけるようにやってもらった。 Greatって何? => すっげーよかったとこを書いてもらった 付箋の色は何を意味しているの? => チームごとに色分けしている “こういうボードは好き”とコメントを頂いたのでうれしかったです。リンダさんはとってもチャーミングな方でした。 以下、参加したセッションの内容や感想など。 Fearless Change – 不安を乗り越え

    私は日本を信じている – Agile Japan 2011に参加しました
  • Trac vs Redmine!導入に悩む人のための7つの比較ポイント

    世の中には相反するものが存在します。例えば、ゴジラとモスラ。アジャイルとウォーターフォール。目黒と目白。アルジェリアとナイジェリア。そして、RedmineとTrac。 デブサミで大盛況だったチケット管理システム大決戦 JIRA vs Redmine vs Trac ユーザーが語る、なぜ私はこのツールを使うのかですが、各ユーザ同士の戦いを期待した人も多かったと思います。しかし、@ryuzeeさんの[Trac]デブサミでITSに関するセッションに登壇しました #devsumiにまとめられているように、ツールは「やりたいこと」を考えて利用し、それを「使う人が改善していくこと」が大切なので、戦わせるのはとても難しい。 はじめに 私世代の人間ならば、「孫悟空とドラえもんはどっちが強いか」といったことに興味を持ってしまい、RedmineとTracもガチンコ勝負させたくなるものです。また、チケット管理シ

    Trac vs Redmine!導入に悩む人のための7つの比較ポイント
  • アジャイルに結婚式準備を行うために必要なただ1つの方法

    私は、昨年結婚したのですが、結婚式の準備はとても大変だということがわかりました。 そして、メンバーは自分と嫁(当時はベータ)の二人だけです。この状況の中で、いかにアジャイルに進めて、結婚式の価値をあげればいいかをまとめたいとおもいます。ネタはShibuya.trac10回勉強会のものです。まず、先のつぶやきから、いろいろな人から励ましの言葉をいただきました。 これらのアドバイスのおかげで、作業の優先度を誤らずに対応できました。ありがとうございます。 アジャイル界の方々からは、様々なプラクティスを教えていただきました。ありがとうございます。 チケット管理でタスクを考えることも考えましたが、思わぬ落とし穴があることを教えてくれた方もいらっしゃいました。ありがとうございます。 チケット管理でタスクを運用するのはとてもパワフルなやり方です。しかし、やり方をまちがえれば、チケット管理自体がヘビーなプ

    アジャイルに結婚式準備を行うために必要なただ1つの方法
  • 3年使ったRedmineの使い方について共有したい10のこと

    前回は、1000人のエンジニアRedmineを使い出すまでの事例を紹介させていただきました。今回は、Redmineの使い方や、大規模に変化してくRedmineの運用について、2年間の運用や改善から得たナレッジや、気がついたことをまとめていこうと思います。 1. Redmineのオブジェクト構造を理解した方がいい Redmineは以下の構造になっているので、タスクの属性をうまく分類する必要があります。 プロジェクト > サブプロジェクト > バージョン > 親チケット > 子チケット > トラッカー > カテゴリ 注意したいのは、プロジェクト・サブプロジェクトには期限が設定できず、バージョンには終了日時、チケットには開始日時と期限をつけることができる点です。期限があるものには、期限のあるものを当てはめるのがすっきりします。Redmineを使って「何を」「どう」管理していきたいのかを、まず考

    3年使ったRedmineの使い方について共有したい10のこと
  • Redmineが1000人のエンジニアに使われるまでのこと

    デブサミ2011の後に、Shibuya.tracの第10回勉強会で初LTをしました。テーマは「EnterpriseレベルのRedmine導入結果について」です。外の勉強会は緊張しますが、@yusuke_kokuboさんや@akipiiさん、アジャイルなゆかいな仲間たちにお会いすることができ、とても楽しい勉強会でした。また学びに行かせていただこうと思います。 はじめに 上の資料はそのときのものです(Slideshareはこちら)。5分間のLTだったため、あまり詳細をお話しすることができませんでしたが、勉強会の時に知り合った方と、今度、Redmine導入&運用の情報交換会を企画しており、そこで共有するネタとして、まずは、Redmine導入時の経験をここにまとめようとおもいます。まずはその前に、私の仕事内容を少しだけ説明させてください。 標準化とか全社共通とかいう仕事 私は入社以来、サービス開発

    Redmineが1000人のエンジニアに使われるまでのこと
  • 1