第二十九日 問題点を明確に/Determining the problem

三連休は、家族とお寿司を食べに行きました、永井盛久です。久しぶりにスポーツでもしようかなと思ったのですが、暑さが強敵過ぎて・・・気が付いたら連休が終わっていました。

 

今日は、前に英会話レッスンで教えていた内容が役に立った!という報告をミャンマーに一週間出張していた社員の方に頂きました。最初は、英語を教える事に対して少し消極的だったのですが、実際に役に立ったと言ってもらえると素直にうれしいです。これからも、英語面で積極的にお手伝いが出来たらいいなと思います。

 

さて、機械学習の実案件の方なのですが、まだまだ作業が難航しています。グラフは相変わらず思い通りに表示されないので、ちょっと泣きそうになりますね(笑)。今週中にはしっかりとしたプロトタイプを完成させ、来週には精度を上げる作業に入らないともう残り時間が無いので、頑張っていこうと思います。

 

今回、なぜこんなにも作業が難航しているのか。それは私が作業工程のステップごとに確認をしないまま作業を進めて行ってしまったためです。このせいで、ソースコードに問題点がどこにあるのかがわからないのです。今回の件で言うと、私がデータの加工が正確に出来ているか確認しないまま学習のステップに入ってしまったため、学習のステップで間違いが出ているのか、それともデータ加工のステップでエラーが発生したのかわからなくなりました。

 

また、予測データをチェックしなかったために、グラフ化するサイトの設定が間違えているのか、それともサイトに送るデータそのものが間違えているのかハッキリしない状況が出来てしまいました。そのため、一つ一つ間違いが起こりうる箇所をつぶしていくのに時間を無駄にしてしまっています。

 

f:id:acroquest:20160719180823j:plain

 

正直なところ、「もう時間が無い!」と思い、焦ってしまっていたため確認が甘くなってしまったのだと思います。しかし、最終的に、細かくチェックすることに時間を使う方が、後になって問題点を探していくよりも効率的で、成果につながるという事を痛いほど実感しました。作業をユニットに分け、一つずつ動作確認した後に通してプログラムを走らせることで、問題点が明確にする事が容易になり、修正作業がよりスムーズに行えます。

 

問題点を明確にすることに時間を取られないよう、「おそらく」こういう事であろう・・・で済ませるのではなく、100%理解できるようにしないといけない箇所は「確実」に確認するべきだと上司にも言われました。確かに抑えるところを抑えないと曖昧なまま作業が進んでしまい、結果間違えていましたでは笑いごとになりませんからね。

 

やはり、成果を出さないといけないので、最終的にどの方法を選べば結果が出るか見極められるようにならないといけないですね。先週に書いた、報告することにプラスして、作業工程の細かいチェックも残り三週間徹底していこうと思います。そして、ここの意識を高めることで更に結果Drivenになれると思います。 

 

 

 P.S. 今日はランチで一年ぶりくらいに冷麺を食べました。写真はその際の様子です。

永井盛久

 

 

Today, I was told by one of the employee who took my English class that what I taught him was very useful in AcroMyanmer. This genuinely makes me happy, and I hope that I can continue this positive influence within the company.

 

I am still struggling on my machine learning project, and nothing is really going well. My graphs are still chaotic, and I honestly do not know what to do with them. Today, I learned a lesson in a hard way, that I should check my work more frequently.

 

I have spent so much time on trying to find what I did wrong, and I seriously regret why I decided not to check my work more frequently. For example, I did not check if my data was properly processed before moving on to the regression step, so I was not able to tell if my problem was coming from the data processing step, or regression step. Also, I was not really careful when I was trying to get the prediction data, so I was not sure where my mistake was coming from in the graph.

 

Honestly, I was rushing to complete my prototype, so this might be why I did not check my code with my boss more frequently. The reason why I keep on mentioning the word “Check” is because by grouping my work steps and checking each one, I can determine where the error is coming from immediately, if any error pops up after running the code as a whole.

 

It took me a lot of time determining what I was doing wrong, and this is wasting so much time. To prevent this, I really have to keep on asking questions until I am 100% sure of what I am supposed to be doing. If I half-knowingly do something, the program might be completely busted by the time I finish coding, and it will take so much time to fix them.

 

In the end, it is all about getting results. In order to get results fast, I need to be able to determine what kind of method I need to choose. It may seem that checking every step will take a long time; it won’t take as much time as trying to find the source of the problem after finishing all the coding. I will try to remember this as I fix my prototype this week.

 

 

Morihisa Nagai