9人のテストエンジニア
この記事は、「ソフトウェアテストの小ネタ Advent Calendar 2017」の20日目の記事です。
エニアグラムを使って、テストエンジニアの特徴を考えてみたいと思います。
エニアグラムについて
『自己成長とコミュニケーションのための人間学』と呼ばれています。
詳しく知りたい方は、ググってみてください(許諾を得ていないため、リンクは載せませんw)
テストエンジニアにいそうな特徴を、エニアグラムのタイプ別に考えてみたいと思います。 私自身は認定コースを受講していますので基本的なところについては把握していますが、それでも個人的な主観が入ってしまうことをご了承ください。
業務で自分のタイプに囚われたり、同僚と対立を生まないため、特徴を理解したい想いで考えてみましたので、ご参考程度にしていただけたらと思います。 また、タイプは自分の強く出るところですので、他のタイプの良いところを自分のものにして行けば、今後の成長に役立てられると思います。
※ ステレオタイプに当てはめてしまって行動したり、相手の方を当てはめてしまうことを私は望んでいません。
タイプ1：改革する人(本能:ガッツセンター)
テストを抜け漏れなく確実に実施したり、周りがその通りに行動するような施策を作ることが得意だと思います。
ただ、不要なテストを省略せずに全数実施することで時間が足りなかったり、作った施策を周りが実施しないことにイライラすることがあるかもしれません。 タイプ７のように、自分のタスクを気楽に考えること、周りを楽しませるように施策を考えると良いかもしれません。
タイプ2：人を助ける人(感覚:ハートセンター)
自分の業務に関係なく、テストの準備を手伝ってあげたり一緒に実施するのが好きなのかもしれません。 でも、感謝されないとストレスが溜まる傾向にあると思います。
個人のタスクを達成する事。タイプ４を参考にすると良いと思います。
タイプ3：達成する人(感覚:ハートセンター)
テストアーキテクチャ設計など、先進的な考えを導入することが得意だと思います。 また、効率性が高く、少ないテストケースの実施で、欠陥の検出できるような特徴があると思います。
たとえ、設計が先進的であっても、プロジェクトに適合できるかの検証が漏れてたりします。 効率性を重視するあまり、テストケースに抜け漏れがあるかもしれません。
タイプ６のように忠実にテストを実施すること、十分な検証も必要かもしれません。
タイプ4：個性的な人(感覚:ハートセンター)
個人ワークで黙々とテスト作業することが得意だと思います。 プロジェクトに影響されずに自分で試行錯誤して解決することができますが、一方でプロジェクトの解決するべき課題にならない傾向にあると思います。
単純なテストケースの実施は苦手かもしれません。。。 感覚が優れているので、逆にテスト実施中に別のケースに気づくことがあると思います。 ただ、アドホックにならないようにしたいです(自戒の意味も込めてw
タイプ１のように、プロジェクトの課題として改善に繋げることが必要だと思います。
タイプ5：調べる人(思考:ヘッドセンター)
テスト技法や最新のアーキテクチャ設計方法などを自ら調べ知識にしたり、プロジェクトの問題点を分析することが得意です。 ただ、プロジェクト全体から一歩引いている傾向にあり、メンバーに知識を提供しますが、それが実施可能かどうかまで検討しない傾向にあるかもしれません。
タイプ８のように、プロジェクトの達成のために積極的にチームに入っていくことが成長につながると思います。
タイプ6：忠実な人(思考:ヘッドセンター)
単純なテストケースを実行すること、作業を着実に進めることが得意だと思います。 ただし、難しい課題に直面すると、全体像がつかめず一部の問題解決だけを追求することがあるかもしれません。 テストの網羅性を把握しない、組み合わせテストで全数テストすることがあるかもしれません。
不安を感じたり分からないことがあれば、全体に問題としてあげること。タイプ９のようにチーム全員で協調することが必要だと思います。
タイプ7：熱中する人(思考:ヘッドセンター)
興味を持った技法やテストアーキテクチャ設計をすぐ試したいと思い、周りを楽しく巻き込むことが得意だと思います。 ただ、自分の業務を分析せずに適用しようとしたり、反対メンバーに歩み寄ることを苦手とするため、最終的にグダグダになることがあるかもしれません。
タイプ５のように分析すること、反対メンバーがいたら意見を聞くようにすることが良いと思います。
タイプ8：挑戦する人(本能:ガッツセンター)
プロジェクトや自分のタスク達成のための目的を本能で理解し、周りを巻き込んで実行する力があると思います。 また、不具合が発生した場合にリスクや影響範囲を収集し、いち早く消化する事に優れていると思います。
ただ、実行力に優れている反面、スキルが低いエンジニアを置いてけぼりにする傾向があるかもしれません。 タイプ２のように、一人一人に歩み寄り理解してあげる事が良いかと思います。
タイプ9：平和をもたらす人(本能:ガッツセンター)
プロジェクト自体やメンバー全員がまとまっていて協調することに生きがいを感じ、ファシリテーションが優れていると思います。 比較的ゆったりとしたペースで作業しますが、自分のペースに合わない状況がプロジェクトで起こると、ストレスを感じるかもしれません。。。
タイプ３のように、成功や効率を求める考え方を取り入れると、自分と一緒にプロジェクト全体を成長させることができるかもしれません。
最後に
テストエンジニアとあまり関係ない気がしますね(笑) また、自身のタイプである４は、記述多めです(笑
自分で読み返して思いついたのですが、プロジェクトの各工程の抜け漏れを防ぐためのチェックリストとして活用できる気がしました。
よろしければ参考にしていただけたらと思います。
WACATE2017冬公開のBPP三部作、堂々完結
って、BPP賞をいただいた話から、半年間ブログ更新してなかった(汗
というわけで、WACATEの内容に関する事は他の人に任せて、前回のBPP受賞者が過ごしたWACATEについて書きたいと思います(笑
WACATE2017 冬 ～すべてがTになる～ 開催概要 - WACATE （ソフトウェアテストワークショップ）
第１部：BPPセッション
『自己理解をして、自身の日常や業務に役立てましょう』というライフハック方法の紹介です。
公開しているスライドでは、以下の内容をカットしています。
- 具体的な業務内容
ライフハックの元ネタ(このネタも含めた完全版スライドは来年公開するかも。今は伏せさせてくださいw)
www.slideshare.net
発表でやったこと、工夫したこと
自分の緊張をほぐすため、最初に台本にないことを適当に喋って笑いをとる。
今回は『初回参加の人を確認して、ベテランの暴走を抑制する』ことをしてみました。
本当は別の事を話すつもりでしたが、、、(第02回ひとりラジオ BPPセッションで確認)全体を伝えておいてからの「話しません」で、徐々に本題に絞っていく
1回目
業務紹介した際。
一応、BPPセッションの内容として、開発・テストの話も考えていたことを伝えるため。2回目(発表テーマに対しては1回目)
だって、セルフコントロールやコーチングの方法知らないもんw
でも、自己理解できれば、最終的には繋がると思っています。だって僕知らないもんｗ #wacate
— yoshitake (@yoshitake_1201) 2017年12月16日3回目(発表テーマに対しては2回目)
今回の発表の元ネタ(スライド非公開)なのに、話さないという暴挙に出た瞬間w
この話もしません！w#WACATE
— ブロッコリー (@nihonbuson) 2017年12月16日安定のこの話はしませんw#wacate
— なそ@さとうひろゆき (@hiroyuki3gou) 2017年12月16日この話もしません！(2回目 #wacate
— ぱいん🍍🍬 (@pineapplecandy) 2017年12月16日
元ネタを話し始めたらキリがなくなるし、そのワークショップを開催するためのアドバイザーの資格を持っていないので。
でも、それを使わなくても、自己理解できることを紹介したかったのです。
「ライフハック」は、「別の言葉」から置き換えてツイートしてもらっていますw
— 伊藤由貴 (@yoshikiito) 2017年12月16日
小ネタの応酬
一つ目の手がかりにて言ったセリフ
今日の振り返り
— Koki Abe (@koooooooooooki) 2017年12月16日
「ピンときちゃった！」 by 満島ひかり → スルーされる
「父さん、妖気です、という事ですか？」 → 少し笑い
「姉さん、事件です、ですか？」 → スルーw
発表内でのワーク
簡単なケースを試してもらった。
分かったからって「あいつは、このタイプだから嫌い」って殴り合いの喧嘩はしないでね。2つ目の手がかりのワークはやめた。
WACATE実行委員から「時間超えるかも」「初めての人にはワークは難しいので、具体例を出して欲しい」というアドバイスをいただきました。 実際に自分のケースが思いつくだけでも1週間以上近く考えたので、最終的にワークをやめました。この判断は賢明だったかも。
本スライドに影響を受けたもの
なそくんの2017夏のBPPセッションのスライド
社外でよく見るLTのスライドとして参考にしました。BPPセッション 良いチームを作ろう from 佐藤 博之www.slideshare.net第３７回テストラジオ
プレゼン資料の作り方は参考になりました。 twitcasting.tv進入禁止のテープ
公開されないスライドにある素材だから、検索しても見つからないw なんとかフリー素材を見つけて使用しました。IBM細川さんのプレゼン方法
「初の社外での発表でインスパイアされてますよ、全く似てないですけどねw」と余談を入れてみる。
「結果として自分らしいプレゼンが出来上がったし、スライドを作るためのモチベーションにもなりましたよ」って言いたかったの。
よかったこと
発表しているときは、案外落ち着いていた
30分ぴったり終わった
普段は緊張しぃなのに、本番で強いのはなんだろね、とか思いつつwゴングを鳴らすことができたw
悪かったこと
- 語尾の癖
自分でも気になるので、直したいところです。。。
- 語尾の癖
BPPセッション無事終わって一安心しました。ベテランさんが生温い目(笑)で見守っていただいて感謝です #wacate
— Koki Abe (@koooooooooooki) 2017年12月16日
第２部：夜の分科会
WACATEの夜の分科会のオーナーになりました。 やったことは「皆さんで自己理解してみよう」でした。
10人ぐらい集まったかも。嬉しい反面、モデレータとしての責任が。。。
分かったことは、
好プレーって案外出てこない
自分じゃ当たり前の事だから、案外好プレーは本人からは出てこないですね。。。
もうちょっと思いつきやすい行動で、引き出し方を考えた方が良いと思いました。例えは、もっと難しい
まぁ、承知の上だったので、聞き役になって引き出そうと思ってたけど難しかったw
最終目標として「キミはこの直感を使って、こんなのするのが上手いんだね。」と認識するところまで行きたかったけど、ただの自分語りの会になってしまったような、、、
でも、一人から「自分のことが分かった気がします」という意見をいただけて嬉しかったです。
もっと改善できるよう頑張ります！
第３部：夜の一人ラジオ
テストクラスタお馴染みの「なそとオカウチワニのテストラジオ」の「第02回 ひとりラジオ BPPセッション」のゲストとして参加しました。 今回の発表の裏話が聞けます。
自分の声ってこんなんなんだ笑、しどろもどろだし、恥ずかしいな笑
今回の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。読みたかった本だったので嬉しいです。
私のTOCfE BCトリロジー
はじめに
1〜3月にかけて、TOCfE BootCampに3回参加しました。
TOCfEとは
思考のための3つの道具と、1つの「問いかけ」がTOCfEで、主に3つの道具の使い方の訓練の場がTOCfE BootCampです。
アンビシャスターゲットツリー
達成できないような目標を達成するために中間目標を設定し、行動を決めるのが「アンビシャスターゲットツリー」です。
「自分の望むソフトを開発したい」という目標に対して、
- 障害（緑の付箋）を洗い出して、
- 障害をクリアする中間目標（青い付箋）を出し、
- それぞれの中間目標の前提条件を決めて、行動（赤い付箋）を出しました。
ブランチ
起こった問題に対して原因を洗い出して、それぞれの因果関係を作るのが「ブランチ」でした。
この時の演習では、「某外資系企業が開発した金融システムの移行が失敗した記事」からブランチを作成しました(実際は、記事の内容だけでは作れない一番難しい演習らしいので、「なぜ継続したのか？」という観点に変えてブランチを作成しています)
一番下の原因から始まり、一番上の結果に至ったという図になります。
クラウド
対立する行動から共通目標を見つけ、解決策を見つけるのが「クラウド」でした。
「ウサギとカメ」の演習で、「カメがウサギを起こさずにゴールする」と「カメがウサギを起こしてゴールする」と言う行動からクラウドを作った結果、「カメはウサギに認められたい」と行った共通目標になり、自分の解決策は「カメがウサギを起こして、ゴールした後にウサギを讃える」となりました。
最後に
TOCfEが効果を発揮するのは、仕事や家族で発生する問題におけるコミュニケーションの解決だと思います。
自分は、仕事で意見が衝突しても論破されるのを避け、問題を抱えたままにすることが多いのですが、このツールを知ってから「相手の考えも正しい」と少しずつ思えるようになり、このツールを使って相手の考えの理由を引き出すようになりました。
相手の問題を引き出すことができれば、コーチングのツールとして適切だと思います。
「相手の問題を引き出すためには、相手の気持ちを理解して聞くことが必要だ」と思って、エニアグラムをより深く学習したいキッカケになました。
TOCfE BCでは使い方を学ぶ訓練をする場で、実際に仕事やプライベートでガシガシ使えるようになるにはしばらく時間がかかると思いますが、どんどん使おうと思います。
JaSST'17 Tokyoに参加して
2/3(金), 2/4(土)に開催されたJaSST'17 Tokyoに参加しましたので簡単に雑感を（本当に雑感ですw
2/3(金) 9:00〜 テスト分析とテスト設計勉強会
JaSST開催前、同会場で行われた勉強会です。
秋山さんの説明から始まり、リリカルさん、ゆもつよさん、河野さん、まりまりとLTが続きました。
テスト分析とテスト設計の説明が非常に分かりやすく理解できたと思います。
特に「やらなくても良いテストはやる必要はなく、やるかどうか分からないからテスト分析するんだ」はテストに対する強いモチベーションだと感じました。
今はテスト工程をあまり知らないので愚直に実施していますが、いつかはそんな風に言えるようになりたいです。テクノロジーセッション「次世代システムに求められるソフトウェア検証技術 〜 静的解析の価値と有効性 〜」「楽天トラベルの開発プロセスに関して」
「「ビジネス要求と品質保証の不可分な関係」 ～ソフトウェアの品質を超上流で確保する～」が超満員で入れなかったので、もともと最初の予定だったこちらのセッションへ。
初めは、MathWorksの静的解析ツールの紹介。
今勤務している会社は、別の静的解析ツールを買って、結局使いきれなかったという黒歴史があります（笑
このツールは、使いやすそうな感じはあったので試してみたいと思いました。
ただ、プロセスにどう当てはめるかが肝だと思いますが。。。その後の楽天トラベルさんの発表を要約すると、
- 開発案件数、スピードが上がっている ＝ QAが足りない
- テストケースが増える ＝ テスト時間が足りない
- テストが漏れる ＝ 品質低下
の問題を、
- 今までのテスト設計を2つに分け、設計段階から前倒し
- 一度作成したテストケースをオートメーション化
- “Quality Gate”(QA評価するための開発者が行うテスト)の導入
で、開発全体の改善が図れたとのこと。 自分が進めているのはテスト方法の改善ですが、やろうとしていることは同じだったのでためになりました。
テストプロセス改善「普及が始まったテストプロセス改善技術 導入・実践着手のために考えるべきこと」
テストプロセス改善でよくありがちな問題を、SEPG、コンサルタントのロールを持ったパネリストが答えるという形式でした。
テストプロセス改善技術導入以前の、部署が抱える問題に着目してて面白かったです。
でも、正直言えば、もう少し話を聞きたかったなぁ。。。テスト技術「VSTePのファーストステップ～JaSST'16東北出張おかわり会～」
テスト分析技法であるVSTePのワークショップに参加しました。
VSTePの詳細は、西先生の資料を参照してください。
http://www.jasst.jp/symposium/jasst13tokyo/pdf/A2-4.pdfソフトウェアテストAdvent Calendar 2016書かれたブログ。
「観点の蒸留」 – QualabLhacaの仕様を一通り読んだ後、以降、仕様書は読まずに、チームでテスト観点出しします。 テスト観点をグルーピングしていくと、次のようなテスト観点図が作成されました。
その後、テスト観点図から、テストコンテナを作成していきます。
VSTePを使ってわかったこと、感じたことは、
VSTePはテストの意図を伝えるもので、この後テスト計画につながる。
仕様書にこだわらない視点で出す。
チームでアイデアを出し続けることが必要チームでの共通認識が持てるまで実施する
テスト観点をキーワードで出すのではなく、チームが理解できる言葉に落とすことが重要コンテナ作成と順序決めのプロセスが難しい
一定のプロセスがなくチームで話し合って決めていくので、テスト対象の全貌が徐々に明らかになるだろうと感じましたが、うまく使うためには、VSTePを理解した上で、一般的な思考プロセスやコーチングが必要になりそうだ、と。今の自分の業務に適用するには、それなりの準備が必要。
今回はファーストステップでしたが、VSTePを自分の中で昇華できるようになりたいなぁ、という気持ちがあります。
雑感
今回3回目の参加でしたが、WACATE参加以降で初めての参加でした。
今回はWACATEつながりの知り合いが多かったので、より繋がりが広がり楽しめたと思います。
JaSST参加当初は、「今の開発のテストの自動化を行いたい」というモチベーションでしたが、その考えが「開発プロセス・テストプロセスを改善したい」というモチベーションに変わっています。また、今までは一人で悩んでいたことも、知り合いのおかげで自分一人の背負う負担が減ってると思います（もっと早くやっていればよかった。。。
そういった事も含め、うちの社員にも積極的に社外で得てほしいため、自分の体験ごと社内に展開したいと思っていますが、
そのために、まずは「社員が開発で抱えている問題を聞いていくこと」が自分の行うことであり、今は、問題を引き出すスキルの必要性を感じています。
今年の計画
遅くなったけど、今年の計画を立てた。
- 会社への計画
まず、会社での仕事の目標は「生産性を上げること」「新規開発に対する余裕を作ること」
そこから、自分のやるべきことを挙げた。
- 自分の作業に余裕を作る
人員の都合で、一つの案件に対して全ての開発フェーズを担当することが多いですが、その結果、設計やテストが比較的おそろかになるのが現状です。
今年は、自分が担当している案件の「実装」「テスト実行」のフェーズは、できる限り他に回るようにしたいと思う。
自分の業務は、（品質の高いテストを作る上で）自分しかできない設計やテスト設計中心にシフトし、同時に、自分以外の人が設計したものに対してレビューするようにしたい。
今は、様々なドメインで設計できるわけではないし、テストの着眼点も甘いので、今年は多くの経験を積みたいと思う。
- 社員レベルの向上
自分の時間に余裕を作るためには、社員の技術を向上させることも不可欠。 他の人が自分の設計を理解して、実装できるようにしていく。 また、実装だけでなく、設計やテスト設計できるよう向上させていきたいと思う。
- 開発プロジェクトの改善
この作業はずっと続けていますが、TPI NEXTによるテスト改善や不具合分析については、ある程度目処をつけたい。 その次に、ソフトウェアのリリーステストを改善し、探索的テストを導入してみたい。
- 自分の目標
自分の目標は、「会社に対する計画」に対して自分が足りないところを身につけていきたい
- テスト力の向上
去年は、WACATEの参加で、テストに対する力がついてきたと思いますが、もっとテスト分析や設計ができるようになりたい。 テスト設計ができるようになれば、自動テストを設計できるようになるので。 あとは、自己評価のために資格を取得していきたい。
- 設計力の向上
上でも書いたように、いろんなドメインで設計できるようになりたい。 また、他人に任せることも身につけたい。
- 問題解決手法を学ぶ
他人に任せることが多くなり、レビューする機会が増えたら、問題解決を提案できなければならないので、今年は学習機会を増やして、業務に使えるようにしたい。
- ディープラーニングを学びたい
今は優先度は低いですが、案件としてきた場合に備えて。 ただ、上記のことが解決し、自分の作業に余裕ができたら取り掛かりたいので、現時点で優先度は低い。
- 当面の業務
２つのフレームワーク開発を完成させることが当面の業務。 まずは、今の業務を今年の計画に基づいて実施してみたいと思う。
- 最後に
マインドマップを作成してから自分の考えを整理してみました。 正直、マインドマップを使うことに対して否定的でしたが、今回使いどころが分かったので、今後の業務でも活かせそうな気がしました。
フレームワーク開発者が考えること
はじめに
自社でライブラリやフレームワークを開発する機会があります。 ただ、この分野のエンジニアって育ちにくい状況なのかなぁと思っています。
- 人の割り当て。具体的な開発案件の方が予算も期限もあり、割り当てられやすい
- 開発方法の違い。具体的な開発案件に比べて抽象的で分かりにくい。
ライブラリ、フレームワーク開発に着目した書籍や情報って、案外見つけにくいと思います。 「猿でもわかるフレームワーク開発、ないかなぁ」と、数年来、書店を巡るくらいですので（笑い
せっかくなので、フレームワーク開発者としての自分の考え方やをブログに残していくことにしました。
ライブラリ、フレームワークとは何ぞや
ライブラリ、フレームワークの違いについては、以下の記事が参考になると思います。
一方で、フレームワークとライブラリにはフレームワークには、いくつか間違った認識があると思います。
フレームワーク開発の魅力は、具体的な各案件に隠れていた一連の処理を見つけ出し、ワークフロー化することだと思っています。
フレームワーク開発者に必要なことって何？
人が割り当てられないことや、開発方法が他の案件と異なることが、本当に開発者の育成を妨げている原因なのでしょうか？
ライブラリやフレームワーク開発者には、どのような事を求めているのでしょうか？
私の勤める会社での、ライブラリ、フレームワーク開発者に対する認識ってこんな感じだと思います。 とにかく、レベルが高くないといけない、難しいことが考えられないといけない、と。 いやいや、本当にそうなの？
自分はUMLでモデリングしますが、言語知識は求めているレベルには達していないと思います。 デザインパターンは知っていますが、要件分析した上でモデリングする際に、あくまで役に立つ程度の知識です。
自分が行ってきた開発の経験上、ライブラリ開発者の必要条件とフレームワーク開発者の必要条件は違うと思います。
自分が思っている、フレームワーク開発者に必要なものは、少なくとも次の2つではないかと思います。
ただ、要件分析が、具体的な案件と違い、難しいのかもしれませんが(^_^;
これから、自分が抱えた事例をもとに、何かしら考えをまとめられたらと思います。
