開発組織マネジメントのコツ - Speaker Deck一人 CTO Night での発表資料です
開発サーバ構築しよう～LDAP（認証基盤）を立てよう～開発サービスはDockerで立てよう
LDAPサーバ立てよう 開発プロジェクト用の開発サーバ構築の一貫として SCM(Subbversion, Git)を立てるにしろ ITS(Redmine, Trac)を立てるにしろ CIサーバ(Jenkins)を立てるにしろ モジュールリポジトリサーバ(Nexus)を立てるにしろ Wiki(MediaWiki)を立てるにしろ コードインスペクション用サーバ(SonarQube)を立てるにしろ メールサーバ(Dovecot+Postfix)を立てるにしろ 他もろもろを立てるにしろ 大概そいつらにはメンバーごとのログインという共通要件があります。 メンバーが追加されるたびに、手順書を更新していちいち各サービスのユーザ登録手順を増やすのもいいんですが、そういうことやってると、 登録・削除が面倒だったり、 アカウントIDやパスワードがサービスごとブレはじめたり、 大変不便なので、Open LDAP
俺の価値創造契約
〜新しい契約形態での受託開発サービス立ち上げ 1,396日間の記録〜 2010年11月に「価値創造契約」を発表してから4年。数案件を実施し、さまざまな経験をしてきました。その貴重なエピソードを発表します。 @XP祭り2014
ソフトウェア開発会社に未来なんてない、つーか滅びろ
『「納品」をなくせばうまくいく』を読み終えました。この本はソニックガーデンという、とあるドメインで話題のソフトウェア開発会社の話が書かれています。著者の倉貫さんとは何度か遊ぶ機会があり、以前からいろいろお話を伺っていたのですが、今日は本書を読んだ感想を交えながら、自分なりに感じたことをぼろくそに書いてみようと思います。 システムインテグレーターというカースト制度を学ぶ 僕は新卒で中堅のSIerに就職しました。ほとんどが2次受けで、外資系のSIerに常駐してシステムを作ってました。その現場は、想像していたのとはちょっとちがって、X次受けという透明なカースト制度がありました。 「これ作っといて」みたいな感じで仕事を丸投げする人や、ろくにシステムもつくれないのに上流工程とやらで論理破綻した仕様書を作る人など、プロフェッショナルってなんだっけ？ と考えさせられることばかりです。 また、1次受けだと
なぜ開発で見積り失敗して忙しくなりがちなのか(アジャイルな見積りと計画づくり読んだ) - $shibayu36->blog;
最近タスクがどのくらいで終わるか見積もることが多いんだけど、そのたびにうまく見積もりができてなかったり、思ったより長引いてしまってすごく忙しくなってしまったり、といったことが何度かあった。このままじゃ良くないなーと思って、「アジャイルな見積りと計画づくり」を読んだ。 アジャイルな見積りと計画づくり ~価値あるソフトウェアを育てる概念と技法~ 作者:Mike Cohn,マイク コーン毎日コミュニケーションズAmazon 実際読んでみると今の状況に非常にぴったりで良い本だった。この本を読んでいくと、最初から正確な見積りをするのは不可能で、作業をしながら見積りの精度をあげるといったり、変更やリスクに強いスケジュールをうまく作るということをしていく必要があるということが分かる。なんとなく自分がタスク管理をしないといけなくなったけど、なんかうまくいかないと思っている人には非常に参考になると思う。あと
開発をうまく回したいなと思って僕が意識している40くらいのこと - Mitsuyuki.Shiiba
自分がこの1年間開発チームを引っ張ってきた中でこういうところに気をつけてたよってこと。 ザーッと勢いで書いてみる。分類はある程度なもんです。組織パターンやFearlessChangeは好きです。 心構え 1 現状を受け入れる 環境に文句を言ってても、何も変わんないし。自分は本当はもっとできるはずなんだ、って言ってても、実際アウトプットはでてないんやろ。なるほど、今はこうなんだってことを受け止めて、じゃあそこからどう改善していけるだろう？と考えたい。 2 遷移状態を受け入れる 現状から、理想的な状態にぴょんって飛び移れるわけじゃないんだから、その途中って泥臭かったりごちゃごちゃしてたりするんだけど、それを受け入れる。練習せずにいきなりスポーツがうまくなるわけないのと同じで。 3 正しいことが選ばれるわけじゃない 政治や感情や時期や思惑や抵抗や。そういうのがあるので「正しいこと」が常に選ばれる
テスト考2014 - Hidden in Plain Sight
年々、ウェブアプリを開発するときにテストを書こうという機運が強くなっていると感じる。 これは、開発パラダイムの成熟を意味することであり、基本的に良いことだと思っている。 しかし同時に「テスト原理主義」とでもいうような極端な考え方もでてきていて、開発スタイルをめぐって摩擦が起こっている。 そして、この議論は「テストは、ないよりあったほうが良いよね」という、微視的には誰も反論できないロジックに押し通されがちで、「地獄への道は善意で舗装されている」の典型的な現象に見えて仕方がない。 テストを書かない、というと背景にどんな深い考えがあっても素人くさく聞こえ、逆にテストを書くというだけで良いプログラマーに見える、という非対称な化粧効果がある。ソフトウェア・コンサルティング会社がテスト好きなのは決して偶然ではない。 ソフトウェアというのは、結局のところ、動いてナンボ、使われてナンボである。 期待するも
はてなやクックパッドの開発現場で、CIやテストはどう行われているのか？（前編）。CROSS 2014 － Publickey
Web技術について横断的に語り合うイベント「CROSS 2014」が1月17日、都内で行われました。 そのセッションの1つ「現場に聞く！テスト/CI/DevOps、実際のところどうなの」では、フリーランスエンジニアの伊藤直也氏がセッションオーナーとして司会を担当し、クックパッドで開発まわりのエンジニアをしている舘野祐一氏、はてなでアプリケーションエンジニアをしている伏井洋平氏、KAIZEN platform Inc.の石橋利真氏らがスピーカーとして登壇。 先進的な現場でテストやCIがどのように行われ、エンジニアのチームがどのように情報共有をしているか、本音で語るという注目すべき内容でした。本記事ではそのダイジェストを紹介しましょう。 現場に聞く！テスト/CI/DevOps、実際のところどうなの 伊藤 今日のテーマとしてはCI（Continuous Integration、継続的インテグレー
ペーパープロトタイピング入門 – 第1回 どうして紙でプロトを作るのか | fladdict
ペーパープロトタイピング講座シリーズ。第1回は導入編。 第1回はの導入編。ペーパー・プロトタイピングとは何なのか、何故必要なのか。そして導入することで、どんな利点があるのかを説明する。 ペーパー・プロトタイピングって何？ ペーパー・プロトタイピングとは、紙で実際にアプリやサイトを「実装する」ことである。 通常の開発においてコンテンツが使いやすいかどうかは、開発が終盤になるまでわからない。このため「作ってはみたが使いにくい」や「いまさら後戻りできない」という問題が発生する。UIや手触りが重要なモバイル系のアプリにおいて、これは致命的な問題になる。ペーパープロトタイピングはこの問題を低コストで解決する。 紙とペンで動作モックを作成することで、本実装を行う前に、素早く手戻なく検証を行うことができる。これにより、仕様書策定や実装前にPDCAのサイクルを実現できる。作業負荷の高い本実装を行う前に軽く
「#ぶつかり稽古」という事件について - Kentaro Kuribayashi's blog
去る11月23日、あるイベントが開催された。「秋のエンジニアぶつかり稽古 2013」という。何を目的にしたイベントなのか誰も(主催者側ですらも)わからないまま始まったこのイベントは、しかし、最後までその目的が明らかにならないままに、なぜか大成功の余韻だけはしっかり残して終わった、異常な「事件」と呼ぶ他ないものとなった。 事の発端 そもそもの始まりからして意味不明だったのである。発端はこれだ。 @__kan こんにちは、ペパボです。YAPC::ASIA参加者スペシャル特典にご応募いただき、ありがとうございます ！ @kentaro とのぶつかりげいこをぜひ開催したく思います。ご都合のよろしい日をいくつかご連絡下さい！ pic.twitter.com/uoj2uExHBU— ペパボ(paperboy&co.) (@pepabo) October 2, 2013 2ヶ月ほど前、YAPC::Asi
ウェブエンジニアの生存戦略 - mizchi's blog
最近、この話題について経営者目線の話が多かったので、エンジニアのスキル獲得戦略とその最大化という観点から話をする。 まず目下のウェブエンジニアとして一番の課題は、「35歳定年説をどう乗り切るか」、ということだろう。もちろん、みんな35歳定年説なんてのが、まやかしであるとはわかっている。若い業界だったウェブ業界も成立してからだいぶ経ち、結果として平均年齢が押し上げられ、自然と35歳以上のエンジニアも増えてきた。 問題は、人月という概念によって、できる人間とそうでない人間の区別がされていないことだ。ウェブエンジニアとしての悲哀や業界の歪みはここにあると思う。下手に謙遜したりして話をややこしくする前に言ってしまうと、自分をできる側の人間として話をする。 生産性を測る確固としたメトリクスがないのも事実だと思うが、すくなくとも熟達した人間と未経験者がおなじ1人月というのは、到底ありえない話だと思う。
開発支援系のサービスが充実しすぎて転職か廃業を考えた | Ore no homepage
なんて表現したらいいかわかんなくて、開発支援系サービスって謎表現したけど…。なんつーか、開発支援向けのサービス？クラウドってやつ？ってかいわゆる外部がやってくれる系のサービス(モニタリング/ホスティング/etc)が充実してますよね。んで、一介のWebエンジニアのおれがこの先生きのこるにはどうするかを真剣に考えていたところだった。きのこ。何割かはネタ。 思いついたものを挙げてみる。AWSやGitHubは割愛。言うまでもねーだろ…。 New Relic http://newrelic.com/ 有名なNew Relic。これも説明するまでもないかな。今のチームでコレのお金払う版を使ってるんだけど、「外部APIとの通信個所とDBとの通信個所が遅いように思えるので調査しますわ」→「それNew Relicで見れるよ」とか「各テーブルへのアクセス頻度集計しますわ」→「それNew Relicで見れるよ」
社内AWSエンジニア向けMac用ツールまとめ資料を公開してみる | DevelopersIO
はじめに こんにちは植木和樹です。今年の5月にクラスメソッドにJoinしてから早半年。当時6名体制だったAWSチームも15名近いメンバーとなりつつあります。 クラスメソッドでは入社した社員にMacBook Airが貸与されます。薄くて軽くて持ち運びに便利なので、いつでもどこでも仕事ができます（歓喜）。さて入社して数日間は仕事をするための環境作りに時間がとられるものですが、なるべく早くフルスロットルな仕事体制を整えてもらえるようクラスメソッド社内で使っているツール類をまとめてみました。 セットアップ手順まで記載するとエントリが長くなるのでツールの紹介のみです。参考となるセットアップ手順については紹介内でリンクを貼っています。 業務系ツール Chrome 配布元サイト Chrome ブラウザ 作業ミスを防ぐため、お客様のAWSアカウントごとにChromeユーザーを切り替えて使いましょう。設定方
国内注目のWebサービスを支える言語・フレームワーク・アーキテクチャ一覧【2013年版】 | Find Job! Startup
FINDJOB! 終了のお知らせ 2023年9月29日にFINDJOB!を終了いたしました。 これまでFINDJOB!をご利用いただいた企業様、求職者様、様々なご関係者様。 大変長らくFINDJOB!をご愛顧いただき、誠にありがとうございました。 IT/Web系の仕事や求人がまだ広く普及していない頃にFind Job!をリリースしてから 約26年間、多くの方々に支えていただき、運営を続けてまいりました。 転職成功のお声、採用成功のお声など、嬉しい言葉もたくさんいただきました。 またFINDJOB!経由で入社された方が人事担当になり、 FINDJOB!を通じて、新たな人材に出会うことができたなど、 たくさんのご縁をつくることができたのではないかと思っております。 2023年9月29日をもって、FINDJOB!はその歴史の幕を下ろすこととなりましたが、 今後も、IT/Web業界やクリエイティブ
Webサービス開発現場から / 近頃の開発のやり方 ･･･ Github と Pull Request とコードレビュー - naoyaのはてなダイアリー
先日プレスリリースが出たのですが、KAIZEN platform という会社で技術顧問などをやっています。それから、一昨日自分も出たWebアプリケーション開発に関する勉強会 (資料) を開いたじげんという会社でも少し前から同じように顧問のような形で携わっています。 自分が関わっている会社のPRも含めて、すこし、2013年現在のWebサービス開発の現場感、やり方みたいなものを書いてみたいと思う。ただ、自分の利益があるところの話だけではフェアではないので、Webエンジニアならよく知っているであろう Qiita を運営しているインクリメンツの様子も合わせて紹介する。 KAIZEN platform KAIZEN platform が提供しているサービスは planBCD という A/B テストの SaaS で、Webサイトのコンバージョンだとかを画面の構成要素を変えて効果測定したいとか、そういう
ユニットテストにまつわる10の勘違い | DevelopersIO
渡辺です。さる方面からテスト系のエントリーがまだか…と催促されたので、ユニットテストについて少し考えてみたいと思います。 最近、TwitterのTLをチェックしていると、JUnitを利用しているにも関わらず違和感のあるTweetや、原因をJUnitにして本来解決すべき問題から目をそらしているようなTweetを多く見かけます。そこで、JUnitをによるユニットテストに関するありがちな勘違いをまとめてみました。 なお、JUnitの部分は、RSpecでもNUnitでも適当に置き換えて読んでも構いません。 1.JUnitを使うことが目的という勘違い JUnitを利用すること自体を目的にしたところで何も得る事はありません。 ありがちな話ですが、「納品物としてJUnitのテストコード（または実行結果）を求められている」ことが理由でJUnitを利用しているならば、それは足かせでしかない可能性があります。
伊藤直也氏が語る、モバイルアプリケーション開発のいまとこれから（後編）～Salesforce Developer Conference Tokyo 2013
伊藤直也氏が語る、モバイルアプリケーション開発のいまとこれから（後編）～Salesforce Developer Conference Tokyo 2013 9月6日開催されたSalesforce Developer Conference Tokyo 2013のセッション「B2Cからみたモバイルアプリケーション開発のいまとこれから」では、コンシューマ向けサービス開発の現場に身を置いてきた伊藤直也氏が、モバイルアプリケーション開発を成功させるための方法をこれまでの経験や現在の開発現場のノウハウを基に語っています。 試行錯誤の回数を増やす、iOSとAndroidは同じように作ってはいけないなど、モバイルアプリケーション開発に関わるエンジニアやデザイナーにとって非常に参考になる内容が込められたセッションの内容を、ダイジェストで紹介しましょう。 （本記事は「伊藤直也氏が語る、モバイルアプリケーショ
伊藤直也氏が語る、モバイルアプリケーション開発のいまとこれから（前編）～Salesforce Developer Conference Tokyo 2013
伊藤直也氏が語る、モバイルアプリケーション開発のいまとこれから（前編）～Salesforce Developer Conference Tokyo 2013 いま多くの開発者が取り組もうとしているモバイルアプリケーションの開発は、経験の面でも技術の面でも、コンシューマ向けの開発現場が大きく先行しています。 9月6日開催されたSalesforce Developer Conference Tokyo 2013のセッション「B2Cからみたモバイルアプリケーション開発のいまとこれから」では、コンシューマ向けサービス開発の現場に身を置いてきた伊藤直也氏が、モバイルアプリケーション開発を成功させるための方法を、これまでの経験や現在の開発現場で得たノウハウなどを基に語っています。 試行錯誤の回数を増やす、iOSとAndroidは同じように作ってはいけないなど、モバイルアプリケーション開発に関わるエンジ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
YAPCで「はてなブログの開発フロー」について話してきました - 大西ブログ
ヌーラボのサービス開発の裏側公開しちゃいます
