自分の失敗を完璧にフォローされて涙が出るレベルな件｜NZ MoyaSystem
いま勤めている会社ではアジャイル開発を取り入れており、2週間を1スプリントとして管理しています。 各スプリントの終わりにはチーム内での実績報告とレビューを行います。今日はそのレビューでの話。 超絶無能だった自分 そのスプリントでの自分のパフォーマンスは最悪でした。 とある一見単純なバグ修正を、鼻歌交じりで「ふふ〜ん」とコミットしたら、 「残念！ こっちの機能が壊れてます。やり直し :)」 とリーダーからあっさりコードレビューで却下される始末。コードレビュー前に当然走らせておくべきユニットテストの結果確認を怠っていたので何も言い訳できませんごめんなさい……。 で、またコーディングのやり直しとなるわけですが、やればやるほどユニットテストが壊れていくんですよ……。 あちらを立てればこちらが立たず地獄。もともと様々な条件にうまーく対応するように書かれているデリケートな処理なので、ヘタにいじれない部
なぜプロジェクトは炎上するのか？炎上しやすい4つの傾向と、炎上を防ぐ3つの対策 - paiza開発日誌
Picture by ITエンジニアを目指す女子高生たちの学園ライフ4コマ漫画『ぱいじょ！』 こんにちは、谷口です。 某Mずほ銀行の案件のニュースが出たとき、弊社でも結構話題になりました。 あんなに巨大なプロジェクトをしずめるのは、もう本当に不可能なんじゃないかと思いますが、どんなに大きな炎上も、恐らくは小さな火種が集まって、やがて大きな炎となってしまった結果だと思いますし、最初の小さな火種の段階からぷちぷち消していけたらこんな結果にはならなかったはず……。 という話をしていたときに、paizaのエンジニアが「かつて炎上しているプロジェクトに自ら突入していくのが趣味だった」などと言い出しました。「そういう性癖なのかな」と思ったんですが、聞いてみると 「炎上しているプロジェクトに行くと『優秀な人たちはどんな振る舞いや働きをして炎上をしずめているのか』『何が原因で炎上したのか、どの時点で何をし
プログラムにコメント書かない文化もあるよって話｜NZ MoyaSystem
以下の記事を読んで。 530000micro.hatenablog.com 僕が勤めている会社では、原則、プログラムにコメントを書かないのがルールです。 人生で初めてプログラムに触れてからこのかた、プログラムには必ずコメントを書けと指導されて来ましたし、自分自身も、後輩たちにちゃんとコメント書けよと言い聞かせてきました。そんなわけで、最初に全然コメントのないソースコードの山を見たときは、正直「ゲッ、なんじゃこりゃ……」と面食らったのは確かです。 ところが、「なぜうちのプログラムにはコメントがないのか？」と同僚に尋ねてみると、実に納得の行く回答が返ってきたのでした。 なぜコメントが必要なプログラムを書くのか？ 同僚いわく、「コメントが無くても読めるようなプログラムを書け」という思想が根底にあるのだそう。 適切に関数や変数が命名され、スコープがきちんと管理され、ロジックの流れが整理されているコ
［ITエンジニア徹底調査2］弱まる転職志向、やりがいを感じない若手が増加
前回に続いて、ITスキル研究フォーラム（iSRF）が国内で就業するITエンジニア1万3287人を対象に実施した調査結果を紹介する。今回は将来のキャリアと仕事のやりがいに焦点を当てる。過去6年間の推移を見ると、今の会社にとどまることを前提にキャリアを考えるエンジニアが増えている。やりがいに関しては、30代以下の若手世代で「やりがいを感じない」との回答が増加傾向にある。 次にキャリアに関する経年変化を見てみる（図4）。今回、最も多かったのは「今の会社の中で、ITエンジニアとしてステップアップしていきたい」（34.4％）。「今の仕事でステップアップしていきたい。別の会社に移ることも視野に入れている」（29.6％）が続く。明確に独立を視野に入れている「今の仕事で築いたノウハウや人脈を生かして、独立開業したい」と答えたエンジニアは3.7％にとどまる。
それ、開発しないほうがいいですよ | rake enjoy
うちの会社が開発会社なのと会社名からちょいちょいサービス立ち上げの相談を受けます。そこでどういったサービスを立ち上げるのかなど色々お伺いしていくんですが、結構な確率でお断りすることが多いんですね。その際に 「それ、開発しないほうがいいですよ」 と伝えさせてもらってます。うちは開発会社なので、仕事として請けたほうがメリットも大きいんですが、多分結果誰も幸せにならないだろうなーと思って止めさせてもらってます。 割と同じような話を何回もさせてもらっているので、今回は改めてまとめてみたいと思います。 開発はお金がかかる まず、ここの認識を持ってもらいたいのですが、開発をはじめてしまうと非常にコストがかかるんです。今時はサービスを立ち上げる場合、ローンチして終わりではなく、継続して改善し続けないと成長しないどころか立ち上がってもきません。ですのでリーンスタートアップにも書かれているように小さく立ち上
Shibu's Diary: 僕のプログラマ人生を賭けてITエンジニア本大賞2016に推薦したい本はこれ
渋日記@shibu.jp 渋川よしきの日記です。ソフトウェア開発とか、ライフハックを中心に記事を書いていきます。 岩切さんがITエンジニア本大賞の募集をしていました。技術書とビジネス書の2カテゴリがあるんですが、それぞれのカテゴリで、2015年に出会った本で、「やばい、これは10年以上待ち望んでた次の時代の道標になる本だ」というものがあったのですが、清き平等な一票ではこの気持ちは伝わらないと思い、筆を執った次第です。 一応僕のことをあまり知らない人も多いと思うので一応説明しておくと、学生のころに日本XPユーザグループの設立準備から関わっていて、アジャイルという言葉が出る前から「仕様書通りにしかコーディングできない世界つまらなそうだし、XPなんか面白そうだな！」と思っていて、イベント運営をしてみたり、C++やらPythonやらRuby(とちぎ)やらのコミュニティに参加したり、ドキュメントツー
@naoya_ito さんの結論がでてないことまとめ(2015/11/25)
naoya @naoya_ito 結論がでてないこと: 実装都合で要件に制限を加えることは一見正しくないが結果複雑なクエリとか既存の設計では無理のある歪みが生じたりする。自分で自分のソフトを書いてるときは、そういうのは避ける。長期的にみるとそれがゆえにシステムもユースケースもシンプルに留まる。けど、機会損失もある
IT勉強会で懇親会をするとき気をつけること - とあるインフラエンジニアの日常
これまで、江戸前セキュリティ勉強会やまっちゃ445勉強会を中心に、IT勉強会で懇親会の担当をする機会に多く恵まれてきました。 その中で、懇親会を企画する際に、気をつけたほうがいいと思ったこと、これまでうまくできなかったことを、 参画から5年（もうすぐ6年）の節目で、一度まとめておきたいと思います。 色々と教えて頂いたid:ripjyr id:vulcainに多謝！ 予約者数 勉強会参加者の6割が入る箱を探す (9/23追記)上記人数は規模に応じて想定割合は変更する。上記の数字は勉強会出席者が100人の場合の想定 (9/23追記)下記は一例（勉強会参加者が多いほど人数が読みづらいけど、多いほど懇親会出席率は低くなる傾向があると思う） 勉強会参加者＜ 70人 → 0.7-0.8 勉強会参加者＞ 100人 → 0.55くらい(少し少なめ） 当日になってキャンセルが出るのは日常。経験則では5-10
ITエンジニアの業務時間外の学習 - 勘と経験と読経
時間外学習に関するブログ記事をタイムラインで目にして考えたこと。ちなみに業務時間外に学習するかどうかは趣味の問題だと思っている。 業務時間外で勉強をしなければいけない理由：101回死んだエンジニア：エンジニアライフ 業務時間外の勉強が必須なんてことはない IT業界は技術の流れに置いていかれるとしんどい思いをする。業務時間外の勉強は必須だ。しかし、おかしな話ではないだろうか。なんで時間外に仕事のための技術を勉強しなければならないのだろうか。 本来であれば、業務に必要なことは業務時間内で教えるべきだと思う。だが、今時そんな余裕のある会社なんて無い。やって当然という雰囲気はあるが、やるだけの理由を説明できる人は少ない。大半が「仕事に必要だからやるんだよ！」としか言わない。 業務時間外で勉強をしなければいけない理由：101回死んだエンジニア：エンジニアライフ 業務時間外の勉強が必須なんてことはない
「エンジニア不足を嘆く」という慢性的な病に対して一言モノ申す【村上福之】 - エンジニアtype | 転職type
日々流れてゆく膨大な情報量の中からおいしいネタを敏感に察知し、ネット界隈を賑わせてくれるWeb業界の異端児・村上福之氏。同氏独自の経験と価値観から、「キャラ立ちエンジニア」の思考回路を紐解いていく。 株式会社クレイジーワークス 代表取締役 総裁 村上福之（@fukuyuki） ケータイを中心としたソリューションとシステム開発会社を運営。歯に衣着せぬ物言いで、インターネットというバーチャル空間で注目を集める。時々、マジなのかネタなのかが紙一重な発言でネットの住民たちを驚かせてくれるプログラマーだ いろんなベンチャー企業から、異口同音に「エンジニアが足りない」という話を見聞きします。中には、「使えるやつがいない」とか言い出す髭を生やしたベンチャー社長とかもいたりします。 そんな人たちに一言モノ申したい。ええとな、人類がこの世に生まれてから今まで、エンジニアが余ってた時の方が少ないんだよ。 90
第1回ペパボテックカンファレンス参加レポート - りあるふぁいとぷろぐらまー
渋谷のセルリアンタワーGMO Yoursにて第1回ペパボテックカンファレンスが開催されたので、参加レポートです。 開会の辞 なぜ、開いたか あんちぽくんさんより 色んな会社が自社のテックカンファレンスをやっているので、やってみたかった 領域が広い → 普段やっていることを話せば面白いかも これからのペパボの技術 by あんちぽくんさん speakerdeck.com ペパボがなにを考え思いエンジニアリングしているのか これからどうエンジニアリングするのかを話していく これまでやってきたこと 技術基盤の改善 基本事業部制で縦割りだったのを技術基盤チームを作ったことで横につなげた 技術的な改善&エンジニアが言うことを聞き入れてくれる組織作り CTOとは 経営をすることのみ それ以外はない 経営の中で技術を担う 今後の技術的展望 １.マイクロサービシーズ化 色んな言語で細分化して小回りがきくよう
新刊『スクラム実践入門』の紹介、あるいは、日本のソフトウェア開発の夜明け - delirious thoughts
発端は確か一昨年のCROSSで、@hsbtさん、稲尾さんの間で話が盛り上がったのが最初だったと記憶しているから、あれから約2年、強力なメンバーで共同執筆した『スクラム実践入門──成果を生み出すアジャイルな開発プロセス』が、いよいよ3/18に刊行される。 追記: 3/18に発売されました。 Amazonのリンクは以下。電子書籍をご希望の方は、版元のサイトで発売と同時に販売されるはずなので、そちらをお待ちください。 スクラム実践入門 ── 成果を生み出すアジャイルな開発プロセス (WEB+DB PRESS plus) 作者: 貝瀬岳志,原田勝信,和島史典,栗林健太郎,柴田博志,家永英治出版社/メーカー: 技術評論社発売日: 2015/03/18メディア: 単行本（ソフトカバー）この商品を含むブログを見る スクラムに関する類書は既にたくさん出ているし、それぞれに素晴らしい本ばかりで、いまさら屋上
[IPA] デスマらないために「超上流から攻める IT 化の原理原則17ヶ条」が思った以上に使える件 [要件定義] | oshiire*BLOG
「超上流」という言葉自体はとても気に入らないけれども、IPA 独立行政法人 情報処理推進機構 が作って公開している「超上流から攻める IT 化の原理原則17ヶ条」が、当たり前のことを当たり前に並べてあってとても役に立つ。 原理原則 17箇条 ユーザとベンダの想いは相反する 取り決めは合意と承認によって成り立つ プロジェクトの成否を左右する要件確定の先送りは厳禁である ステークホルダ間の合意を得ないまま、次工程に入らない 多段階の見積りは双方のリスクを低減する システム化実現の費用はソフトウェア開発だけではない ライフサイクルコストを重視する システム化方針・狙いの周知徹底が成功の鍵となる 要件定義は発注者の責任である 要件定義書はバイブルであり、事あらばここへ立ち返るもの 優れた要件定義書とはシステム開発を精緻にあらわしたもの 表現されない要件はシステムとして実現されない 数値化されない要
![[IPA] デスマらないために「超上流から攻める IT 化の原理原則17ヶ条」が思った以上に使える件 [要件定義] | oshiire*BLOG](https://cdn-ak-scissors.b.st-hatena.com/image/square/bfb41ba2bfefb166491d5d3e83380136f2017ab2/height=288;version=1;width=512/http%3A%2F%2Foshiire.to%2Fwp-content%2Fuploads%2F2015%2F01%2F17principles-300x212.png)
地方に暮らすエンジニアの抱える課題と希望 | Social Change!
先日、島根県の松江で行われた「松江Ruby会議06」というイベントで講演をしてきました。講演のテーマは『「納品のない受託開発」とエンジニアの働きかたのこれから』というもので、「納品のない受託開発」「地方」「Ruby」「ギルド」について話して欲しいと依頼を受けました。 色々と新しいネタも入れた資料ですが、今回の記事では、地方で働くエンジニアについて、その講演で話したことをもとに考えてみたいと思います。 “地方”を言い訳にしている人たち あちこちの地方に講演で伺うことも多く、懇親会などに参加すると地方における問題を聞かされます。確かに様々な問題があるのもわかります。だからといって何か提案をしても「そうはいっても地方だと難しい・・・」という言葉をよく聞くのです。 しかし、果たして本当に「地方」が問題なのでしょうか。 そこで思い出すのは、東京にいても現状を変えようとしない人たちの言葉です。彼らはこ
アジャイルが否定したものを見直そう - arclamp
2014/9/6に開催されたXP祭り2014で「アジャイルを手放して得られたこと」という講演をしてきました。Togetterはこちらから。 元々は「アジャイルのダークサイド」の話がしたくて応募したのですが、その後、いろいろと考えているうちに僕自身にも気づきの多い内容となりました。 さて反応を見てると前半のアーキテクチャとマネジメントの話に興味を持っていただいたようです。なので、このブログでは「なぜアーキテクチャとマネジメントの話からアジャイルの話をしたのか」ということを書いてみます。 アジャイルがさまたげたもの アジャイル開発手法が大きく注目されるのは1999年の「Extreme Programming Explained」の出版であり、2001年の「アジャイルソフトウェア開発宣言」です。1990年代後半から2000年代初頭というのは、IT産業が大きく成長する時代であり、同時に、当時主流で
92five app
Experience a soujourn transcending elegant features comprehensively designed for a team of any size. Projects Say hello to a novel, state-of-the-art app for project management. Tasks Punctuality is one of the cardinal business virtues. Keeping this maxim in mind, Tasks have been designed to adhere to deadlines.
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
情報共有から始めるチーム開発とキャリア戦略
エンジニアコミュニティで組織は動き出す
「知ってるつもり」では恥ずかしい 基礎から学ぶ、新入社員に教えたい「IT新常識」 － TechTargetジャパン
チケット管理システム大決戦 JIRA vs Redmine vs Trac ユーザーが語る、なぜ私はこのツールを使うのか
