思考のサルベージ(その３)
各工程で心がけたい思想を掘り起こしてみる
「問題解析」、これを取り上げてみますか。製造工程の要ですね。 私が実際に経験したケースで考えてみます。
システム試験で問題発生
「システム試験であるシナリオを流したら、タイムアウトした。」と一報が入ました。そのシナリオは自分が担当しているモジュール(「モジュールA」としときましょう)がメインで動くシナリオなので、解析依頼が来て作業開始です。
解析手法
現場ごとに、いろいろですね。デバッガをつないだり、解析装置で信号線の入出力確認したり、ログだけが頼りなんて場合もあります。慣れない環境ではてこずる場合もありますが、ともかく限られたデバッグ情報をもとに原因を究明しなければなりません。 まずは報告通りの現象になっているかを確認しましょう。ここが食い違ってると話になりません。
システムの問題解析
解析担当になった時点で、担当モジュールの不具合を探すのではなく、システム内の不具合を探すという心構えが必要ですね。「モジュールA」がメインだとしても必ずしもそこに問題があるとは限らないわけですから。特に自分のモジュールの品質に自信が持てないとそのモジュール内の犯人探しに時間を浪費し、問題の本質を見落とす上に貴重な時間を浪費してしまいます。デバッグ情報から客観的に何があったかを見極めましょう。
「モジュールB」登場
調べてみると、「モジュールA」がスタックしていました。スタックしている原因を探ると「モジュールB」から想定外のデータが入力されているようでした。本来なら、「モジュールB」の担当者に解析担当を振って、ひとまず様子見ですね。ところが、、
時間がない！
問題が解決しないと週末の無人連続運転ができないとか、リリース期限が迫ってるとか、問題解決を急がされるケースがありますね。幸い各モジュールの担当者は同じフロアで作業しています。すぐに「モジュールB」の担当に来てもらい一緒にデバッグ情報を見てもらいました。すると、「モジュールC」から読みだしたデータをそのまま使っているとのことでした。すぐに「モジュールC」の担当に来てもらうとデータの設定は「モジュールD」が行うとのこと、、 最終的に、「モジュールE」の担当まで来てもらい、テストシナリオに必要なイベント送信が無いことが判明しました。解析担当を振っただけなら二日くらいはかかったかもしれませんが、数時間で問題解決です。この時、実際に各担当に声をかけたのは私ではなく「モジュールB」の担当者でした。
何か掘り起こせた？
- 客観的にデバッグ情報から状況を正確に把握する
- 周囲を巻き込む力 「周囲巻き込む力」はスピード勝負では特に大事ですね。「システム内の不具合を探す」というスタンスだからこそです。
おしまい
現場によっては別のモジュール担当が遠隔地にいるなんてこともありますね。そんな時はどうするべきですかね。問題は山積みです。
GANを試してみました！
話のきっかけ
弊社内で研修を行っているのですが、私はテーマを『AI』と設定し（普段の業務柄……）、画像認識の基本の話をしようかな〜と思って準備を進めようとしていたところ、とある会議にてこんな話題が出たんです。
「今GANとか流行ってるもんね〜。研修でそれ面白いかも。」
……ちょっと待ってください。私、GANをやるとは一言も言ってません！！！
などと半分冗談交じりにで聞いて、半分その言葉に完全に乗せられてしまい……今考えると、絶対に生半可な気持ちでやるものではなかったと完全に後悔していますが、とりあえず手を付けてしまったわけで。。。
題材は、JSPも会場の一つとなってる 東海道らぐ のマスコットキャラ、東海りなちゃんを学習させてみました。この東海りなちゃんは、元々 カスタムキャスト というアプリで生成されたものなのですが、そんな画像をAIくんは学習できるのか、試してみよう！というのが今回のお話です。
ちなみに私自身は普段TensorFlowのソースコードを書くような仕事はしていますが、画像認識についてはほぼ初心者ですので、その点踏まえた上で読んでいただけたらと思います。
続きを読むモスキートーンのAIスピーカー（？） 後編
「AIスピーカ」の音声入力
モスキートーンのAIスピーカー（？） - Smile Engineering Blog （前編）では、「モスキートーン」を中心に書きましたが、今回は「AIスピーカ」の音声入力がモスキートーンや高周波に反応するのか？ を考えてみます。
素朴な疑問は、8kHz（サンプリング周波数16kHz）程度の帯域にしか対応していない音声認識が、モスキートーン（17kHz前後）や、さらには人間に聞こえないような高周波（20kHz以上）に反応するのでしょうか？
AIスピーカの入出力（代表的な例）
| 入出力 | デバイス | 目的 | 周波数帯域 |
|---|---|---|---|
| 入力 | マイク | ウェイクワード 音声認識 |
～8kHz（サンプリング周波数16kHz） |
| 出力 | スピーカ | 回答の音声再生（音声合成） 音楽再生が可能 |
～24kHz（サンプリング周波数48kHz） |
思考のサルベージ(その２)
各工程で心がけたい思想を掘り起こしてみる
今回は「レビュー」を取り上げてみましょう。 どうすれば、有意義なレビューを実現できるか、考えてみます。
レビューの目的ってなんだっけ
レビューアが、作成したレビュー資料(設計書とか、プログラムとか)をレビューイに説明し、両者で間違いや問題がないことを検討・評価しシステムの品質を保証するのが目的です。では、具体的にレビューイ、レビューアはレビューの場で何ができればいいのでしょう。
レビューイのやるべきこと
こと、ソフトウェアの開発では設計・実装、特に実装では実現方法は何通りもあります。機能が実現できていればOKという訳ではないですね。システムにとってそれが本当に最適な設計・実装なのか吟味しなければなりません。そのために、レビュー資料と説明から、レビューアの意図を理解する必要があります。それができなければ、賛意、反意の表明も助言もできません。
レビューアのやるべきこと
レビューイはレビューアの意図を理解しようといろいろと質問してくるでしょう。レビューアはそれに対し自分の意図を相手にわかるように説明できなければなりません。ここでしどろもどろになってレビューが壊れていく、、よくある光景ですね。つまり、レビューアは設計書なり実装なり、明確な意図をもってレビュー資料を作成し、その意図を説明する準備をしておかなければなりませんね。
自己表現
レビューは自己表現の場なんですね。レビューアがうまく自己表現できなければ議論はできず、有意義なレビューになりません。自己表現がうまくいけばそれに対する反論や別のよりよい方法をレビューイから引き出すことができます。 逆にレビューイは、レビューアの提案を正しく評価し、場合によってはより有効な情報を提供しなければなりません。相対的にレビューイは経験も技術力もレビューアより求められます。でもそれよりなにより、レビューアの意図を徹底的に理解しようという姿勢が大事です。 若い人で、まだまだ、自信がなくてレビューに参加するだけになってしまっているなら、まず、そういう姿勢を身に着けるのもいいかもしれません。もちろん事前準は怠ってはいけません。
何か掘り起こせた？
- 参加者それぞれが明確に自分の考えを持たなければならない。 まずはここからなんだろうと思ってます。 有名人の言葉か、映画や小説のセリフか忘れましたが、こんな言葉をきいたことがあります。 「アイデンティティがなければ誰にも何も伝わらない。」
おしまい
「早くレビューやって共犯者作ろう」なんて冗談がありますが、「主犯は自分」という現実からは逃れられませんね。
Pythonで機械学習（kaggle入門その２）
はじめに
前回の「Titanic: Machine Learning from Disaster」に続いて、 もう一つのチュートリアル「House Prices: Advanced Regression Techniques」をやっていきます。
【概要】
アイオワ州エイムスの住宅について、住宅価格を予想するもの。 訓練用データの79項目の説明変数（敷地の広さ、キッチン・寝室数等）にて学習し、 テストデータの1459件に対して、住宅価格を予想する。
【環境】
環境は前回と同じ以下で実施。
開発言語
- Python3.7
ライブラリ
- jupyter
- pandas
- matplotlib
- seaborn
- scikit-learn
- numpy
ツール
- jupyter notebook
【課題データの取得】
House Prices: Advanced Regression Techniques | Kaggle
上記ページより以下のファイルをダウンロードする。
続きを読む