はじめに はじめまして、Martingale（Twitterアカウント）と申します。 10年間、半導体分野の生産技術者をしたのち、データアナリストに転職し、今はデータ分析を使って化学プラントの故障原因の解明や予知保全をやっています。 近年、注目されているディープラーニングをはじめとする機械学習ですが、私の感覚では、製造現場への導入があまり進んでいないように思います。 その背景には従来から品質管理に活用されている統計的品質管理の影響があるのではと感じています。 統計的品質管理が上手く機能しているが故に、製造現場で機械学習の必要性があまり感じられていないのではないか？ということです。 つまり、以下のような会話が繰り広げられているのではないかと。。 製造現場でのやり取り （注）絵の中で、若手エンジニアとベテランエンジニアと書いたのは、あくまでイメージです。若手の方が、学生時代にPythonを触っ
2. 自己紹介 福島 真太朗 (Shintaro Fukushima) ● コネクティッド先行開発部InfoTech データ解析基盤G グループ長/プリンシパル・リサーチャー ● s_fukushima@mail.toyota.co.jp ● shi-fukushima@toyota-tokyo.tech ● TwitterID: shifukushima 2 ● 産業技術総合研究所人工知能研究センター 客員研究員 ○ NEDO・産総研 AI品質マネジメント検討委員会 委員 ● 国立情報学研究所 ○ JST未来社会創造事業 高信頼な機械学習応用システムによる価値創造 委員 4. トヨタ＠大手町 クルマのライフサイクルに関わるデータ解析を推進 4 ● 車両データ解析 (CAN・位置情報・画像等) ● 機械学習の品質管理・保証 ● マテリアルズ・インフォマティクス ● 生産工場における兆候検知
2019/10/31(金)に開催されたEngineering Organization Festival 2019 で @t_wada さんの「質とスピード」という講演を聞き、とても感銘を受けたのでメモ。 品質とスピードはトレード・オフの関係にある。どちらを優先するか？要バランスだ。 そう思っていた時期が私にもありました。 けど、そんなことはなかった！ ■追記 個人的な捉え方としては、 プロダクトを漸進的に成長させ、仮説検証ループするスピード上げようとすると、犠牲にした保守性があとで(意外とはやく1ヶ月後には)足枷になる。 保守性(テスト容易性、理解容易性、変更容易性)が低いとリードタイムが延びてスピードがどんどん落ちていくループをまわせなくなる。ってことかな、と思う。 スピードを上げようとしたのに、意外とはやくスピードが上がらなくなるジレンマ。 @t_wadaさんのスライド 素敵なグラレ
安全ソフトウェアの教科書的な存在であるセーフウェアを読み始めた。656ページもある分厚い本なので、まずは30分くらいで斜め読みした。 自分は約20年近くクリティカルデバイスの開発に携わってきたので、書いてあることがよく分かったが純粋なソフトウェアエンジニアにはピンとこないかもしれないとも感じた。 具体的な事故の事例も多く掲載されているので、取っつきやすいと思うがやっぱり解説が必要にも思える。 そこで、できるところからこの本に書いてあることの意味について解説してみようと思う。 どこがいいかざっと見ていたら、エピローグ「これからの展望」にいいことが書いてあったので、ここからいこう。 【『セーフウェア』エピローグ これからの展望 より引用】 □安全をより確かなものにする最も効果的な方法は、単純であることと、知的に処理できるシステムを構築することである。 □安全性と信頼性は別なものであって、混同し
by Chaitanya Ekanadham One of the common questions we get asked is: “Why do we need machine learning to improve streaming quality?” This is a really important question, especially given the recent hype around machine learning and AI which can lead to instances where we have a “solution in search of a problem.” In this blog post, we describe some of the technical challenges we face for video stream
データ分析をしている人にとっては，データのクオリティを日々モニタリングするのは頭痛の種です．最近のシリコンバレーでは，Data Engineer とは別に Data Quality Engineer というポジションで募集をしている企業もたまに見かけます．それぐらいデータの「質」には，気を配る必要がありリソースが掛かる分野といえるでしょう．とは言え，専任のポジションを設けるのはなかなか難しいので，それでもできるだけ簡単にモニターリングしたいです． Airflow と Slack を組み合わせることで，データのクリティを日々モニタリングすることができます．データエンジニアリングにユニットテスト的な概念を持ち込めないかと模索してきましたが，Airflow + Slack は個人的には一つの理想形と言えます． Apache Airflow とは？ Apache Airflow は，プログラムでジ
老朽化に伴い、今後需要が増大する見通しのインフラ点検作業。産総研は人工知能（AI）技術の1つである機会学習を活用し、インフラの打音検査を効率化できるシステムを開発した。人の経験や勘に頼らず、AIが打音の異常を判断する。検査作業の工数を削減できる他、非熟練者でも見落としなく点検作業が行えるという。 産業技術総合研究所（産総研）は、首都高技術、東日本高速道路、テクニーと共同で、インフラ構造物の打音検査を人工知能（AI）でアシストし、異常度マップを自動生成する「AI打検システム」を開発した。従来の打音検査の手順を変えずに図面化を含めた検査作業の工数を削減できる他、非熟練者でも見落としなく点検作業が行えるという。 産総研では、点検員の感覚に頼らずに打音の異常度を定量化し、精度のばらつきやミスを防止する技術の研究開発に取り組んできた。そのコア技術の1つであり、今回開発したAI打検システムに利用したの
You started off by saying that in most organizations there's a dedicated team of engineers (usually tech leads or seniors) who use their free time or a committee to oversee initiatives and guidelines to propagate best practices. From the way the article is written it sounds like you're saying you do something else, but you're example of having 20%ers doing this seems the same as "free time" to me.
はじめに はじめまして、AirレジのiOSアプリ開発を担当している保田です。 現在Airレジチームでは、ログからアプリパフォーマンスの低下を検知する仕組み作りに取り組んでいます。 今回はその取り組みについて、どのように実現しているかをご紹介させていただきます。 背景 昨年5月に、Airレジのリニューアルを行いました。 しかし、この時に「レシートの印刷が遅くなった」「レシートの印刷ができない」という声を多数いただいてしまいました。 ユーザーの業務の中でも特に重要な「会計・決済」という部分を預かる以上、 このような品質の低下をいち早く検知して、解消していかなくてはいけないということで今回の取り組みを開始しました。 社内テストでも性能面の評価を実施していたものの、実際の業務の特定パターンにおいて起きる事象もあったため、本番環境の品質の低下を検知する仕組みが求められました。 ログの収集 「アプリパ
Webサービスの開発は、ユーザ/顧客へ価値を早く届けるため、競合より早くリリースするため、人的リソースを無駄使いしないためなど、とにかく素早く進めたいものですね。一方で、開発を急ぐあまり品質を犠牲にすればかえって価値が失われたり、技術的負債が溜まって長期的なコストが大幅に増大する可能性もあります。開発速度とプロダクト品質は基本的にはトレードオフの関係にあるのでしょう。 開発速度と品質のどちらを優先するかはプロダクトの性質や、チームもしくは会社の状況によって異なるとおもいます。この状況の認識がチームメンバー間でずれていると、チームのパフォーマンスを最大限に発揮できないばかりか、チーム内の関係悪化も招きかねません。エンジニアたちとプロダクトオーナーの間の対立のようなありがちな問題の原因の一つかもしれません。 そこで、開発速度と品質のトレードオフをどう判断すべきかの基準を明確にして、原則それに従
2016年11月3日（祝）、大田区産業プラザPiOにて開催された国内最大のPHPイベント「PHPカンファレンス2016」。レバテックフリーランスでは、カンファレンスセッションの登壇者のひとり・和田卓人氏にインタビューを実施しました。 テスト駆動開発の先駆者として知られる和田氏ですが、今回の講演テーマは「PHP7で堅牢なコードを書く-例外処理、表明プログラミング、契約による設計」。あえてテスト以外のテーマを設定した理由をはじめ、PHPの優位性や今注目している言語、初心者エンジニアへのアドバイスなど、幅広くお話を伺ってきました。 ＜この記事の要約＞ 1. PHPの良い点は、ゆるふわな言語に見せかけて堅牢なコードも書けるところ。悪い点は、覚えることが多くて難しいところ。 2. テストを書いていればコードの品質が高いわけではない。また、テストが書けないくらい問題を抱えたコードでも、中から改善してい
ソースコードを漸進的に改善するための組織的活動のパターン・ランゲージを作りました。リファクタリングはソースコードの改善テクニックですが、ソースコードの品質改善活動を成功させるためにはリファクタリングだけでは足りません。品質改善を利害関係者も含めたチームの活動として捉えることが必要です。このソースコード品質改善パターンを参考にしてソースコードの品質改善を成功させてください。 ソースコード品質改善パターンとは 筆者は、製造業の組込みソフトウェア開発チームに対してプロセス改善や技術支援のコンサルティングを行っています。そのコンサルティングの中で、ソースコードの品質を漸進的に改善することに成功したチームに共通するコツのようなものをパターン・ランゲージとしてまとめたものが、このソースコード品質改善パターンです。 まだ、数チームの事例分析に基づくものなのでパターン・ランゲージとして練りきれていないとこ
製品検査で検査する人に心理的な負担や圧力があると絶対にダメだ。「NGにするのめんどくさい、つらい」と検査員が思っている状態では、「なんか変だな？」と感じてもスルーされてしまう。むしろNGにするとほめてもらえるくらいの環境を構築しないといけない。 この前、担当製品の受け入れ検査でNGが出た。検査員は私だった。 最初は（なんだ？ 妙に数値がいいな？）という違和感があっただけだった。いつもと比べてちょっと違う、しかし測定値は仕様をクリアしている。むしろいつもよりいい方向に振れている。 この「ちょっとした違和感」が何かを確かめるには、検証作業を自分の手でしないといけない。検証の手段を、製品の技術面により詳しい人に聞いたり図面を読んだりして情報を集めないといけない。また営業や生産管理部門の担当者には納期の遅れ、今日中にはもう検収を上げられないことを伝えないといけない（3月の期末、年中で最も営業が納期
こんにちは。投稿推進部ディレクターの新里です。 私はディレクターとして、動作確認に積極的に関わるようにしています。その理由は、担当したサービスをより多くのユーザーに快適にご利用いただきたいという思いからです。 せっかくサービスを使おうと思っていただいたユーザーがいるのに、不具合をきっかけに不便だなと思ったり、使わなくなったりするのは、私だけでなく開発しているメンバー全員にとっても、すごく残念なことだと思います。 そんな状況を少しでも減らすために、私が普段の業務の中で動作確認を行う時に心がけていることをご紹介したいと思います。 心がけていること6つ なるべく実機で確認する 条件を組み合わせる タイミングを狙う あえて余計なことをやる エンジニアに聞く きちんと管理する 1.なるべく実機で確認する シミュレーターで動作確認することも可能ですが、実際にユーザーが使うのに近い状態で画面を見て、違和
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
