「知ってるつもり」では恥ずかしい 基礎から学ぶ、新入社員に教えたい「IT新常識」 － TechTargetジャパン進化の激しいITの世界。新入社員にIT知識を伝えようにも、数年前の知識は陳腐化しているかもしれません。新年度を控えた今、TechTargetジャパンの入門記事で重要技術の今を確認しましょう。
第1回ペパボテックカンファレンス参加レポート - りあるふぁいとぷろぐらまー
渋谷のセルリアンタワーGMO Yoursにて第1回ペパボテックカンファレンスが開催されたので、参加レポートです。 開会の辞 なぜ、開いたか あんちぽくんさんより 色んな会社が自社のテックカンファレンスをやっているので、やってみたかった 領域が広い → 普段やっていることを話せば面白いかも これからのペパボの技術 by あんちぽくんさん speakerdeck.com ペパボがなにを考え思いエンジニアリングしているのか これからどうエンジニアリングするのかを話していく これまでやってきたこと 技術基盤の改善 基本事業部制で縦割りだったのを技術基盤チームを作ったことで横につなげた 技術的な改善&エンジニアが言うことを聞き入れてくれる組織作り CTOとは 経営をすることのみ それ以外はない 経営の中で技術を担う 今後の技術的展望 １.マイクロサービシーズ化 色んな言語で細分化して小回りがきくよう
開発者の生産性：Noと言える技術 | POSTD
生産性を維持するのは難しいことです。 特に開発者の立場では。 ゾーン（超集中状態）に入るには時間がかかりますが、入ったゾーンから引きずり出されるのは簡単です。 例えば、 * ミーティング * Eメール * 作る予定の機能や、修正すべきバグ などに意識が分散されてしまいます。確認しておかないと、気付いたら何もする時間がなくなっています。 これを解決するための秘策があります： あらゆることに” no “と言うのです。 私たちのやり方をお教えしましょう。 ミーティングは木曜日だけ ミーティングは生産性を奪います。私たちは経験から、いつもミーティングの前後に45分の時間が消えてしまうことに気付きました。さらに、Skypeでのたわいないおしゃべりでも15分間が失われます。 45分後にミーティングがあると思うと、重要なことは始められません。同じように、電話やミーティングが終わってから、即座に大きな問題
泥沼プロジェクト振り返り
はじめに ちょっと前まで結構激しく泥沼化したプロジェクトにいた。 その頃はプロジェクトも僕も相当疲弊していて、何も考える時間がなかった。 ある程度、月日が経って今なら もう少し客観的にあの頃のことが考えられるかなと思い書いてみることにする。 振り返りをし、自分としてもプロジェクトとしてもどうあるべきであったかとか そういう立派なことが考えられればいいのだが。 とかく、Slide Shareとか世の中は成功事例は多く発信される。 けど、失敗事例のほうが共通して当てはまったりする。 前提 ・古典的なウォータフォール ・古典的なStruts1系ベース内製フレームワーク ・Java SE 6 ・QAとかいない ・デザイナーとかいない ・フロントエンドエンジニアとかいない アンチパターン 当時のプロジェクトを振り返って、明らかにこれは駄目だっただろというところ。 ◆プロジェクト全体 ・決定者がいない
「進捗どうですか？」より2015倍捗る「困ってますか？」 - Qiita
概要 お願いした作業の進捗を聞くときには「進捗どうですか？」より「困ってますか？」と聞くほうが何倍も捗るよ、というお話。 タイトルの2015倍は冗談です。念のため。 「進捗どうですか？」はダメです あけましておめでとうございます。ところで皆さん進捗どうですか? ・・・いやー、流行りましたね。 この「進捗どうですか？」はtwitter上で使うと「最近どうよ、忙しいの？」程度の挨拶で面白みがあるのですが、実際に仕事で使うとなんのいいこともないと思うのです。 質問攻め いいことがないと思う理由は、「進捗どうですか？」は質問攻めになりやすいと思うからです。「進捗どうですか？」の先に待っているやりとりはだいたいこんな感じです。 「進捗どうですか？」 「進捗ダメです。」 「どこがダメなの？」 「単体テストが遅れています」 「どれくらい遅れてるの？」 「えーと・・・、0.5日分くらいです」 「項目数でい
イライラを解消！ 乱立するRedmineの情報をまとめて確認できる環境を構築する
開発の新しいツールや技術は、全社・部署全体という大きなレベルではなく、小さなチームやプロジェクトがトライアル的に導入されることが多いと思います。その結果、普及期に入ったころにはシステムや運用ルールの統合がとんでもなく難しくなってはいないでしょうか。開発タスクを10倍気持ちよくする環境構築のノウハウを紹介していく本連載の第1回目として、今回は複数のRedmineでバラバラに登録されているチケットを横断的に照会、集計する仕組みを解説します。 プロジェクト管理サイト、管理できていますか？ 弊社では、有名なプロジェクト管理向けWebアプリケーションツールの1つ「Redmine」を、弊社の主力製品であるERPパッケージの開発で利用しています。 RedmineはRuby on Railsを利用したオープンソースのツールで、利用事例も非常に多数あります。 ただし、弊社の開発部隊は1,000名を超える開発
チケット管理システム大決戦 JIRA vs Redmine vs Trac ユーザーが語る、なぜ私はこのツールを使うのか
チケット管理システム大決戦 JIRA vs Redmine vs Trac ユーザーが語る、なぜ私はこのツールを使うのか
あなたのスタートアップのアイデアの育てかた
スタートアップのアイデアを得る方法について、Y Combinator (Paul Graham, Sam Altman, Paul Buchheit) と Peter Thiel、Chris Dixon の考え方を中心に解説したスライドを書きました。タイトルは「あなたのスタートアップのアイデアの育てかた」です。 アイデアの発案の仕方については諸々ある書籍や資料から学んでいただければと思うのですが、今回は主にスタートアップのアイデアについてという一部領域でのアイデアの気づきかた、育てかたに絞って解説しています。 もちろんこの方法が唯一の正解の方法であるとは限りませんし、仮に正しいプロセスだとしても、正しいプロセスから素晴らしいスタートアップのアイデアが常に出てくるわけではありません。ただ、Y Combinator をはじめとした彼らの考え方は、一つの参考になる考え方ではないかなと思いますので
エンジニアがデザインに取り組んでわかったこと
最近、いくつかのデザインに取り組んでわかったことがあるので、書いておこうと思う。 ぼくは2,3年前にこの業界に入ってからずーっとフロントの実装畑でやってきた。 それは自分の意図していたものではなかったけど、前職のまぼろしという会社は実装が強みの会社だったので、デザインに触れることはほぼほぼなかった。 それもあってか、ぼくは「もうちょっとコストを考慮してほしい」「このあしらいが一体ユーザーにいくらのお金を落とさせるんだろう」とか、あげくの果てには「実装のことを考えたデザインをすべき」とまで考えていた。これらの考え方はぼくだけでなく、コーダーからよく同様の声が上がっている。 だけどデザイナーさんと接する機会が増えるごとに、デザインができるようになったら今までイラついていたことがどんな風に見えるのか確かめたいな、という気持ちになった。 それ以外にも「なにか作るとデザイナーばかり褒められて厳しい」
あなたの足を引っ張る、よくある「生産性の勘違い」 | ライフハッカー・ジャパン
私たちはみな、賢く働きたいと思っています。でも、ときどき、前に進んでいるのか、ただ空回りしているのかわからなくなります...。プレッシャーがあるほうが仕事ができるんだ、という人がいます。しかしそれは、先延ばしを正当化しているだけかもしれません。今回は、私たちを助けるというよりはむしろ邪魔をしている、「生産性にまつわる勘違い」を紹介します。 トレーシー・フォークス氏（Get Organised South AfricaのCEO）は、私たちの多くが「忙しさという仕事に忙しい」状態にあると言います。 「私たちはいつも会議から会議へと駆け回り、仕事に忙殺されています」と彼女。「多くのことをこなすのが大切なのではありません。大切なのは賢い選択をすることです」 生産性コンサルタントであるフォークス氏は、さまざまな企業の社員たちの前で、仕事の管理について話すそうです。「よく、自分は組織にとって価値ある存
若手開発者の後悔 | POSTD
(編注：2020/08/18、いただいたフィードバックをもとに記事を修正いたしました。) これはある仕事熱心な若手開発者のほぼ実話です。2004年の後半、この若手開発者は小さな会社で働き始めました。条件は全て彼の望みどおりでした。給料はいいし、扱うのは彼の得意とするプログラミング言語、アプローチの複雑性、モデリングのアーキテキチャでした。 彼にとって今回の会社が初めての職場ではありませんでした。しかし、ここでの最初のプロジェクトは結果的に 問題だらけ に終わりました。当時、この若手開発者は、機能は絶対に変わらないものだと思っていました。しかし、それは間違いでした。機能が変更されるたびに完全なリファクタリングを行わなければなりませんし、バグを引き起こして膨大な時間を無駄にしてしまいます。彼は、テストを書くといった実直な方法も試してみましたが、書いたテストはメンテナンスが必要な上、書くのに時間
7年働いた時点での私の仕事の極意 - Kengo's blog
最重要 実行に重きを置く やらないで後悔するよりも、やって反省する。 反省は成長を産み生産的だが、後悔は精神の無駄な消費。 時間は有限で貴重な資源だが、たぶん今の段階では行動する前に得るものや結果を予測するのは難しい。 正しい反省の方法とは何か、考え続けること。 「正しく反省するために、何を記録しておくべきか」実行前に明らかにしておくこと。 反省の結果は組織的な何かに落としこむ。組織構造、戦略、静的解析、自動テスト、教育など。意識しないでも巨人の肩に乗れる状況を作ることが、組織の成長につながる。 Done is Better Than Perfect ただし、思考停止の言い訳にしないこと。詰めの甘さを擁護する言葉ではない。詰めの甘さは立場や考え方が違うひと3人くらいに意見を求めればだいたい炙り出せる。 長期的視野を持ちつつ、それに引っ張られない。進展を作ること、現状を少しずつ変えることを意
技術的負債について - 表道具
2015-03-19 技術的負債について スタートアップや新規事業に限った技術的負債の考え方f-shin.net ちょっとこの記事は酷い．品質と開発スピードを兼ね備えたコードは，そもそも致命的な技術的負債ではないだろう． 現代的なスタートアップのプロダクトでは，シンプルなものを作って世に出すというのはあまり起こらない．いわゆる「仕組み作り」と言われるものをやらなければならず，そのために何を作るかを練った場合，凄まじい天才で無い限り，様々な概念をつなげた複雑なシステムを作ることを考えてしまう．アイデアもガンガン出てくるし，その優先度もつけられずただデカくなっていく．その意味で，スタートアップ段階で必要になるコードの規模は思っていたより大きいことが多い．それを事前にうまく落とそうという試みがリーン・スタートアップであるとも言える． 例えば現在のマーケットで「猫の鳴き声を共有するサービス」があっ
チームワークは「仲良しごっこ」ではない | サイボウズ式
【サイボウズ式編集部より】この「ブロガーズ・コラム」は、著名ブロガーをサイボウズの外部から招いて、チームワークに関するコラムを執筆いただいています。今回ははせおやさいさんが考える「本当のチームワーク」について。 春は異動の季節です こんにちは、はせおやさいです。 春ですね。3月ですね。異動、転職の時期ですね。 みなさまの身の回りでも異動になったり転職してきたり、新たな出会いがあるのではないでしょうか。 さて、新しいチームが組成されたとき「チームワークを発揮して結果を出そう」と言いますが、この「チームワークがいい」というのは具体的にどんな状態でしょうか。 チームメンバーの仲が良く、いつも楽しそうなこと？ チームリーダーに人望があって、全員の気持ちが1つになっていること？ 「仲良き事は美しき哉」と申しますが、ビジネスシーンにおいて、「チームワーク＝チームの仲が良い」というのは、残念ながら誤った
糞システムにしないため、私ができること『はじめよう！ 要件定義』
「なぜ糞システムができあがるか？」の答えは、「一つ前の仕事をしている」に尽きる。 詳しくはリンク先を見てもらうとして、まとめるなら、自分の仕事のインプットが出来てないので、仕方なく前工程の仕事を代行しているうちに、リソースと気力がどんどん失われているからになる。これはプログラマに限らず、SEからPM、テスタや運用を入れても、当てはまる。「何をするのか」が決められない経営層が糞だから、あとはGIGOの法則（Garbage In, Garbage Out）に従う。 では、どうすればよいか？ 「“何をするのか”を決めてもらう」という回答だと、連中と同じ肥溜めに落ちている。なぜなら奴らの“目標”とは、「売上を○％ストレッチする」とか「新規市場を開拓する」といった、現状を裏返した願望にすぎないから。売上アップ／新規開拓のために、どこに注力して、何にリソースを使い、そのために必要な道具（システム）を“
新刊『スクラム実践入門』の紹介、あるいは、日本のソフトウェア開発の夜明け - delirious thoughts
発端は確か一昨年のCROSSで、@hsbtさん、稲尾さんの間で話が盛り上がったのが最初だったと記憶しているから、あれから約2年、強力なメンバーで共同執筆した『スクラム実践入門──成果を生み出すアジャイルな開発プロセス』が、いよいよ3/18に刊行される。 追記: 3/18に発売されました。 Amazonのリンクは以下。電子書籍をご希望の方は、版元のサイトで発売と同時に販売されるはずなので、そちらをお待ちください。 スクラム実践入門 ── 成果を生み出すアジャイルな開発プロセス (WEB+DB PRESS plus) 作者: 貝瀬岳志,原田勝信,和島史典,栗林健太郎,柴田博志,家永英治出版社/メーカー: 技術評論社発売日: 2015/03/18メディア: 単行本（ソフトカバー）この商品を含むブログを見る スクラムに関する類書は既にたくさん出ているし、それぞれに素晴らしい本ばかりで、いまさら屋上
Web・ソシャゲ系エンジニア就活記録
Yahoo大企業だけあって普通。非エンジニア職の人事面接さえ通過できれば余裕。私服で大丈夫。 dwangoスーツは逆に浮く。なんだかんだ言ってWebテストは受けさせられるけどなんの参考にもしてなさそう。最終以外は現場のエンジニアが面接官なので適当に興味のある技術の話しとけば大丈夫。最終だけは多少圧迫(こっちの話に食いついてこない)というか「落とす」面接なので注意。 Pixiv説明会で社長の話聞いたら受ける気なくしたのでよくわからない。自分についてのキーワード100とか書かされる。 クックパッド自分も自分の周りも誰も通らなかったからよくわからない。Web上で簡単なプログラミングさせられるけど本当に簡単でなんで落ちたのかよくわからない。 サイバーエージェント女性人事が友達感覚で話しかけてきてアレ。技術の話より一発当たるサービスのアイデアみたいなの用意しといた方がいい。 DNA基本的に現場のエン
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
conasu
コードレビューのススメ
プロジェクト設計において使えるさまざまな手法をまとめた『Design Research Techniques』 | 100SHIKI
