Developers Summit 2016【19-D-3】の登壇資料です。 http://event.shoeisha.jp/devsumi/20160218/session/1047/
![外注が主な企業でどのように内製開発を立ち上げ・進化させているのか?](https://cdn-ak-scissors.b.st-hatena.com/image/square/ca372b5f1a8c93272366a87f4a46a49d7cc011e8/height=288;version=1;width=512/https%3A%2F%2Fcdn.slidesharecdn.com%2Fss_thumbnails%2F20160219developerssummithowtostartandevolveinhousedev-160219082037-thumbnail-4.jpg%3Fcb%3D1455870370)
リブセンスさんの「人は一ヶ月でエンジニアになれるのか - 詳細解説」を読んでみてこれはかなりすごいなと感動しました。 あとはほかのWeb系の企業さんの研修に関する資料を読みつつ、どうすれば効率的にWeb開発の知識を習得できるのかなといろいろ考えてみたのでそのメモです! 🚌 リブセンスさんの教育に対する考え方 人は一ヶ月でエンジニアになれるのか - 詳細解説 学生時代に知っておきたかったWeb技術の学び方の学び方 Web開発における問題点 Web開発は領域それぞれが深い。ゴールがない 新しい技術が日々生まれたり、深い知識が要求されるため、学び続ける必要がある - (問題点) 知っておかないといけない知識が多い - git/javascript/css/ruby/CI/ミドルウェア の画像 - 要求される知識も深く、定期的なバージョアップが要求される - (問題点) メインストリームの技術の
編集部でのこぼれ話を中心に、この先のスタートアップ関連の動きをおさらい! 記事にする必要のない余計な情報、ウラ話を中心にゆる~くお届けします。 北島:座談会も10回目ですが、今週もトピックいろいろなようで。 盛田:今週はなんといっても実物の「Gatebox」を見たのがやばかった。二次元嫁を声で召喚できる魔法の装置です。実際に召喚してもらったけど、やばい。プロジェクターの使い方だけであそこまでリアルにできるものかってびっくり。理想的なひきこもり量産機ですよあれは。 Gatebox | Hologram Communication Robot ■関連記事 美少女が「おかえり」オタクの夢を叶える「Gatebox」 北島:まだ展示とかもされてないですよね。普通にうらやましい。 盛田:本当にステルスで開発してたらしくて、DMM.makeのほぼ誰も知らないっていう。ウィンクルって「なんか光る鳥(AYA
こんにちは!クックパッド編集室メディア開発グループ長の @yoshiori です。 このまえ夏の技術職インターンシップの前半の開発講義・課題部分が終わったのでさっそく公開しちゃいます! ちなみにこのインターンの対象者はプログラミングはわかるし自分で(授業とかではなく)コード書いている人なので超初心者向けでは無く、少なくともひとつ以上の言語でプログラミングが出来る人向けです。 一日目 TDD + git 編(@yoshiori) 講義初日なのでまずは簡単に肩慣らし & 開発の基礎の部分として TDD と git で始めました。 git については軽く説明し TDD は基本のテストファーストで進めて行きました。 ちゃんと何かをするたびにテストを実行し、メッセージを見れば次にすることが分かるというのを体験してもらい、GREEN が良くて RED が悪いのではなく、GREEN を想定しているのに
弊社の開発における考え方として「方向>開発フロー>スキル」という順番があります。 方向がずれているとすぐに数ヶ月吹っ飛ぶので向かう先をどこにするかは最も大事。 次に開発フローで、変なコミュニケーションロスがあるといかにスキルの高いエンジニアがそろっていてもスピードがあがりません。 そして最後にスキル。 そんな話を藤村くんたちに熱弁していたら、 「ゆうじ、それはプロダクティビティエンジニアって言って、職種として今後大事になってくる考え方だよ」 と教えてもらいました。 このプロダクティビティエンジニアについては、 まだ日本語での良いドキュメントが見つからず自分の言葉で説明するしかないのですが、 要はスループットを上げる事にフォーカスするエンジニアの事です。 上記に書いたようなコミュニケーションロスなどを無くしたり、 最適なツールを決定したり、issueの切り方を整理したり、 テストフロー、デプ
こんにちは、TJOさんに暗躍していると言われたエンジニアのあべです。アドテク部勉強会の中で「イノベーションと開発プロセス」というテーマで発表しました。 ここのところChatOpsや継続的デリバリー等の様々な開発プロセス改善に関する話題をよく耳にするので、サービス開発という文脈の中でそれら各トピックが何を求められてでてきたのかを概観し、各種課題についてどのようにアプローチしていけるのかをザザッと触れていく内容になっています。 特に中心的に取り上げたかったのが、サービス開発は仮説検証の繰り返しであること、これらを高速に回していくことでイノベーションを目指していくこと。さらに、そんな背景のもとでエンジニアが高速仮説検証サイクルの実現に強くコミットし、より加速させていくこと。そしてそのためには開発プロセスの改善が必要だよね?みたいな話題です。 # だいぶ風呂敷広げすぎてますが。。。自分が楽しくコー
・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
システム品質を左右する「組織体制」「開発スキーム」「マインド」を改善してきたリクルートの苦労を振り返る(組織編)~ソフトウェア品質シンポジウム 2013 システムの品質を左右する要因は何か。リクルートテクノロジーズ 執行役員CTO 米谷修氏は「組織体制」「開発スキーム」、そして発注者を含む関係者の「マインド」の3つが大きな要因であると説明します。 9月12日と13日の2日間、都内で開催された日本におけるソフトウェア品質に関する最大級のイベント「ソフトウェア品質シンポジウム 2013」(日本科学技術連盟主催)の特別講演として行われたのが、米谷氏の講演「進化するIT組織と開発スキーム ~リクルートのサービス開発の事例紹介とともに~」でした。 大規模なシステムを迅速、かつ高品質に、という要求が続く現場で、米谷氏が続けてきた試行錯誤の中で得た知見とは何か。講演の内容をダイジェストで紹介しましょう。
Write Your App If you can write it for the web using HTML/HTML5, CSS3 and Javascript*, you can use the Intel® XDK to build it as an HTML5 web app or as a native app for all of the major App Stores. Emulate & Test The Intel XDK makes it easy for developers to check look and feel of their apps with on-screen emulation on a wide variety of devices. The App Tester allows you to test on a physical devi
By clicking “Accept All Cookies”, you agree to the storing of cookies on your device to enhance site navigation, analyze site usage, and assist in our marketing efforts. View our Privacy Policy for more information. When you visit websites, they may store or retrieve data in your browser. This storage is often necessary for the basic functionality of the website. The storage may be used for market
定期的にSI業界が終わったという話が出ますが、本当にそうでしょうか。終わるべきは一括発注・請負のディフェンシブなビジネスモデルです。受託はなくなることはありません。ソフトウェアの開発を、他の業界のアナロジーで考えるのではなく、正面から取り組んだビジネスモデルについて語っています。 ディフェンシブな開発 今から5年前に、SI業界における多くの問題の原因がそのビジネスモデルにあるという「ディフェンシブな開発〜SIビジネスの致命的欠陥」という記事を書きました。SIにおけるビジネスモデルは、発注者とベンダーはあらかじめ決めた金額と要件の中で納品と検収を目指すため、利益を出すためには双方がリスクを取らずに「守り」に入る必要があります。その結果、顧客にとって価値を産むかどうかよりも決められた要件通りに作られることを重視することになってしまいます。人月という単位であらかじめ決めるとなれば、単価の安い下請
本来のミッションから少し離れて、本業の参考にと思って知己を得ていた先方の会社さんを訪問したり情報交換したりして過ごしていたんですが、いろいろ凄いです。「事情を日本のブログで紹介するよ」と言ったら、どこか明かさないという条件で許してくれました。 ● ソフトウェアの開発効率はあまり考えない シャチョーも担当者も現場の人も、効率は大事だけど開発に取り組む要員の創意工夫ややりがいを重視しているとのこと。現場レベルでは18ヶ月のプロジェクトが50ヶ月遅延した笑い話をしてくれたり、某ドイツの基幹系をロシア企業に提供する際にドイツ人の定義定義のやり方に嫌気が差し、そんなことだから戦争に負けるんだと掴み合いになった話を披露してくれました。 ● でっかいものを作りたがる どっちかっていうと日本では小さくて正確なコーディングを求めて、バージョンがアップするごとにコンパクトかつバグが少なくという方向で作業指示が
Android案件の見積り | クラスメソッド開発ブログ を読んで、業界人らしき人のブコメが、「この程度でホッテントリか」という感じで、僕もややそっちよりの意見だったので、ざっくり補足できそうな点について書いて見ました。もう転職して受託の立場ではなくなったので。やや発注側の視点も含まれています。 責任のないリスクについてコスト負担範囲を決める すべてにおいて最重要項目です。変化の激しいスマホ業界においては、互いのリスクテイクについての認識をあわせておく必要があります。例としてはこんなものがあります。 開発期間中に突如OSのメジャーバージョンアップがあった。 顧客「あ、新しいのでましたね。対応できますよね^^」 世論に応じて機能の根幹部分が突然リジェクト対象になる。 りんご「今日から電話番号認証禁止ね^^直さないと削除しちゃうよ^^」 過去を顧みない方針転換がなされる ぐぐる「メニューボタン
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く