質とスピード（2020秋100分拡大版） 2020/11/20 @ JaSST'20 Kyushu
質とスピード（2020秋100分拡大版） / Quality and Speed 2020 Autumn Edition
質とスピード（2020秋100分拡大版） 2020/11/20 @ JaSST'20 Kyushu
「研究開発型スタートアップと事業会社のオープンイノベーション促進のためのモデル契約書ver1.0」を取りまとめました （METI/経済産業省）
経済産業省と特許庁は、研究開発型スタートアップと事業会社の連携を促進するため、共同研究契約やライセンス契約などを交渉する際に留意すべきポイントについて解説した『モデル契約書ver1.0』を取りまとめました。 1．経緯 オープンイノベーションが進みにくい理由のひとつとして、企業と共同研究を行うスタートアップ側の法的な知見の不足が指摘されています。そこで、研究開発型スタートアップと企業の法的な知見のギャップを埋め、オープンイノベーションを促進するためのツールとして『モデル契約書ver1.0』を策定しました※。 2．モデル契約書ver1.0の内容とポイント 本モデル契約書は、公正取引委員会による「スタートアップの取引慣行に関する実態調査」の中間報告で明らかになった問題事例に対する具体的な対応策を示しており、契約交渉で論点となるポイントについても明確にしています。 本モデル契約書が、企業とスタート
エンジニアリングスキルで捉えるチームマネジメント - mtx2s’s blog
チームのマネージャーが、自らの責務をジョブディスクリプションとして明文化することは難しい。職務内容や権限を、断片的にしか書けないかもしれない。もしそうなるなら、実務も断片的になっている可能性がある。 チームマネジメント（組織マネジメント）という活動は、個々のマネージャーの経験や関心によって、断片的になりやすいように感じている。断片的とは、マネジメント活動が、責務の一部の領域に偏ってしまっていたり、問題を検知してはじめてその領域がマネジメント範囲であることを知る、といった様子を指している。 このような状態になる背景は、マネージャーにとって、マネジメントが、日々の実務を通して蓄積された経験に基づく活動になっているからではないか。マネージャーは孤独だ。ひとりでその責務を担う。エンジニアとは違い、チームで協働するわけではない。だから、形式知として言語化されず、個人の経験として暗黙知にとどまる。その
「厳密な仕様記述における形式手法成功事例調査報告書」の公開 ：IPA 独立行政法人 情報処理推進機構
ソフトウェア開発現場では、日本語で作成する仕様書の記述内容が曖昧である事に起因する製品品質の低下やプログラム不具合対応などの手戻り作業に伴う開発コストの増加が問題視されています。「形式手法」(*1)は、こうした仕様記述の内容から曖昧さを排除し、誤解を招かない仕様書を作成する手法の一つとして注目されています。 国際規格においても、高い安全性を要求される製品に関連する規格であるIEC 61508(*2)や、自動車業界に対するISO 26262(*3)など、形式手法の使用を推奨しており、形式手法に対する国内企業の関心も高まってきています。 IPA/SECにおいても、「形式手法」が上流工程の品質向上に有効な手法のひとつとして、普及促進を行ってきました。 本調査では、仕様記述における形式手法導入の成功プロジェクトのキーパーソンに対し、「仕様書作成に係る諸問題の根本原因が何か」、「それを形式手法の活用
丸投げしたんだから、頑張ってくださいよ（作業量は増えたけどね）
丸投げしたんだから、頑張ってくださいよ（作業量は増えたけどね）：「訴えてやる！」の前に読む IT訴訟 徹底解説（67）（1/3 ページ） 下請けに丸投げした作業の工数が当初見積もりの6.4倍にまで増えてしまった。下請けの追加費用支払い要請に応じるか、契約を結び直すか――どうする、元請け！ 連載目次 IT訴訟事例を例にとり、トラブルの予防策と対処法を解説する本連載。今回取り上げるのは、「元請けベンダーと下請けベンダーの間に起きた機能追加費用を巡る争い」だ。 昨今、問題視されることの多いソフトウェア開発における多重請負構造。ユーザー企業から発注を受けた元請けベンダー（以降、本文中は「元請け」と表記）が作業の一部（あるいはほとんど！）を下請けベンダー（以降、本文中は「下請け」と表記）に再委託することは、むしろ一般的といってもいいほど数多く存在する。 両者の間で作業の分担や支払い、不具合の責任など
エンジニアリングマネージャーになった次の日にすること - How To Create Organizational Strategy
マネージャーになると長期的な目線で、組織を理想的な状態へ進めていくことが求められます。 未だ直面していない、曖昧な状況に対してプロアクティブに対応していくことは非常に難しいです。 本発表では、曖昧性を極力回避し、開発組織戦略の大枠をつくることにフォーカスします。
受託開発の会社が自社サービスを立ち上げて軌道に乗せるまでの取り組み
Linuxカーネルを読んで改めて知るプロセスとスレッドの違いRetrieva inc.5.1K views•35 slides
E2EテストをSelenium Webdriver からCypress.io に移行した話 - 一休.com Developers Blog
こんにちは。 一休.comの開発基盤を担当しています、akasakasです。 今回は、E2EテストをSelenium WebdriverからCypress.ioに移行した話をしたいと思います。 一休のE2Eテスト事情 あれから、数年が経過して、、、 どうしてこうなった？？？ SeleniumではSPAへの対応が難しくなってきた なんでもかんでもSeleniumで頑張ろうとした弊害 いざリプレイスへ・リプレイスをする上で気をつけたこと 開発者フレンドリー 安定性 然るべきレイヤーでテストする（何でもかんでもブラウザテストにしない） 技術選定 Cypress.io とは？ Cypress.io のいいところ セットアップが楽 テストを書くことだけに集中できる CI連携が楽 Cypress.io の頑張って欲しいところ その他、移行に関しての細かい話 重複テストケースの排除 Page Objec
Rubyコミッター・Yuguiに学ぶ、コードに書くべき「適切なコメント」と「適切な場所」 - エンジニアHub｜Webエンジニアのキャリアを考える！
Rubyコミッター・Yuguiに学ぶ、コードに書くべき「適切なコメント」と「適切な場所」 Rubyコミッター・園田裕貴（Yugui）さんが、長年の経験で体得したソースコードに書くべき「コメントの技法」を教えてくれました。 プログラミングにおいて、どんな初心者でも書けるけれど、適切に書くのは上級者でないと難しいもの。それがコメント（=ソースコードに書かれている注釈やメモ）です。 不適切なコメントをつけても、プログラムの動作には影響しません。しかし、書き方の巧拙によって、コードの可読性や理解のしやすさには雲泥の差が出ます。良質なコメントが良質なコードをつくるのです。 今回はRubyコミッターでありgrpc-gatewayの開発者でもあるSupership株式会社の園田裕貴（Yugui）さんに、優れたエンジニアがどんな観点を持ち、どんなコメントを書いているのかを聞きました。 園田 裕貴（そのだ・
身に着けた技術をいかに捨てられるか。エンジニア歴39年、今でもエンジニアで居続ける理由。
サイバーエージェントのゲーム・エンターテイメント事業に携わる10社以上の子会社が所属する事業部SGE（Smartphone Games & Entertainment）では、さまざまなメンバーが活躍しています。 初めてプログラミングに触れたのは39年前。新しい技術がどんどん出てくる環境は、新しいことが好きな自分には合っていると語る平松。現在は、特定のプロジェクトには所属せず、事業部横断でネイティブアプリの品質チェックやパフォーマンス改善を担当。事業部にいなくてはならない存在となっている。そんな平松の今までのキャリアとこれからどんなことをしていきたいのかをききました。 初めてプログラムに触れたのは1979年 エンジニアをはじめたきっかけを教えてください。 高校の進路をどうしようかと考えている時に、ちょうど地元の高校で、日本で2番目に情報処理科が開設されました。元々、新しいものが好きだったので
海外志向と遠回り ─ 20年近くかけて少しずつやりたいことに近づいたソフトウェアエンジニアの生存戦略 - GeekOutコラム
こんにちは、ひげぽん（@higepon）といいます。最近は、@miyagawaさんが配信しているRebuild.fmというポッドキャストにときどき出演させてもらっています。もしかしたら、そちらで私のことをご存じの方もいらっしゃるかもしれません。 ソフトウェアエンジニア歴は長く、もうすぐ20年になります。新卒で電機メーカーのシステム子会社に就職。その後、株式会社はてな、サイボウズ・ラボ株式会社などを経て、アメリカのTwitter本社で働くために渡米。最近また日本に戻って、某外資系企業でエンジニアをしています。 長いキャリアの中では、たくさんの失敗や遠回りをしました。世界に羽ばたくWebサービスを作ろうと奮闘しましたが、失敗しました。開発効率を上げるツールを作って使われないこともありました。行きたい会社の面接を受けて箸にも棒にもかからず、悔しい思いをしたこともありました。 本記事では、このよう
統計コンサルの議事メモ
※今回の内容はDr.STONEという漫画のネタバレを含みます 唐突ですが、Dr.STONEという漫画が好きです。 Dr.STONE 1 (ジャンプコミックスDIGITAL) 作者:稲垣理一郎,Boichi集英社Amazon 物理や化学に詳しくないので内容を理解しながら読めているわけではないのですが、石化した世界で少しずつ文明のレベルが上がっていくのを見ていると、科学って地道だけど面白いなーと思ってしまいます。 しかし読んでいて一点気になるところがありました。 白夜たちが宇宙から地球に帰還した後、3組のカップルから石神村が誕生したことです。 もちろんそれぞれのカップルが非常にたくさんの子どもを産めば可能でしょう。しかし現代人が10人も20人も子どもを産めるのかというと少し難しいような気もします。 またカップルが3組しかありませんので、子どもが少なければあっと言う間に「全員が親戚同士」みたいな
エンジニアが知っておきたい工数見積もり術！ " 無理ゲー進行 "から脱するために大切なコト - エンジニアHub｜若手Webエンジニアのキャリアを考える！
エンジニアが知っておきたい工数見積もり術！ 無理ゲー進行 から脱するために大切なコト エンジニアの仕事に欠かすことのできない、工数見積もり。実際の現場でいくどとなく見積もりを行ってきた筆者が、「健全な進行」にするための工数見積もりのテクニックを伝えます。 アプリエンジニアの池田 惇（ @jun_ikd）です。今回は、エンジニアならば避けられない「工数見積もり」について考えてみたいと思います。若手エンジニアでも自分の作業は自分で見積もるようにするべきです。なぜなら、より正確に計画を立てられるようになれば、自分の時間をコントロールして学びや家族・友人との時間を確保できるからです。また、期日内に完了をさせることは周囲の信頼獲得に繋がります。工数の見極めはエンジニアとして、とても重要なスキルなのです。 なお、本稿での「見積もり」とは開発に必要な期間を予測することとし、見積もりが失敗する原因や対策
SQUARE ENIX OPEN CONFERENCEゲーム開発プロジェクトマネジメント講座
ゲーム開発 プロジェクトマネジメント講座 ２０１１年１０月８日 株式会社スクウェア・エニックス CTO 橋本 善久 1 ©SQUARE-ENIX 2011 SQUARE ENIX OPEN CONFERENCE なぜプロジェクトは 失敗するのか？ 2 ©SQUARE-ENIX 2011 プロジェクトの失敗ポイント • 見込みより売上が少ない • 計画よりもコストがかかっている • 発売時期が遅れた • 発売に間に合わせるため内容が削られた • ユーザーの評判が悪い • 不具合が発生 • スタッフの満足度が低い、故障者が出た、辞め てしまった • など・・・ 3 ©SQUARE-ENIX 2011 プロジェクトの失敗ポイントの分類 • スコープ（コンテンツの範囲）の問題 • 品質の問題 • コストの問題 • 時間の問題 • リソース（人員・環境）の問題 • ビジネスの問題 4 ©SQUARE
Git を少しでも高速、安全に使う方法を紹介 - アジャイルSEの憂鬱
はてブを眺めてたら、なんか Git の記事がバズってたので、便乗して Git の話を書いてみた。 Oh, shit, git! http://ohshitgit.com/ 「Oh shit, git!」を簡単に和訳してみた。(追記あり) - Qiita https://qiita.com/KaminoHiroki/items/391fb421e94e82c00128 基礎知識 git-reset は危ない git reset --hard は作業ディレクトリにコミットしていない変更があった場合、全てを吹き飛ばしてしまう可能性があります。 使う前に必ず git status を実行して、作業ディレクトリの状態を確認をした方が良いです。 git-checkout は遅い checkout コマンドは作業ディレクトリの状態を変更します。このとき ファイルアクセスが発生するため遅い です。 git
Webアプリケーションフレームワーク導入時に考慮すべき22の観点 - Qiita
本記事では、 チームによる持続的に変更可能なWebアプリケーションの開発を目標に、フレームワーク導入時に考慮すべき22の観点を紹介する。 フレームワークによって特徴は異なるが、本番導入にあたって、考慮すべきポイントはあまり変わらないので、極力フレームワーク1に依存しすぎないよう配慮する。また、話をシンプルにするため、REST APIを提供するアプリケーションを題材とする。 前提 ソフトウェアのエントロピー ソフトウェアがエントロピー増大の法則を避けられないことを、体感している開発者は多いだろう2。普通にアプリケーション開発を続けると、開発スピードは鈍化し、品質は低下してバグが増え、開発者からは技術的負債への怨嗟の声が聞かれるようになる。エントロピー増大というフォースは極めて強力で、意思を持って立ち向かわなければ、容易にダークサイドに堕ちてしまう。 関心事の分離 大規模Webアプリケーション
コスパで学ぶ自動テストのはじめ方 - 若くない何かの悩み
Qiita 週間ランキング1位を獲得しました Kuniwak です。ご愛顧ありがとうございます。 qiita.com さて、本題に移りたいと思います。 つい最近ですが、勤め先の別チームに向けて自動テストの導入を支援するための資料を作成しておりました。こちらを共有したいと思います。 speakerdeck.com 資料中にある「仕様化テストを推奨しない」という決断には賛否両論あるかと思います。仕様化テストを推奨しなかった理由は、仕様化テストにかかるコストは相当に高く、本当に余裕があるときでないと選べない選択肢だったからです。今回自動テストを導入しようとしているチームは、見るからに余裕のない状況だったので仕様化テストからやれとは言えませんでした。 もし、「自分だったらこうする」等のアドバイスがあれば、ぜひ参考にしたいと思います。コメントなどに書いていただけると嬉しいです。
Excel管理の座席表をLeafletでWeb化した話 - LINE ENGINEERING
! This post is also available in the following languages. 英語, 韓国語, ベトナム語 こんにちは、LINEのIT支援室で社内システムの開発と運用をしている岩月です。この記事はLINE Advent Calendar 2017の6日目の記事です。 人員の増加に対応するために、今年の4月、LINEはJR新宿ミライナタワーに移転しました。移転に伴い、IT支援室ではいくつかの新しい社内システムを導入しましたが、今日はその1つである「座席表」についてお話させていただきます。 開発のきっかけ 移転前、座席の管理は以下のようにExcelで行われていました（名前は消しています）。 ◯◯さんの座席を調べたいと思ったら、Excelもしくは変換されたPDFをダウンロードして、ビューアーの検索機能で名前を調べる必要がありました。恐らくよくある運用というこ
一歩間違えると逆効果！仕事に必要な本当のチームワークとは？まとめ
0 0 132 0 日本経営協会が 2013 年に発表した「組織・チームにおけるメンバーのあり方と行動についての調査報告書」によると、6 割近くの企業が「チームに何らかの問題を抱えている」と回答したようです。 チームでの仕事は、あなた 1 人では解決できない分ハンドルは難しいと言えます。 さらにチームワークのあり方を間違って認識してしまうと逆効果になる場合もあります。 しかし、仕事においてチームワークは不可欠なものです。あらゆる分野でチームワークは効果的と言えます。メンバーそれぞれが持っている知識や経験が違うので、お互いに持ち寄って協力し合えばチームの生産性を底上げすることができます。 この記事では、チームワークの重要性と良いチームの条件をお伝えします。信頼できる 1 次情報に近い記事をできるだけ載せていますので、ぜひ参考にしてください。 チームの力を最大限にして高い生産性を生み出しましょ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Real World PlantUML
