読者です 読者をやめる 読者になる 読者になる

私の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. 最後に
    マインドマップを作成してから自分の考えを整理してみました。 正直、マインドマップを使うことに対して否定的でしたが、今回使いどころが分かったので、今後の業務でも活かせそうな気がしました。

フレームワーク開発者が考えること

はじめに

自社でライブラリやフレームワークを開発する機会があります。 ただ、この分野のエンジニアって育ちにくい状況なのかなぁと思っています。

  • 人の割り当て。具体的な開発案件の方が予算も期限もあり、割り当てられやすい
  • 開発方法の違い。具体的な開発案件に比べて抽象的で分かりにくい。

ライブラリ、フレームワーク開発に着目した書籍や情報って、案外見つけにくいと思います。 「猿でもわかるフレームワーク開発、ないかなぁ」と、数年来、書店を巡るくらいですので(笑い

せっかくなので、フレームワーク開発者としての自分の考え方やをブログに残していくことにしました。

ライブラリ、フレームワークとは何ぞや

ライブラリ、フレームワークの違いについては、以下の記事が参考になると思います。

ライブラリとフレームワークの違い

一方で、フレームワークとライブラリにはフレームワークには、いくつか間違った認識があると思います。

フレームワークへの勘違い

こういう共通ライブラリはいらない

フレームワーク開発の魅力は、具体的な各案件に隠れていた一連の処理を見つけ出し、ワークフロー化することだと思っています。

フレームワーク開発者に必要なことって何?

人が割り当てられないことや、開発方法が他の案件と異なることが、本当に開発者の育成を妨げている原因なのでしょうか?

ライブラリやフレームワーク開発者には、どのような事を求めているのでしょうか?

  1. C++, C#など、開発言語に対する知識が高いこと
  2. UMLなどでモデリングできること
  3. デザインパターンを知っていること
  4. 要件分析ができること

私の勤める会社での、ライブラリ、フレームワーク開発者に対する認識ってこんな感じだと思います。 とにかく、レベルが高くないといけない、難しいことが考えられないといけない、と。 いやいや、本当にそうなの?

自分はUMLモデリングしますが、言語知識は求めているレベルには達していないと思います。 デザインパターンは知っていますが、要件分析した上でモデリングする際に、あくまで役に立つ程度の知識です。

自分が行ってきた開発の経験上、ライブラリ開発者の必要条件とフレームワーク開発者の必要条件は違うと思います。

自分が思っている、フレームワーク開発者に必要なものは、少なくとも次の2つではないかと思います。

  1. 要件分析ができること
  2. UMLなどでモデリングできること

ただ、要件分析が、具体的な案件と違い、難しいのかもしれませんが(^_^;

これから、自分が抱えた事例をもとに、何かしら考えをまとめられたらと思います。