2019年ふりかえり

今年も去年に引き続きいろいろなことに挑戦しました！
なんとなく気持ち的には停滞してる気持ちでしたけど、思い返すといろいろしてるなー。

やったこと

JSTQB FL合格
wacate初参加
講演に登壇（複数人）
転職
認定スクラムマスターになった
娘と二人で実家に帰る（3日間）

JSTQB　FL合格

合格しました！
昨年からテストに興味があったけど、ちゃんと体系的な知識を取り入れたかったので勉強がてら取得しました。
ちょうど並行して社内でテストプロセスの導入に関する取り組みもしていたので、知識と取り組みがうまく結びついてとても役に立ったのを覚えています。

wacate初参加

以前からTLにてwacateというとても楽しそうなイベントがあることを知っていましたが都合が合わずに行けませんでした。が、夏に参加することができました！
QAの方と接する機会が無かったのでとても新鮮でした。ずっと開発をしてきて、QAやテストにあまり関わってなかったので取り組む視点とか考え方とか、学べることがとても多かったです。

講演で登壇

あるところで日頃参加しているコミュニティのメンバーと登壇しました。と言っても厳密には壇上に上がってなくて、ライブコーディングとして脇でコーディングしてる人でした。
当初は自分の知識も自信がなかったので参加するかとても迷いました。結果的には、自分の知識も整理できたし、新しいことをたくさん知れたので参加できて良かったと思っています。（貴重な機会を頂けてありがたいですほんと）
特に一緒に参加した方々がいろんなこと知ってるので、発表内容のミーティングとかしてるときにもいろんな話が聞けるんですよね。機会があればこれからも挑戦していきたいですね。

転職

転職しました！
前職をやめた理由は、学びがあまり無くなってきたことと、学びが重要ではない意識が全体的に漂ってたためです。目の前のことで精一杯な状態が続いていて負のスパイラルを感じました。
「どこもそうだよ」とよく言われますが、ほんとにどこもそうか？という疑問を解消するためにも転職しました。
結果的にはどこも一緒だったような、良くなったようなって感じです。割といろいろなことに自由がきくので、働きやすくはなったと思います。

認定スクラムマスターになった

スクラム開発をしているわけでは無いですが、開発にその活動やエッセンスを取り入れたいなと思っていました。
研修ではスクラムや各イベントの目的を特に意識するような内容でしたし、私は結構苦手なところだったので学びが多かったです。
あと、スクラムとかアジャイルでとことん話ができる機会って身近には無いのでめちゃくちゃ楽しかったです！

娘と二人で実家に帰る

唐突なプライベートですが。
退職前の有休消化を使って平日に、初めての娘と旅してきました（実家だけど）。実家まで車で5時間かかるのでそれなりの小旅行です。
マジでめちゃめちゃ仲良くなりました！仲悪かったわけじゃないですけど、今までは母じゃなきゃ嫌だって言ってたことが、父でも良くなったりしました。（風呂とか、寝るとか、トイレとか）
とは言えその1ヶ月後くらいから父親イヤイヤ期みたいなのが来てキライって言われたりしてましたけど！

今年はPMを受験できなかったので、今年は受験したいと思います。あとはネットワーク関係の知識が不足していて支障をきたしそうなので、そこら辺もなんとかしていきたいですね…。

STMボードNucleo64を使ってみる

ETWESTEでSTMボードを手に入れたので、少し遊んでみたいと思います！ ET展ではいつも配布しているのですが、持っていませんでした。

金曜のETWESTで、これもらえたからいろいろ遊んでみよ！ pic.twitter.com/VbCqVqUaHq

— avaler@つばめ (@avaler0604) 2019年6月17日

はじめに

とりあえずこういうときは公式のリファレンスとか読むんだよね？
っていうことでボードのユーザーズマニュアルはこちら

NUCLEO-L476RG｜デザイン/サポート｜STM32, STM8ファミリはSTの32bit／8bit汎用マイクロコントローラ製品

このなかの「UM1727 User manual」を参考にしていっています。 まずは開発環境をセットアップします。

開発環境のセットアップ

このボードのUSBのインターフェース部分（ST-LINK)のドライバのインストールからですが、開発環境にも含まれているようなので、開発環境のインストールから始めます。
とはいえこのCPUのシリーズ違いはよく使っているので、まずは私が使い慣れているEWARMを入れてみます。

ここからインストール！ https://www.iar.com/jp/iar-embedded-workbench

インストール完了！

評価版のライセンスをもらうために登録が必要なので、登録を行う

（会社名必須とか、めっちゃ企業で使うこと前提だけど個人で登録してもいいんだよね・・・と不安になりながら登録）

動かしてみる

マニュアル読んでると、ファームウェアのパッケージにExampleProjectあるみたいなので、とりあえずそれを動かして見たいと思います。

・・・ん・・・どこにあるん・・・？？？これか？これなのか！？（見つけるまでめっちゃ時間かかってしまった）

https://my.st.com/content/my_st_com/en/products/embedded-software/mcu-mpu-embedded-software/stm32-embedded-software/stm32cube-mcu-mpu-packages/stm32cubel4.html

あってるっぽい！サンプルのプロジェクトっぽいの発見した
STM32Cube_FW_L4_V1.14.0\Projects\NUCLEO-L476RG\Examples\GPIO\GPIO_IOToggle\EWARM
このディレクトリにあるProject.ewwを起動してみる

無事にビルドできた

サンプルプロジェクトのLチカが動いた！（まだコードは書いてない・・・） pic.twitter.com/vrEekxK2s8

— avaler@つばめ (@avaler0604) 2019年6月18日

とりあえず動かすのもなかなか大変でした。マニュアルもあんまり見てないしコードも書いてないでまだ・・・。

んー次はこのサンプルコードにテストハーネスを実機に入れてみようかな。

技術的負債を返済したい

久々のブログです。

今日のふりかえりで「開発スケジュールが逼迫しているから、何かを犠牲にしないといけない」みたいな話になりました。技術的負債ですね。

ただ、今までの経験上、負債を返済できたことがありませんでした。そういった負債を作らないように「モブワーク」とか「ユニットテスト」とかを導入している節もあります。

そのため、最初は反対の気持ちでしたが、「負債を管理しておけば、今の私達なら返済できるのでは」といった話がでました。
過去の私達はタスクの管理もしてなければ、個人で仕事をしていたので、返済をスケジュールすることはほとんどありませんでした。
しかし「いまならチームで立ち向かうことができるのでは」と思っています。

やってみることとして、「やらなかったことリスト」を作ってみることにしました。私達が意図して作成した技術的負債を目に見える形にしておくことで、返済しなければならないタスクを見えるようにしておきます。また、抱えた負債の内容を他人が見ることができるので、「これは早く返済ししないといけない内容だ」という判断もできるようになるのでは、と思っています。

っていう話をしたときに、後輩くんが「きのこ本に書いてあった気がする」といっていたので改めて読んだら、１つ目がまさにこの話でした！

GWは改めて本を読み直してみよう、と思った話でした。（１０連休だー！） 

プログラマが知るべき97のこと

心理的安全性ゲームを体験してきた

だいぶ日にちが経ちましたが、先日、心理的安全性ゲームを体験してきたので、雑ですが感想を書きたいと思います。

体験してきました！楽しく学べた！
同じ言葉でも状況によって全然受け取り方が違うということを実感。
今度うちのチームでやろう。#心理的安全性ゲーム pic.twitter.com/FC9myIAMQV

— avaler (@avaler0604) 2019年2月21日

心理的安全性ゲーム

ゲームの詳細は以下を参照ください。

games.yattom.jp

感想

• 状況カード、発言カードがあるあるなので、具体的な場面が想像できた
  • ゲームをしてて（あーこれあのときのあれやなー）みたいな想像ができました。ゲームを通じてふりかえりができる。
• 「あのときにはあのカードでこういえばよかった」みたいなふりかえりができる
  • これは帰ってから気づいたのですが、ゲーム中に手札が良くなくて、かなりネガティブなことを言ってしまいました。でも、あとで考えると他のカードでポジティブに捉えれる言い方もあったなというのを思いつきました。こういう経験は実際にも結構多いので、ゲームで慣れておくことで、その場面に遭遇しても一息ついて考えられるくせがつけれそうです。
• 発言カードが一見ネガティブに見える内容でも、状況や言い方によっていい印象に変わるし、その逆もある
  • 例えば「関係ないよ」っていうのも、「自分には関係ないから知らない」というふうに捉えられる使い方もあれば、「あなたには関係ないから大丈夫」というふうに捉えられることもある。
• ゲームでネガティブな印象に慣れておくことで、実際にそういう場面に出くわしたときに「あっ、それゲームのやつやん」みたいになる
  • うちのチームで少しやってみたときに気づいた内容です。良くない状況のときに良くない発言とかがあったとき「それ〇〇カードのやつやん」と気づけることで、場の雰囲気の回復がスムーズでは、ということでした。
• 状況カードを自分のチームに合わせてもっと具体的な状況を追加しても面白そう
  • これもチームで気づいた内容です。初期のカードはあるあるなことが多くてそれでも十分なのですが、もっと具体的な自分のチームのあるあるを追加すると、より実践的なゲームになりそうでした。

まだチームでしっかりとゲームできていないので、近いうちにやってみたいと思います！

チームで初めてのKPT

本日はチームで初めてKPTを行いました！

うちのチームでは日ごろから振り返りの機会がほとんどないので、先週行ったFunDoneLearnに続き、新しい取り組みです。
やり方はカイゼンジャーニーのKPTのページを参考にしました。

カイゼン・ジャーニー たった1人からはじめて、「越境」するチームをつくるまで

やってみて気づいたこと

• よかったこと（keep）や問題点と思っていることが他のメンバーと被っていると共感できて嬉しい。
• 「あれよかったよねー」と話ができるのが良い。今までのチームでお互いによかったことを話す機会なんてなかった。
• 日ごろから「感じたこと」をメモするなりしないと忘れてしまう。（忘れるくらいなものは振り返る必要もないのかも？）

共感できるのは良いですね。最近はモブワークを中心にしていますが、「良かった」「悪かった」みたいな感想を言い合う機会を作れてませんでした。今回のKPTで私が良かったと思ってたことを他のメンバーも「同じこと思いました！」って言われると「やっぱり！？」みたいな、より一体感を感じた気がしました。

チームとして、良い気づきを得ていた

他にも問題を出し合ってるところで、「リファクタリングできていない」という問題が上がったのが個人的にはすごくよかったです。
今年度の最初はそもそもテストを書く習慣がなかったチームが、リファクタリグが無いことを問題と感じていて、テスト→リファクタリングの手順で設計を行っている。ということが実感できました。テストの内容はまだまだですが、この１年間でチームとしてはかなり成長できていると思いました。

TRYもちゃんと決められた！

TRYについても、ちゃんとやることを決められました。今までは「カイゼン！」って言うと少し空気が重くなるのを感じていましたが、今回は問題点もみんなで共感した項目だったので、「できそうなレベル」で、しかも効果がありそうなTRYが上がりました。

おわり

いままでチームで振り返るきっかけがなかったので少し敬遠していましたが、杞憂でした。いまのところは週１回のペースで続けて行きます。たぶん、数回もやれば、自然とモブワークの中でシームレスにKPTの思考で振り返りを回せるようになるのでは、とも思ってます。

gccでCppUTestを使う

CppUTestが使えるようになりました。備忘録として、手順を記載しておきます。
（事前にCppUTestをビルドしてライブラリにしておき、テスト時にリンクするようにしています。）

GoogleTestをビルドしたときにと同じやり方でいけました。
その時は、以下のページを参考にさせてもらいました。

nekko1119.hatenablog.com

CppUTestも同じようにしていきます。
以下のページからCppUTestをダウンロード、解凍。
https://cpputest.github.io/

解凍したディレクトリで以下を実行。 

mkdir mybuild
cd mybuild
cmake -G "MinGW Makefiles" ..
cmake -G "MinGW Makefiles" ..
mingw32-make

※cmakeのコマンドの部分、１回だけではなぜかエラーが出るので、２回コマンド実行しています。（ちゃんとエラー読んでなくて、調べてもないのは良くないね・・・。でも２回やったら通るんだもの・・・。）

1回目の時のエラーの画面。

ちなみに、初めて実行したときはpthreadがなくて、mingw32-make時にエラーがでました。
mingw32のウィザード使ってpthreadを入手すれば無事ビルドできます。

以下のディレクトリにライブラリができています！

\mybuild\src\CppUTest\libCppUTest.a
\mybuild\src\CppUTestExt\libCppUTestExt.a

あとは、テストにリンクしてビルトすれば、CppUTestでユニットテストが書けます。
pthreadが使用されているので、-pthreadをつけるのを忘れずに。

g++ -pthread test.cpp -L. -lCppUTest hoge.o 

※CppUTestのライブラリはテストを実行するディレクトリに移動しています。
※test.cppにcファイルのヘッダをインクルードするときはextern "C"{ } でくくるのを忘れずに。

２０１８年振り返り

今年はいろいろと新しいことに挑戦しました。簡単に振り返ってみたいと思います。

今年始めたこと（初めてやったこと）

・テスト自動化の環境構築（GoogleTest、Jenkins）

・JaSSTの初参加

・Twitterでインプット・アウトプットを始める

・ブログを開設

・社内で輪読会を開催

・テスコンチュートリアルに初参加

・ソフトウェア品質技術者を受験

・デイリースクラムを導入

・モブワークを導入

今年一年でかなりテストによってますね。ユニットテストを書くのは楽しいです。でも、テスト観点とかを考えるようなところはこれと言って実践できていないので、来年からは本格的にやっていきたいですね。そういう意味では、今年は環境構築がメインでインフラが整ってきた感じですね。

以下、なんとなく印象に残っていることを書いてみます。

TDDの実践

昨年の１１月ころにTDDに初めて触れました。そもそもユニットテストの存在も知らなかったので「実機でテストしなくてもテストできるの！？」のいう衝撃でした。ただ、環境の構築が難しく、昨年は実践できていませんでした。２０１８年に入って、３か月ほど環境の構築をぼんやり考えるうちに、何とか自分の環境でgoogletestを動作させることができました。このあたりがすべての始まりだと思います。

JaSSTの初参加

TDDを実践できる環境を構築できたものの、レガシーコードとの戦いが待っていました。一人で進めるのはなかなか厳しく、チームで取りかかることを決めます。ちょうどそのころ、JaSSTという存在を知り、そこにt_wadaさんが登壇することを知り、参加することに。TDDの講演は初めてだったのでかなり感動しました。

JaSSTに参加したことで、QAやテスターといった職種に触れるきっかけになりました。外の世界を知らなかったので、品質保証といえば「ちゃんとやれよ」とか「バグ出すなよ」と言っているようなもんだと思ってました。（とんでもないですね・・・。）
また、講演で「Twitter　OKです」みたいなことが平然と行われているのにも衝撃を受けたのを覚えています。あまりそういう会に参加していなかったもので。そこでTwitterで情報収集できるやん、ということで、インプット用のTwitterのアカウントを作成しました。（いまのやつ）
このあたりからテストにとても興味を持ちます。

チームでユニットテストを書く

レガシーコードに立ち向かうにはチームでの取り組みが必要だと判断し、JaSSTで見たTDDの講演をチームに対して行います。感触はいまいちでした。テストは必要なのはわかるけど、難しい、何をテストしたらいいかわからない　という意見が多かったと思います。

TwitterのTLに流れてくるテスト関連の話題を追っていたので、何をテストしたらいいかわからない　というのは自分も思っていて、テストは奥が深かったんですよね。特に私たちは自分たちで開発からテストまでしないといけないので、TDD的なテストだけではなくて、QA的な目線からみたテストもする必要があって、そこの知識は正直だれも持ち合わせていないことに気づきます。（今のまだ不足しています）

アウトプットを始めてみた

Twitterを始めたこともあり、ブログを開設してアウトプットを始めました。大したことを記事にはできていませんが、アウトプットできる環境があるだけで、日ごろから「これ記事にできそう」と考える癖がついてきてます。
記事にできそうって思うと、手順とかその時に考えていることを残すようになるので、記事にできなかったとしても、振り返りに活用できています。

輪読会の開催

「エンジニアは勉強が必要！」というのは常に思っています。勉強といっても、教科書があってノートに書いて問題解いてとかじゃなくて、アンテナ張って「お、これなんか面白そう、使えそう」みたいなものを少し試すでもいいと思ってます。でもやっぱりそうは言っても実際は難しいので、社内で学習できる時間の確保を行いたいと思ってました。ちょうどリーダブルコードを読んでいたので、輪読会でも開催してみようということではじめました。今のところ継続できているので、良い感じです。

輪読会だけでなくて、その時間をTDDとかテスト技法の勉強時間にも使えています。まあでも、私がやりたいことをやっているだけ感も出ているので、私はそれでいいのですが、チームがもっと強くなるにはもう少し何か必要かもしれませんが・・・。

来年は、もう少し本格的にテストに対して力を入れていきたいと思っています。いつか社内でQA立ち上げてもいいんじゃないかと思っています。とりあえず申し込んだJSTQBfoundationの合格を目指して勉強します（資格駆動）。
PMの知識ももう少し欲しいので、IPAのPMも受験したいですね（資格駆動）。
もう午前１免除の期間すぎちゃったので、起床試験からの受験になりますね・・・。