Developers Boost 2020参加メモ
- はじめに
- 参加の動機
- 参加してみての感想
- 全てのエンジニアに求められていること ～新卒1年半で技術執行役員になって感じたこと～
- 古の大企業向けパッケージソフトのクラウド移行にJoinして見えた面白さ
- コミュニティ活動で差別化をめざすエンジニアとしての一手
- 開発/データ分析基盤開発チームの、データを用いた内部カイゼンの話
はじめに
こんにちは、Yumihikiです。今回はデブスト2020に参加した記事を書きます。
ちなみに最初の方はしっかりスライドを見ながら下書きを残していたのですが、後半からTwitterのガヤ芸人をしていたのでまともなメモを残せていません（笑）
なので感想などを中心に、最後の方は自分用のメモとして残しておきます。
参加の動機
同世代のエンジニアの方の活躍を聞いて、モチベーションを高めようと思い参加しました。元々イベントの存在はエンジニアに転職する前から知っていたのですが、エンジニアになってから参加するんだ・・・！と言う気持ちで参加を見送っており、やっとこさ参加したというわけです。
参加してみての感想
やっぱり勉強会の参加はとても楽しいですね・・・！ 今回はエンジニアの生き方について中心に話を聞くつもりでしたが、気がついたら全て聴講していました。やはり通してみなさんがおっしゃっていたことはアウトプットの大事さでした。
端的に言うとアウトプットを行うための取り組みが自身の勉強にもなり、認知してもらうことで価値を上げ、強みを作っていけるという感じです。発表の中ではみなさん、さまざまな理論を基に取り組みの裏付けをされていて適切に努力を行うことの大事さが良くわかりました。
これは私も最近心がけるようにしてきていますが、がむしゃらに頑張るのではなく具体的に頑張ることが必要です。そのためには理論的・論理的な取り組みと自分がどうなりたいか、どうやって行きたいか、自分は何のスキルを持っているのか、何が足りないのかといった棚卸しが必要になってきます。私は今年になってエンジニアに転職したこともあり諸々を把握できているつもりでしたが、他の方の取り組みを見るとまだまだ出来ていないことがありました。
特にここ最近は「こうなりたい」と言う姿に対しての努力が余り出来ておらず、改めて伸び代を感じることが出来たのが大きな収穫です。せっかくなのでこの学びを実際に取り組んで活動するまでを、また別の記事に書き起こして行きます。
このような具合に自分のキャリア、モチベーションといった点を強く考えるチャンスをいただけたのが良かったです。
それ以外の話で言うと、みんな辛いことはあるんだなと少し励みになりました（笑）
自分のキャリアであるとか、能力面だとか、リモートワークであるとかの自分が辛いと思う・感じることは同じように周りも捉えている、と言うのは「辛い」状態に入ると意識出来ない点なので。みんな自分と同じように焦ったり苦しんだりするんだよと思えることはメンタルの余裕さにもつながるのではと考えています。
このみんな同じ、と言うことが私の中で、今回のデブストのテーマである「Share your ENGINE! ～ひとりじゃない～」と非常にマッチしていると感じました。このイベントに参加出来たことは自分のエンジニア人生の中で良い糧にして行きたいと切に思っています。
今私は28歳になる年なので、30歳の最後のデブストの参加可能ラインの時に登壇できるよう、一歩ずつアウトプットに取り組んで成長して参ります！
通しての感想は以上です。下記に、エンジニアの生き方的の面で参考になったスライドのリンクを掲載しておくので興味がある方はぜひ見て下さい！（その他の見つけられなかったスライドもあり、他の方の発表も素晴らしいものだったことを念の為、記載しておきます！）
全てのエンジニアに求められていること ～新卒1年半で技術執行役員になって感じたこと～
江草 陽太さん[さくらインターネット]
タイトルからすごい・・・！
今に至るまでの話
社会インフラを自社製品として作っていて工程の広範囲に携われる規模感の会社を考えていた
当時200人程度の規模感でちょうどよかった
得意分野を生かすことができる
この辺りが決め手
当時のさくら全体の技術を見る役割の人が明確にはいなかったから、そういう人を置くべきではと相談した結果、江草さんがやることに
当時、それが取り締まりになるということとは思っていなかったそう
幸い、どんな分野でも会話はできるレベルにはいたそう
組み込み
アプリケーション
インフラ
役員会に出ると投資などの話も出るが、簿記の資格があったため理解できた
エンジニアとして生きていくには
実装できるだけでは影響力をモテない
説明力と読解力は大事
成果物だけで会社、世界を変えられるほどの技術力を身につけることは難しい
ドキュメントを正確に読む、エラーメッセージを正しく読む
正確に説明する能力、正確に読解する能力がとても重要
変化についていくことが重要だから
変化が激しい時代でも変わらないのは自然科学
ツールや使うシステムは変わっても動作原理は変わらない
原理原則を理解していれば新しいものも理解できる
プログラミング言語の習得の話などもそう
新しくITのことを勉強しようと思ったら逆に難しい時代
CPUなど理解しなくても開発ができるが、そもそもの原理がわからないと良くない
どう言った現象
物事を進めるコツは単純化すること
課題を整理し、単純化すると理解されやすい
解決すべきクリティカルな課題を減らすことができる
解決策がシンプルになる
一般化しやすくなるので、思考を減らせる
バランス感覚が重要
一つの理想解全体の最適解とは限らない
速い、短い、かっこいい、だけが全てではない
保守性に乏しいコードとか・・・
理解できていないことは遂行できない
自分が理解できていないことを他人とやるのは難しい
実装はできなくても良いので最低限理解をする
なんとなくの理解で使っているものは使う以上のことはできない
自分の分野は自分がプロになるしかない
他社に依頼するときなど、お願いしたら良い感じに作ってくれるだろうというのはなく作ってもらっているものの仕組み バッチ、リアルタイムなど 理解して話をすることが大事
古の大企業向けパッケージソフトのクラウド移行にJoinして見えた面白さ
増井 秀和さん[Works Human Intelligence]
弓道の写真を貼っていた
COMPANYの話
クラウドサービス
96年に誕生したレガシーアプロ
密結合
320万行を超えるコード・・・
SlackでRSS Appをしよう
手に入れた情報はすぐに手を動かして試す
大変だったけど、新しいサービスのキャッチアップを行えた
古いアプリケーションは裏を返せば今でも生き残るニーズがあるということ
時代の潮流に生き残ることは大変だが、その先の製品でハッピーになってくれる人がいる
エンジニアとしては難題の方が経験になる
どれだけ他人に語れる経験ができたかそのまま勝ちになる
チャレンジ→悩む→後悔する を超えた先
コミュニティ活動で差別化をめざすエンジニアとしての一手
加納 悠史さん[ラクス]
自身へのメリット
組織へのメリット
キャリア的メリット
コミュニティを覗く
参加する
学習のモチベーションを登壇にする
登壇することで人に説明できる知識を得られる
コミュニティ運営で得られるものがある
最初は登壇から初めてアウトプットを武器にする
興味があれば運営サイドも行う
情報の捉え方、より深い情報を主体的に手に入れられる
会社はコミュニティに消極的？
広報活動
文化の醸成
開発/データ分析基盤開発チームの、データを用いた内部カイゼンの話
青山 弦太さん[ビッグツリーテクノロジー&コンサルティング]
チームカイゼン
データは皆に自信をくれる
データを取る前からわかっていたことでも、仮説を自信に変えてくれるメリットがある
カイゼンは一歩ずつ
一足とびにやるのは大変だけど、一歩ずつ行うことで積み上げて大きな改善になっていく
1年目は公式リファレンス、
4年目は〜
5年目は登壇
成長に悩むことはあるが、小さい歩幅で着実に進んでいこう
（そしてここからTwitterへ移行して参りました・・・・・）
はじめてのバグのおはなし
Crieitさんにて投稿しました。
テスト仕様書について
こんにちは、Yumihikiです。今回はテスト仕様書についての記事を書きます。
テスト仕様書とは、ソフトウェアテストのあれこれをまとめた文書のことです。具体的な定義は調べた限りなさそうですが、テスト仕様書で検索した結果、次のようなことが仕様書に含まれることが多そうです。
- テストの条件
- 実行内容、シナリオ
- 想定結果
- 実施日
- 実施者
- エビデンス
- その他コメント欄
そのほかには
- テストの目的
- 実行方法
- テストの区分（正常系・異常系）
- 進捗状況
といった項目を設けるところもあるようです。
また、使用する媒体はExcelやGoogleスプレッドシートでの管理が多い印象です。
実務では実際にテストを行った結果、どのような結果になったのかなどを記載するためにテスト仕様書を用意しています。でなければテストをしました！と言ったところで本当にしたのかどうかがわからないからです。
書いてみるとテスト仕様書とは何なのか？というのはすごくあっさりとした内容でしたが・・・ 実務未経験では全く見聞きしなかったものなので改めて記事に起こしてみました。おそらく色々な会社によってテスト仕様書で表すものが異なると思うので、次のお客様先で働いた際にはどんなテスト仕様書が現れるのか（？）少し楽しみにしておきたいです。
最後まで読んでいただき、ありがとうございました。
デシジョンテーブルについて
こんにちは、Yumihikiです。今回はテスト技法のひとつである「デシジョンテーブル」について解説します。
デシジョンテーブルとは、一言でいうと複雑な仕様を整理するためのテスト技法の1つです。表形式で因子・水準と対応する結果を表現したものです。
例えば、あるECサイトを運営しているとします。
その際、購入するユーザーと条件に対し、次のプログラム仕様書があった場合を想定します。
学生は平日・土日問わず、常時10%オフとする。
社会人は休日は5%オフとする。
上記を表すと次のようなデシジョンテーブルになります。
ざっくりとそれぞれの英語・記号を解説しておくと次のような意味合いになります。
Y:Yes
N:No
X:Execute（実行した場合に求まる結果を指す）
-：無関係・非該当
ここでいうと、学生・社会人・平日と書いてある青背景部分が条件部分で割引なし・5%オフ・10%オフと書いてある黄色背景部分が結果の部分になります。
デシジョンテーブルを利用することで、複数の条件の組み合わせの結果がどのように影響するのかが分かりやすくなります。
先ほどの画像の例だと比較的シンプルな条件なので、先の例の仕様書をもう少し複雑にしてみましょう。
学生は平日・土日問わず、常時10%オフとする。
社会人は土日は5%オフとする。
また、学生・社会人以外のユーザーは平日は10%オフ、休日は割引はなしである。
ただし、購入時間が平日8時〜17時の場合、学生は10%オフから20%オフになり社会人も5%オフになる。
その他ユーザーは購入時間による割引は行わないものとする。
新たにユーザーの区分が学生・社会人以外が増え、購入時間の概念が増えました。ぱっと見だと、どの区分がどういう条件で割引になるのかよく分かりません。
これをデシジョンテーブルに置き換えると次のようになります。
どうでしょうか。文章だけより、組み合わせと出力結果が分かりやすくなったのでは無いでしょうか？ 実際のプログラム・ビジネスロジックは複雑だったりすることが多いのでデシジョンテーブルを利用することで仕様を整理することができるというメリットがあります。
また、自分が実際に利用してみて良いなと思ったのは仕様の漏れや矛盾に気が付くことができるということです。今回の例で挙げている仕様でも当初「その他ユーザー」は時間の割引はどうするの？ 割引の条件が重なるとどうなるの？ ということに気が付くことができました。
デメリットを挙げると、関係の無い因子・水準を挙げてしまうとテストケース数が膨大になってしまいます。今回のケースだと12パターンのみですが、例えばこのケースに1つ新たに性別などの条件が加わっただけで24パターンにテストケースが増えることになります。
そのため、関係の無い因子・水準があれば分割する必要があります。
というわけで今回はデシジョンテーブルについてまとめてみました。
エンジニアとして働く中で、テストは開発のある意味基礎的なところだなと思ったので、引き続きテストについて学んだことをまとめていこうと思います。
ブラックボックステストの同値クラステストと境界値クラステスト
テストについて学ぼう
初めて開発現場へ入ったときにわからない単語、業務はたくさんあります。 いわゆる「テスト」について全く知らなかった私が半年の業務経験を経て少しわかるようになったので記事を残すことにします。
テストとは
開発したプログラムが要件を満たしているか確認する業務のことです。学校の中間テスト、期末テストのことではありません（笑） テストを行うことでプログラムが想定通りの動きをする事、また想定外の動きをしない事を確認します。大なり小なりどの開発現場でもテストは行っている（はず）です。
テストについて例を挙げてみます。 例えば、ECサイトで商品を購入する場合には次の手順を踏んで購入すると思います。
- 商品を選ぶ
- カートに追加ボタンをクリックする
- 商品がカートに追加される
- 購入へ進むボタンをクリックし、手続きを行う
普段何気なく商品をカートに追加、購入などの操作ができていると思いますが、万が一出来なかったらどうでしょうか？ 何気なく行った改修によってそれらの操作ができなくなったら問題です。 そういったミスがないかチェックするためにテストを行います。
テストの種類について
テストの種類としては大きく2分され、「ブラックボックステスト」「ホワイトボックステスト」が存在します。簡単に言うとブラックボックステストは プログラムの中身を見ずに行うテスト技法で、ホワイトボックステストは反対にプログラムの中身を見ながら行うテスト技法のことです。
その中で今回はブラックボックステストについて説明します。
ブラックボックステスト
ブラックボックステストは先述の特徴のため、どちらかと言うとプログラムを読まない非エンジニア、プログラマの方がテストを行う際に取り入れられるようです。
テストを行う際には仕様書（どのようにプログラムが構成されているかを書き出した文書）から実際に行う条件を洗い出し、テストを実行します。ただ、闇雲にテストを実行するだけでは非常に効率が悪く、重要なケースが漏れてしまう恐れがあるため、効率的なテスト技法として同値クラステストと境界値クラステストというものが存在します。
同値クラステスト
同値クラステストとは、同じ結果を出す値をまとめて1パターンとするテスト技法です。先ほどに引き続き、ECサイトの例を挙げます。 例えば、キャンペーンとして購入金額が一定の割合を上回った場合、景品をプレゼントするとします。 組み合わせは次の通りです。
この場合、一体何ケーステストすれば良いでしょうか？ 0円〜20001円までテストを行うとなると膨大なテストケース数に膨れ上がります。かといって減らしていこうとなった場合でも闇雲にテストを行うのでは非効率です。
例えば購入金額が1000円の場合と2000円の場合とでは結果が一緒ですよね？同じく3000円や4000円のケースも同じ結果が求まるはずです。そのため仮に金額を1000円ずつ増やして試していく、としてもテストケースが増えてしまいます。
そのために存在するのが同値クラステストです。この同値クラステスト技法を用いることでテストケースを減らすことができます。今回のケースでいうと例えば、
- 2500円
- 7500円
- 15000円
- 25000円
の4ケースを試してみることで、各ケースのパターンを確認し、仕様通りであることが確認できます。
境界値クラステスト
境界値クラステストは、判定条件の近くの値をテストします。この観点でテストを行うと、同値クラステストでの漏れや仕様、プログラムの誤りを検出することができます。先ほどの同値クラステストの例 で言うと境界値の金額とプレゼントのケースは次のようになります。
- 4999円: なし
- 5000円: ティッシュ
- 5001円: ティッシュ
- 9999円: ティッシュ
- 10000円: ハンカチ
- 10001円: ハンカチ
- 19999円: ハンカチ
- 20000円: ハンカチ
- 20001円: ティッシュとハンカチ
このテストケースを実行することで検条件判定が正しいかどうかを確認することができます。=のつけ忘れで〇〇円以上、と判定するところをより大きいとしてしまっていた場合、仮に5000円購入した場合でもティッシュがもらえなくなってしまいます。
値によって分岐させる場合、その境界となる数値の箇所にバグが入り込みやすいので確認できる、というテスト技法でした。
以上、ブラックボックステストのテスト技法について挙げました。 このような観点を持つことで、テストのケースを減らすことができます。
参考文献
はじめて学ぶソフトウェアのテスト技法
