2017年を振り返る

今年を振り返った。けっこう駄文w

f:id:kabe-aa:20171231102424p:plain

  1. 会社への計画

    • 自分の作業に余裕を作る
      6月あたりから、ほぼ上流設計しかしなくなった。けど、システムの要求仕様まとめるだけで今年は終わった。 。。 そもそも工数の都合でやってなかったので仕方ない… 要求仕様作成の経験者がいない、ってのも… まぁ、良い経験させていただいております(^^;;

    • 社員レベルの向上
      詳細設計、実装、(今までのレベルで)のテストは別の人に任せることができた。ただし1人だけど。
      今の問題は、自分に設計が依存してしまうこと。
      「どう設計してほしいか分からない」と言われるので結局自分で設計する羽目に。むー(; ̄ェ ̄)
      設計意図を伝えるような書き方を意識してたけど、自律的に向上させるためには、別の方法でサポートした方が良さそうです…   

    • 開発プロジェクトの改善
      当初やろうとしたことは手付かず…
      というか、グループ内の仕事改革が起きて、仕事の仕方を見直す場ができた。
      前半でキレて良かったかな(よくない笑
  2. 自分の目標

    • テスト力の向上
      今年は、某塾やモデルベーステスト自動化の分科会、他にも色んな勉強会に参加したので、色々学ぶことが多かった。
      (テスト設計ではなく)機能設計にはだいぶ反映されているかなぁ。。。アウトプットできる成果は今のところないけど。。。  
    • 設計力の向上
      機能開発以外は、ほとんど他人に任せた、と思う。 その分、他人の設計を読み取る力も身についた。  
    • 問題解決手法を学ぶ
      今年初めにTOCfEに出会ったのは大きいかも。 あと、エニアグラムの講習を受けた事で、自己理解・受容できるようになった。 自分が感じた違和感を適切な方法で伝えられる、良い方法を一緒になって考えられるようになった事は、今年一番の成果だと思います。  
  3. 当面の業務
    1つは完成して、必要に応じてアドバイスする程度なので、手離れできた。
    もう一つは、システムアーキテクチャごと変更してるので継続中…という言い訳してるけど、やっぱり見積もりは甘かったなぁという感想。
    でも、今一番欲しいスキルは、見積もりというより、メンバーの力をうまく引き出す方法ですかね。

  4. 最後に
    今年は、『ながーいトンネルの中でようやく光が見えた気がする』一年だった
    多くの出会いと学びをいただいて、皆さんに感謝です。
    来年もよろしくお願いします!

9人のテストエンジニア

この記事は、「ソフトウェアテストの小ネタ Advent Calendar 2017」の20日目の記事です。

qiita.com

エニアグラムを使って、テストエンジニアの特徴を考えてみたいと思います。

エニアグラムについて

自己成長とコミュニケーションのための人間学』と呼ばれています。

f:id:kabe-aa:20171218103419p:plain
エニアグラム

詳しく知りたい方は、ググってみてください(許諾を得ていないため、リンクは載せませんw)

テストエンジニアにいそうな特徴を、エニアグラムのタイプ別に考えてみたいと思います。 私自身は認定コースを受講していますので基本的なところについては把握していますが、それでも個人的な主観が入ってしまうことをご了承ください。

業務で自分のタイプに囚われたり、同僚と対立を生まないため、特徴を理解したい想いで考えてみましたので、ご参考程度にしていただけたらと思います。 また、タイプは自分の強く出るところですので、他のタイプの良いところを自分のものにして行けば、今後の成長に役立てられると思います。

※ ステレオタイプに当てはめてしまって行動したり、相手の方を当てはめてしまうことを私は望んでいません。

タイプ1:改革する人(本能:ガッツセンター)

テストを抜け漏れなく確実に実施したり、周りがその通りに行動するような施策を作ることが得意だと思います。

ただ、不要なテストを省略せずに全数実施することで時間が足りなかったり、作った施策を周りが実施しないことにイライラすることがあるかもしれません。 タイプ7のように、自分のタスクを気楽に考えること、周りを楽しませるように施策を考えると良いかもしれません。

タイプ2:人を助ける人(感覚:ハートセンター)

自分の業務に関係なく、テストの準備を手伝ってあげたり一緒に実施するのが好きなのかもしれません。 でも、感謝されないとストレスが溜まる傾向にあると思います。

個人のタスクを達成する事。タイプ4を参考にすると良いと思います。

タイプ3:達成する人(感覚:ハートセンター)

テストアーキテクチャ設計など、先進的な考えを導入することが得意だと思います。 また、効率性が高く、少ないテストケースの実施で、欠陥の検出できるような特徴があると思います。

たとえ、設計が先進的であっても、プロジェクトに適合できるかの検証が漏れてたりします。 効率性を重視するあまり、テストケースに抜け漏れがあるかもしれません。

タイプ6のように忠実にテストを実施すること、十分な検証も必要かもしれません。

タイプ4:個性的な人(感覚:ハートセンター)

個人ワークで黙々とテスト作業することが得意だと思います。 プロジェクトに影響されずに自分で試行錯誤して解決することができますが、一方でプロジェクトの解決するべき課題にならない傾向にあると思います。

単純なテストケースの実施は苦手かもしれません。。。 感覚が優れているので、逆にテスト実施中に別のケースに気づくことがあると思います。 ただ、アドホックにならないようにしたいです(自戒の意味も込めてw

タイプ1のように、プロジェクトの課題として改善に繋げることが必要だと思います。

タイプ5:調べる人(思考:ヘッドセンター)

テスト技法や最新のアーキテクチャ設計方法などを自ら調べ知識にしたり、プロジェクトの問題点を分析することが得意です。 ただ、プロジェクト全体から一歩引いている傾向にあり、メンバーに知識を提供しますが、それが実施可能かどうかまで検討しない傾向にあるかもしれません。

タイプ8のように、プロジェクトの達成のために積極的にチームに入っていくことが成長につながると思います。

タイプ6:忠実な人(思考:ヘッドセンター)

単純なテストケースを実行すること、作業を着実に進めることが得意だと思います。 ただし、難しい課題に直面すると、全体像がつかめず一部の問題解決だけを追求することがあるかもしれません。 テストの網羅性を把握しない、組み合わせテストで全数テストすることがあるかもしれません。

不安を感じたり分からないことがあれば、全体に問題としてあげること。タイプ9のようにチーム全員で協調することが必要だと思います。

タイプ7:熱中する人(思考:ヘッドセンター)

興味を持った技法やテストアーキテクチャ設計をすぐ試したいと思い、周りを楽しく巻き込むことが得意だと思います。 ただ、自分の業務を分析せずに適用しようとしたり、反対メンバーに歩み寄ることを苦手とするため、最終的にグダグダになることがあるかもしれません。

タイプ5のように分析すること、反対メンバーがいたら意見を聞くようにすることが良いと思います。

タイプ8:挑戦する人(本能:ガッツセンター)

プロジェクトや自分のタスク達成のための目的を本能で理解し、周りを巻き込んで実行する力があると思います。 また、不具合が発生した場合にリスクや影響範囲を収集し、いち早く消化する事に優れていると思います。

ただ、実行力に優れている反面、スキルが低いエンジニアを置いてけぼりにする傾向があるかもしれません。 タイプ2のように、一人一人に歩み寄り理解してあげる事が良いかと思います。

タイプ9:平和をもたらす人(本能:ガッツセンター)

プロジェクト自体やメンバー全員がまとまっていて協調することに生きがいを感じ、ファシリテーションが優れていると思います。 比較的ゆったりとしたペースで作業しますが、自分のペースに合わない状況がプロジェクトで起こると、ストレスを感じるかもしれません。。。

タイプ3のように、成功や効率を求める考え方を取り入れると、自分と一緒にプロジェクト全体を成長させることができるかもしれません。

最後に

テストエンジニアとあまり関係ない気がしますね(笑) また、自身のタイプである4は、記述多めです(笑

自分で読み返して思いついたのですが、プロジェクトの各工程の抜け漏れを防ぐためのチェックリストとして活用できる気がしました。

よろしければ参考にしていただけたらと思います。

WACATE2017冬公開のBPP三部作、堂々完結

って、BPP賞をいただいた話から、半年間ブログ更新してなかった(汗

というわけで、WACATEの内容に関する事は他の人に任せて、前回のBPP受賞者が過ごしたWACATEについて書きたいと思います(笑

WACATE2017 冬 ~すべてがTになる~ 開催概要 - WACATE (ソフトウェアテストワークショップ)

第1部:BPPセッション

自己理解をして、自身の日常や業務に役立てましょう』というライフハック方法の紹介です。
公開しているスライドでは、以下の内容をカットしています。 

  • 具体的な業務内容
  • ライフハックの元ネタ(このネタも含めた完全版スライドは来年公開するかも。今は伏せさせてくださいw)

www.slideshare.net

発表でやったこと、工夫したこと

  • 自分の緊張をほぐすため、最初に台本にないことを適当に喋って笑いをとる。
    今回は『初回参加の人を確認して、ベテランの暴走を抑制する』ことをしてみました。
    本当は別の事を話すつもりでしたが、、、(第02回ひとりラジオ BPPセッションで確認)

  • 全体を伝えておいてからの「話しません」で、徐々に本題に絞っていく

    • 1回目
      業務紹介した際。
      一応、BPPセッションの内容として、開発・テストの話も考えていたことを伝えるため。

    • 2回目(発表テーマに対しては1回目)
      だって、セルフコントロールコーチングの方法知らないもんw
      でも、自己理解できれば、最終的には繋がると思っています。

    • 3回目(発表テーマに対しては2回目)
      今回の発表の元ネタ(スライド非公開)なのに、話さないという暴挙に出た瞬間w


      元ネタを話し始めたらキリがなくなるし、そのワークショップを開催するためのアドバイザーの資格を持っていないので。
      でも、それを使わなくても、自己理解できることを紹介したかったのです。
      ライフハック」は、「別の言葉」から置き換えてツイートしてもらっていますw

  • 小ネタの応酬
    一つ目の手がかりにて言ったセリフ

    • 「『ピンときちゃった』ってどう言うことですか?」(某T社のCMの満島ひかりを意識して、人差し指を立てる)
      → 知らない人が多数と思われる(似てないとは思っていないw)。ただ、満島ひかりが好きなだけなので、言えて満足w

    • 「『父さん、妖気です』ってことですか?」(鬼太郎の妖怪アンテナが立った時に言いそうなセリフ)
      → 何人かがクスッと笑ってくれた。

    • 「『姉さん、事件です』ってことですか?」(ホテルの高嶋政伸のセリフ)
      → 語感が似てただけで勢いで言う。もちろんダダ滑りwwww

  • 発表内でのワーク

    • 簡単なケースを試してもらった。
      分かったからって「あいつは、このタイプだから嫌い」って殴り合いの喧嘩はしないでね。

    • 2つ目の手がかりのワークはやめた。
      WACATE実行委員から「時間超えるかも」「初めての人にはワークは難しいので、具体例を出して欲しい」というアドバイスをいただきました。 実際に自分のケースが思いつくだけでも1週間以上近く考えたので、最終的にワークをやめました。この判断は賢明だったかも。

  • 本スライドに影響を受けたもの

    • なそくんの2017夏のBPPセッションのスライド
      社外でよく見るLTのスライドとして参考にしました。

      www.slideshare.net

    • 第37回テストラジオ
      プレゼン資料の作り方は参考になりました。 twitcasting.tv

    • 進入禁止のテープ
      公開されないスライドにある素材だから、検索しても見つからないw なんとかフリー素材を見つけて使用しました。

    • IBM細川さんのプレゼン方法
      「初の社外での発表でインスパイアされてますよ、全く似てないですけどねw」と余談を入れてみる。
      「結果として自分らしいプレゼンが出来上がったし、スライドを作るためのモチベーションにもなりましたよ」って言いたかったの。

  • よかったこと

    • 発表しているときは、案外落ち着いていた

    • 30分ぴったり終わった
      普段は緊張しぃなのに、本番で強いのはなんだろね、とか思いつつw

    • ゴングを鳴らすことができたw

  • 悪かったこと

    • 語尾の癖
      自分でも気になるので、直したいところです。。。

第2部:夜の分科会

WACATEの夜の分科会のオーナーになりました。 やったことは「皆さんで自己理解してみよう」でした。

10人ぐらい集まったかも。嬉しい反面、モデレータとしての責任が。。。

分かったことは、

  • 好プレーって案外出てこない
    自分じゃ当たり前の事だから、案外好プレーは本人からは出てこないですね。。。
    もうちょっと思いつきやすい行動で、引き出し方を考えた方が良いと思いました。

  • 例えは、もっと難しい
    まぁ、承知の上だったので、聞き役になって引き出そうと思ってたけど難しかったw

最終目標として「キミはこの直感を使って、こんなのするのが上手いんだね。」と認識するところまで行きたかったけど、ただの自分語りの会になってしまったような、、、
でも、一人から「自分のことが分かった気がします」という意見をいただけて嬉しかったです。
もっと改善できるよう頑張ります!

第3部:夜の一人ラジオ

テストクラスタお馴染みの「なそとオカウチワニのテストラジオ」の「第02回 ひとりラジオ BPPセッション」のゲストとして参加しました。 今回の発表の裏話が聞けます。

twitcasting.tv

自分の声ってこんなんなんだ笑、しどろもどろだし、恥ずかしいな笑

今回のWACATEの雑感

今回は、セッションあり、分科会モデレータあり、ラジオパーソナリティあり(?)と、幅広く経験させていただきました。
セッションが終わった後は、登壇者の横でずっと聞いていました。特別席かっ!
小学校の授業で騒いで先生の前で座らされた気分にもなりましたがw

WACATEの詳しい感想は内容は後日載せるかも。。。

あと「コミュ力強化」をテーマに掲げていたので、自分の班のファシリテーションや意見の抽出を積極的にやらせていただきました。
6人中3人が初回参加でしたが、それぞれのセッションの目標を達成できるように意見を引き出せたかなぁ、と思います。
次回も参加してくれるといいですね。

WACATEスタッフの皆さん、開催までの間色々とご迷惑をかけてしまいましたが、とても貴重な経験をさせていただき、ありがとうございました。 そして、参加者の皆さん、お疲れ様でした。

WACATEでBPPをもらった話

すでに半月経ってしまいましたが(^^;;

6/17, 18の2日間、マホロバマインズ三浦で行われたワークショップWACATEに参加してきました。

WACATE2017 夏 ~技法はいつもひとつ(とは限らない)~ 開催概要 - WACATE (ソフトウェアテストワークショップ)

そこで、ベストポジションペーパー賞を戴いちゃいました☆

伝わるポジペの書き方

今なら言えますが、自分が参加した過去2回のポジペ集を分析して、本気で狙いに行きました(どや

そんな訳で、とってもレアな、BPPを狙える(かもしれない)ポジペの書き方を載せますw

ポジペ投票メンタルモデルの構築

と大それた事を書いてみましたが、『ポジペを選ぶ時の考え方』を初めに考えてからポジペの内容を決めています。
「何書こう?」で悩んだのではなく、制約を決めてから、ポジペを書くための手札を選んだ感じです。

ポジペを説明する時間がない

3分程度で何を知ってもらいたいのか?印象を残せるか?

ポジペを読む時間がない

自分のグループ以外のポジペも空いた時間で読むので、やはり印象第一。
むしろ、自分グループ以外に伝える方が重要。

ポジペで考慮した事

自分がポジペを書く際に考慮していたのは、次の通りです。

自分がどういう人間かわかること

初めの自己紹介は2 行程度で書き、残りは「それがどんな事か、分かりやすく言い換える」事に注力しました。

言いたいことがたくさんあっても情報を絞る。びっしり書かない。

2016冬は『半年間の成果』を書いていますが、「成果を元に自分を知ってもらう」戦略は、分かる人には伝わるけど、初めて会う人には伝わらないのでやめました。
どんなに「WACATEらしく加速感」があっても、伝わりづらいことは書かない戦略にしました。

専門用語はあまり使わない。代わりに、誰にでも伝わるような言葉遊びを使う。

自分が「システム全体を俯瞰する開発者」と紹介した上で、全員が分かるような例えを使うようにしました。

最初の考えた例えは「山登りで先導する」「ジャングルを探検する」イメージ。
ただ、自分のやっていることがイメージとは完全に結びつきづらく、最終的に色んな言葉が置き換えることができる「 RPGシステム開発攻略」に落ち着きました。

自分が伝わる絵を用意する

RPGシステム開発攻略なので、ドラクエのマップを某サイトを使って夜な夜な作成w
マップもこだわり始めると、ややこしいものが出来るので、あくまで補助的なシンプルなものにしました。

全体が淀みのない文章で、線として繋がるように

自分が感覚で文章を捉える人間なので(笑)、
「目に飛び込んだ瞬間から自然と読んでた」ってところが一番大事かなぁと。

テーマに合致するように意気込みを書く

「2日間、よろしくお願いします」

最後の2つは、いいや(笑)
まとめてみると大したことない、人に伝わる文章の書き方なのですが、改めて意識すると難しかったですね。

閑話休題

ポジペのイメージを固めて書く前に、既存技術がないか調査したという事で。
楽天の川口さんの「ドラクエ風スキルマップ」を見て、自分が表現したいイメージとは異なったので、気にせずに自分の思い通りに表現してみました。
がっっ!!、5/26に行われたJaSST東北で「テストエンジニア版スキルマップ」の発表があり、「ドラクエ風」な部分が類似してて、その週末が〆切だったこともあり、少し頬を赤らめながら提出しました笑

とは言っても、

賞をもらった今だからこんなこと書けますが、実際、当日はもらえる自信はなかったです(^^;;

ポジペを書く時に使った観点で読むと、もっと良いポジペを書いた人がいましたし、実際自分は『意気込み』と『加速感』が一発で飛び込んできたもの(=自分のポジペから外したもの)を選びました(その子はやはりMAP賞でした)。
なので、今回の書き方の紹介は、受賞した1ケースと思っていただければ。

ポジペの書き方にこだわった分、新しい見方が増えて、よりWACATEの醍醐味を味わえると思います。

今回から賞状が小さくなって机上に飾る事ができる!
副賞はELASTIC LEADERSHIP。読みたかった本だったので嬉しいです。 f:id:kabe-aa:20170620233613j:plain

私のTOCfE BCトリロジー

はじめに

1〜3月にかけて、TOCfE BootCampに3回参加しました。

TOCfEとは

教育のためのTOC 日本支部

思考のための3つの道具と、1つの「問いかけ」がTOCfEで、主に3つの道具の使い方の訓練の場がTOCfE BootCampです。

tocforeducation.org

アンビシャスターゲットツリー

tocfebc.doorkeeper.jp

達成できないような目標を達成するために中間目標を設定し、行動を決めるのが「アンビシャスターゲットツリー」です。

「自分の望むソフトを開発したい」という目標に対して、

  1. 障害(緑の付箋)を洗い出して、
  2. 障害をクリアする中間目標(青い付箋)を出し、
  3. それぞれの中間目標の前提条件を決めて、行動(赤い付箋)を出しました。

f:id:kabe-aa:20170320154928j:plain

ブランチ

tocfebc.doorkeeper.jp

起こった問題に対して原因を洗い出して、それぞれの因果関係を作るのが「ブランチ」でした。

この時の演習では、「某外資系企業が開発した金融システムの移行が失敗した記事」からブランチを作成しました(実際は、記事の内容だけでは作れない一番難しい演習らしいので、「なぜ継続したのか?」という観点に変えてブランチを作成しています)

一番下の原因から始まり、一番上の結果に至ったという図になります。

f:id:kabe-aa:20170320155505j:plain

クラウド

tocfebc.doorkeeper.jp

対立する行動から共通目標を見つけ、解決策を見つけるのが「クラウド」でした。

「ウサギとカメ」の演習で、「カメがウサギを起こさずにゴールする」と「カメがウサギを起こしてゴールする」と言う行動からクラウドを作った結果、「カメはウサギに認められたい」と行った共通目標になり、自分の解決策は「カメがウサギを起こして、ゴールした後にウサギを讃える」となりました。

f:id:kabe-aa:20170320154246j:plain

最後に

TOCfEが効果を発揮するのは、仕事や家族で発生する問題におけるコミュニケーションの解決だと思います。

自分は、仕事で意見が衝突しても論破されるのを避け、問題を抱えたままにすることが多いのですが、このツールを知ってから「相手の考えも正しい」と少しずつ思えるようになり、このツールを使って相手の考えの理由を引き出すようになりました。

相手の問題を引き出すことができれば、コーチングのツールとして適切だと思います。

「相手の問題を引き出すためには、相手の気持ちを理解して聞くことが必要だ」と思って、エニアグラムをより深く学習したいキッカケになました。

TOCfE BCでは使い方を学ぶ訓練をする場で、実際に仕事やプライベートでガシガシ使えるようになるにはしばらく時間がかかると思いますが、どんどん使おうと思います。

JaSST'17 Tokyoに参加して

2/3(金), 2/4(土)に開催されたJaSST'17 Tokyoに参加しましたので簡単に雑感を(本当に雑感ですw

  • 2/3(金) 9:00〜 テスト分析とテスト設計勉強会

    JaSST開催前、同会場で行われた勉強会です。

    connpass.com

    秋山さんの説明から始まり、リリカルさん、ゆもつよさん、河野さん、まりまりとLTが続きました。
    テスト分析とテスト設計の説明が非常に分かりやすく理解できたと思います。
    特に「やらなくても良いテストはやる必要はなく、やるかどうか分からないからテスト分析するんだ」はテストに対する強いモチベーションだと感じました。
    今はテスト工程をあまり知らないので愚直に実施していますが、いつかはそんな風に言えるようになりたいです。

  • テクノロジーセッション「次世代システムに求められるソフトウェア検証技術 〜 静的解析の価値と有効性 〜」「楽天トラベルの開発プロセスに関して」

    「「ビジネス要求と品質保証の不可分な関係」 ~ソフトウェアの品質を超上流で確保する~」が超満員で入れなかったので、もともと最初の予定だったこちらのセッションへ。

    初めは、MathWorksの静的解析ツールの紹介。
    今勤務している会社は、別の静的解析ツールを買って、結局使いきれなかったという黒歴史があります(笑
    このツールは、使いやすそうな感じはあったので試してみたいと思いました。
    ただ、プロセスにどう当てはめるかが肝だと思いますが。。。

    その後の楽天トラベルさんの発表を要約すると、

    1. 開発案件数、スピードが上がっている = QAが足りない
    2. テストケースが増える = テスト時間が足りない
    3. テストが漏れる = 品質低下

    の問題を、

    • 今までのテスト設計を2つに分け、設計段階から前倒し
    • 一度作成したテストケースをオートメーション化
    • “Quality Gate”(QA評価するための開発者が行うテスト)の導入

    で、開発全体の改善が図れたとのこと。 自分が進めているのはテスト方法の改善ですが、やろうとしていることは同じだったのでためになりました。

  • テストプロセス改善「普及が始まったテストプロセス改善技術 導入・実践着手のために考えるべきこと」

    テストプロセス改善でよくありがちな問題を、SEPG、コンサルタントのロールを持ったパネリストが答えるという形式でした。
    テストプロセス改善技術導入以前の、部署が抱える問題に着目してて面白かったです。
    でも、正直言えば、もう少し話を聞きたかったなぁ。。。

  • テスト技術「VSTePのファーストステップ~JaSST'16東北出張おかわり会~」

    テスト分析技法であるVSTePのワークショップに参加しました。

    VSTePの詳細は、西先生の資料を参照してください。
    http://www.jasst.jp/symposium/jasst13tokyo/pdf/A2-4.pdf

    ソフトウェアテストAdvent Calendar 2016書かれたブログ。
    「観点の蒸留」 – Qualab

    Lhacaの仕様を一通り読んだ後、以降、仕様書は読まずに、チームでテスト観点出しします。 テスト観点をグルーピングしていくと、次のようなテスト観点図が作成されました。
    f:id:kabe-aa:20170206162715j:plain

    その後、テスト観点図から、テストコンテナを作成していきます。
    f:id:kabe-aa:20170206162754j:plain

    VSTePを使ってわかったこと、感じたことは、

    • VSTePはテストの意図を伝えるもので、この後テスト計画につながる。

    • 仕様書にこだわらない視点で出す。
      チームでアイデアを出し続けることが必要

    • チームでの共通認識が持てるまで実施する
      テスト観点をキーワードで出すのではなく、チームが理解できる言葉に落とすことが重要

    • コンテナ作成と順序決めのプロセスが難しい
      一定のプロセスがなくチームで話し合って決めていくので、テスト対象の全貌が徐々に明らかになるだろうと感じましたが、うまく使うためには、VSTePを理解した上で、一般的な思考プロセスやコーチングが必要になりそうだ、と。今の自分の業務に適用するには、それなりの準備が必要。

    今回はファーストステップでしたが、VSTePを自分の中で昇華できるようになりたいなぁ、という気持ちがあります。

  • 雑感
    今回3回目の参加でしたが、WACATE参加以降で初めての参加でした。
    今回はWACATEつながりの知り合いが多かったので、より繋がりが広がり楽しめたと思います。
    JaSST参加当初は、「今の開発のテストの自動化を行いたい」というモチベーションでしたが、その考えが「開発プロセス・テストプロセスを改善したい」というモチベーションに変わっています。

    また、今までは一人で悩んでいたことも、知り合いのおかげで自分一人の背負う負担が減ってると思います(もっと早くやっていればよかった。。。

    そういった事も含め、うちの社員にも積極的に社外で得てほしいため、自分の体験ごと社内に展開したいと思っていますが、
    そのために、まずは「社員が開発で抱えている問題を聞いていくこと」が自分の行うことであり、今は、問題を引き出すスキルの必要性を感じています。

今年の計画

遅くなったけど、今年の計画を立てた。

f:id:kabe-aa:20170121164115p:plain

  1. 会社への計画
    まず、会社での仕事の目標は「生産性を上げること」「新規開発に対する余裕を作ること」
    そこから、自分のやるべきことを挙げた。
     
  2. 自分の作業に余裕を作る
    人員の都合で、一つの案件に対して全ての開発フェーズを担当することが多いですが、その結果、設計やテストが比較的おそろかになるのが現状です。
    今年は、自分が担当している案件の「実装」「テスト実行」のフェーズは、できる限り他に回るようにしたいと思う。
    自分の業務は、(品質の高いテストを作る上で)自分しかできない設計やテスト設計中心にシフトし、同時に、自分以外の人が設計したものに対してレビューするようにしたい。
    今は、様々なドメインで設計できるわけではないし、テストの着眼点も甘いので、今年は多くの経験を積みたいと思う。
      
  3. 社員レベルの向上
    自分の時間に余裕を作るためには、社員の技術を向上させることも不可欠。 他の人が自分の設計を理解して、実装できるようにしていく。 また、実装だけでなく、設計やテスト設計できるよう向上させていきたいと思う。
      
  4. 開発プロジェクトの改善
    この作業はずっと続けていますが、TPI NEXTによるテスト改善や不具合分析については、ある程度目処をつけたい。 その次に、ソフトウェアのリリーステストを改善し、探索的テストを導入してみたい。
      
  5. 自分の目標
    自分の目標は、「会社に対する計画」に対して自分が足りないところを身につけていきたい
     
  6. テスト力の向上
    去年は、WACATEの参加で、テストに対する力がついてきたと思いますが、もっとテスト分析や設計ができるようになりたい。 テスト設計ができるようになれば、自動テストを設計できるようになるので。 あとは、自己評価のために資格を取得していきたい。
     
  7. 設計力の向上
    上でも書いたように、いろんなドメインで設計できるようになりたい。 また、他人に任せることも身につけたい。
     
  8. 問題解決手法を学ぶ
    他人に任せることが多くなり、レビューする機会が増えたら、問題解決を提案できなければならないので、今年は学習機会を増やして、業務に使えるようにしたい。
     
  9. ディープラーニングを学びたい
    今は優先度は低いですが、案件としてきた場合に備えて。 ただ、上記のことが解決し、自分の作業に余裕ができたら取り掛かりたいので、現時点で優先度は低い。
     
  10. 当面の業務
    2つのフレームワーク開発を完成させることが当面の業務。 まずは、今の業務を今年の計画に基づいて実施してみたいと思う。
     
  11. 最後に
    マインドマップを作成してから自分の考えを整理してみました。 正直、マインドマップを使うことに対して否定的でしたが、今回使いどころが分かったので、今後の業務でも活かせそうな気がしました。