Selenium でキーワード駆動テストを実践したときのあれこれ 『まずはやってみた編』

はじめに

12/18 Selenium 勉強会4で予定しているセッションの冒頭の話をします。

勉強会では、本編で浮き彫りになった改善点に取り組んだ話を、『リファクタリング編』として銘打ち、掘り下げて話す予定です。

 

それぞれ状況が異なれば、様々な見解があると思います。

セッションとうまく話が繋がればセッション内で言及したり、合わなくても後日お話をさせて頂きたいと思いますので、よろしければコメントください。

 

Selenium でキーワード駆動テストを実践したときのあれこれ まずはやってみた編

リファクタリング編との繋がりを考慮し、スライドによる投稿で失礼します。

www.slideshare.net

※ 駆け足で資料を作成した為、後で手直しするかもしれないです。

  すみません m(_ _)m

 

まとめ

最後のスライドの繰り返しにはなりますが、 はじめてみるとひとりの取り組みでさえも、様々な要求が湧いてきます。

これらをクリアする為に取り組んだ内容を、別日のアドベントカレンダーや勉強会4での『リファクタリング編』で紹介しますので、しばらくお待ちください(^ ^)

 

ユースケース駆動開発についての勉強まとめ そして思ったこと

先日、以下の書籍を使ってユースケース駆動開発について勉強をしました。

ユースケース駆動開発実践ガイド

ユースケース駆動開発実践ガイド

経緯

私はキーワード駆動テストアプリケーションを作っています。
せっかく時間をかけたものなので、これを公開してもっと多くの人に利用してもらおうと思いました。

ただ、そこにはまだまだ実現したいことが多く残っていました。
そこで、私はアプリケーションを利用してくれる方の中から開発に参加してくれる方を募ると良いのではないかと考えました。

しかし、私は一つの課題があることに気づきました。
これがどういうものなのかが、私にしか理解できないものになっていたことに。

そこで、対象の構造を改めて誰もが分かる形で表現するにはどうしたらいいのか?と考え、
手に取ったのが本書でした。

本書を読んだのは、本当にたまたまです。
他にもUPやRUPの本、DDDやRDDの本も手に取りましたが、要求分析からテストまでの開発の流れを体系的に理解する必要がある今の私には、これが一番自分に合っていたからです。

ユースケース駆動開発において予備設計に進める上で重要だと感じた点

要求

機能要求…システムができること(非機能も含める)
振る舞い要求…機能要求からユーザーとシステムの対話を明らかにしていくこと。

ユースケースモデリング

要求を元に、アプリケーションの振る舞いをユースケースとして記述することで、アクターとシステム間の振る舞いを明確にする。

ドメインモデリング

問題とする領域を明確にし、現実に基づいたユースケースを記述する上での用語を明確にする行為。
何を解決しなければならないのかを明らかにするために、問題領域をドメインモデルとして明らかにする。

ポイント

ユースケース記述を、解決すべき領域(ドメインモデル)の用語を用いて叙述的に書くこと。
この記述が、オブジェクト自体やオブジェクト同士の関連を見つける目的で実施されるロバストネス分析の実施を補助することになる。

勉強のまとめ

私はJJUGに参加しているのですが、昨年参加した「ビール片手にLT大会」が今年は11/21に開催されるということでした。
ちょうど良い機会だと思い、勉強のアウトプットもかねて発表してきたので、備忘録として残します。

www.slideshare.net

様々な開発手法

ロバストネス分析の結果を明らかになった、バウンダリ/エンティティオブジェクト、コントローラからシーケンス図を作成し、
そこに表現されたオブジェクト間の相互作用、必要な属性をオブジェクトに反映し、抽象的に表現した図がクラス図になります。

ユースケース駆動開発であるICONIXは、このようなアプローチで開発を進めていく手法を採用しています。

一方、本書を読む中で「そもそもオブジェクトととは?」について調べる為に参照した下記書籍では、ユースケース駆動開発とはまた別のアプローチでオブジェクトをに他の手法が紹介されていました。
詳しくは別の機会にしますが、OOADというジャンルではオブジェクトを設計をしていくという目的は同じなのですが、そこへのアプローチの仕方は他にも様々あるのだなと感じました。

私が大切だと思ったこと

開発の話からそれますが本書だけでなく、日常生活からの体験も踏まえて思ったことがあります。

  • 自分が何を大切にしていて、何かをするときに関わる人が居るときはその人は何を大切にしているのかを話してお互いに納得すること
  • 様々なシーンでの役割を理解すること
  • 良い仕事は良好な関係から生まれること

オブジェクト設計ではないですが、この世で生活をする上ではいろんなシーンがありそこでには自分の役割があるはずです。

  • 職場での役割
  • 家庭での役割
  • 社会での役割

役割がなければ自分で作ればいいのかなと思います。
役割が合わないと思えば、合わせるか、変えていけばいいのです。
私はオブジェクト設計を通してこんなことを思いました。
変な人ですね(^_^;)

今後、UPやRUP、DDDのアプローチついて勉強するのが楽しみです。

デザインパターン学んで得られたこと

キーワード駆動アプローチのテストシステムを作る上でその構造について悩んだ時に読んだこちらの書籍と、そこから学んだことを受けて考えを巡らせた時のことについて書きます。

増補改訂版Java言語で学ぶデザインパターン入門

増補改訂版Java言語で学ぶデザインパターン入門

デザインパターンの書籍を読んだ感想

テストシステムを構造化、アイディアを形に(実装)する上での良い参考例になりました。
特に「保守性」や「分かり易さ」が鍵になると考えていた次の要件を実現することができるようになったと思います。

  • 継続的にメンテナンスしながら使用していきたい
  • 他の人にもメンテナンスしてもらいながら利用してもらいたい

デザインパターンから具体的に恩恵を受けた点

具体的には次のような点でデザインパターンの恩恵を受けることができました

  • 自分のプログラムを構造化できた
  • 再利用しやすい構造にリファクタリングできた
  • JUnitといったOSSのソースを読めるようになった(コードの意図を理解できるようになった)
  • アプリケーション全体を設計する手法を知らないことにも気づけた

おかげで、OOADについて知り、ある方の紹介でユースケース駆動設計についても知る機会を得ることが出来ました。
jugemix.hatenablog.com


ICONIX」では、デザインパターンは詳細設計フェーズでオブジェクト間の相互作用を構造化する一つの手法として紹介されています。
設計について勉強しようと思っている方は、デザパタの勉強から始められると、プログラムの構造設計からアプリケーションの構造設計へと思考を広げられるようになるので良いと思います。

実際に役立ったデザインパターン

ここからは実際にOSSの中で見られたデザインパターンや、テストシステムを構築する際に実際に役立ったパターンを具体例と合わせてまとめます。

チェーンオブレスポンシビリティ

目的の処理を持つオブジェクトをチェーンのように実行していく。JUnit4.x系ではStatementクラスとして採用されているパターンである。

次のソースのmethodBlockメソッド(281行目参照)を参照いただきたい。
github.com
ここでは、Statement抽象クラス型のstatementオブジェクトに実行するオブジェクトRunBefores/RunAfters等のオブジェクトが追加されていることに気づくと思う。

テンプレートメソッド

抽象メソッドで構成する処理の流れを具象メソッドにまとめ、抽象メソッドの実装はサブクラスに任せる。
これにより、具象メソッドで処理の全体の流れは強制しつつ、具体的な処理内容は個別の実装に任せたい時に有用。
共通の前処理と後処理の間に個別の処理を実装したいーといった時に効果を発揮する。

例えば、チェーンオブレスポンシビリティで紹介したBlockJUnit4ClassRunnerクラスは実際にインスタンス化されるランナーであるが、この継承元のParentRunner抽象クラスではこのStatementを実行するrunLeaf具象メソッド(321行目参照)が実装されていて、Statement自体の作りは各具象ランナーに委譲しているテンプレートメソッドパターンとなっていることが読み取れると思う。
github.com

少し脱線しますが、JUnitを使ったテストでテストの実行順や必要な処理を追加するような場合にカスタムランナーを作られると思いますが、その場合は、このStatement型オブジェクトに意図した順に実行されるロールのオブジェクトを追加することが妥当なランナーのカスタマイズ方法だと私は思います。
これを実践しているのが、PitaliumのPtlBlockJUnit4ClassRunnerWithParametersクラスですので、参照されると良いでしょう。
github.com

ファクトリーメソッド

オブジェクトを生成する側のクラスでnewをしないでオブジェクトを生成する。

一般的なプログラミングの入門書では、生成する側のオブジェクトが生成される側のオブジェクトをnewするような記述になっている。
しかしこの場合、生成される側のクラス名等に変更が発生した場合、生成する側のオブジェクト格納先、そのオブジェクトを利用するコードにも影響が発生するがある。

そこで生成する側のオブジェクトで、生成されるオブジェクトのインタフェースを受けとるようにファクトリーメソッドを記述したらどうだろうか。
インタフェースを実装するクラスに変更があっても生成する側には、生成する箇所にしか影響が及ばないようになる。
インタフェースを介しているので、インタフェースオブジェクトを利用するコードには影響が及ばないのである。

このようなことからファクトリーメソッドを利用すると、生成されるオブジェクトと、オブジェクトを生成する側のオブジェクトの結合度を緩やかにする効果がある。
WebDriverのPageFactory.initElementsはページオブジェクトを生成する際の良い例である。
github.com

ブリッジパターン

機能のクラス階層が実装のクラス階層のインスタンスを保持し、役割を保持する構造のパターン。
機能の追加、実装の追加を同時に行うことができる。
f:id:jugemix:20161229141714p:plain

コマンドパターン

処理をオブジェクト化することで、その処理のメンテナンス性と拡張性の両方を兼ね備えることができる。
f:id:jugemix:20161229141707p:plain

その他役立ちそうなデザインパターン

その他にも役立ちそうだと思ったパターンを簡単にまとめます。

イテレータ

対象データをコレクションとして扱い拡張for文を使うことで、そのコレクションに格納しているデータを繰り返し操作できるようになる。
データを保管するクラスを作る時に、イテレータを実装するとデータの取り扱いが容易になることがある。

アダプター

既にあるAPIを利用して、必要とするAPIを作ることができる。
無理にオーバーライドせず、必要とするクラスを作ることができる。

シングルトン

インスタンスを複数作らず、使い回したいときに有効。リソースを節約できる。
PitaliumのWebDriverはWebDriverManagerシングルトンクラスにより、テスト間で使い回し可能な作りになっている。

ステート

状態を具象クラスとして扱う。そのクラスが状態に関する共通の処理をインタフェースとして実装する。
この結果、状態に応じて処理を呼び出す側は、状態インタフェースを実装したクラスのオブジェクトを保持することで、現在の状態を気にする必要がなくなる。

まとめ

一般的に知られているデザインパターンを知り使うことで、誰にでも分かりやすいコードが書けるようになることが分かったかと思います。
今後、詳細設計を行う際には、このようなパターンの適用も視野に入れて開発に取り組んでいきたいと思います。

JUnit4.13のソースを追っかけてみた

先日参加したSQiP「キーワード駆動テストシステムを作ろう」で学んだ、ランナーの役割をJUnitでも実践できるのかを検証する為に、JUnit4のソースコードを読んでみました。

 

作ったクラス図

折角、なんちゃってクラス図を書いたので公開します。

f:id:jugemix:20160924003957p:plain

 

参考にしたサイト

最初は「ランナーってなんだ?」というところから入って、こちらのサイトを参考にし始めたのですが、分かったような分からないようなままになっていました。

www.mscharhag.com

 

もやもやしたまま、SQiPのチュートリアルを迎えて、ランナーの役割が分かったところで、JUnitのソースを読むと不思議と頭に入ってきました。

 

途中、こちらのサイトも参考にさせて頂いたり

d.hatena.ne.jp

ihirokyさんは、super.runChild()をオーバーライドしたrunChild()の中で呼び出しています。これも一つの方法ですよね。

BlockJUnit4ClassRunnerを継承したカスタムランナーなので、必ずBefore/Test/Afterの間に実行されるようになります。

 

また、こちらのサイトを参考にさせて頂いたりしました。

dev.classmethod.jp

 

渡辺さんのカスタムランナーは記事でも書かれているように、ユニットテスト以外のテストにも利用されています。なので、run(notifier)からinvokeTest(notifier, testcase)を実行するような作りでカスタムランナーを作られています。面白いです。

 

結局何がいいのかというと、JUnitを使ってどんな風に「テストを実行したいか」が重要なのかなと思いました。

 

渡辺さんも書かれていますが、JUnitは「テストケースがクラス毎にメソッド単位で定義されている」というところが原則です。ですから、この考え方に沿ってJUnitを利用するのが、自然な使い方かなと僕も思います。

 

僕がカスタムランナーを作るとしたら

自分が作っているキーワード駆動テストシステムで共通した画面操作を共通処理に移すにはこうすると思います。

 

例えば、毎回ログインログアウトが必要なシステムだとします。

これをいちいちテストに書くのは面倒なので、共通処理化してしまいます。

 

案1)

・カスタムランナークラスの定義

 public Class LoginTestLogoutRunner extends BlockJUnit4ClassRunner

methodInvokerのオーバーライド

 @Override protected Statement methodInvoker(...) {

  return new CustomInvokeMethod(method, test);

 }

・@Testを実行するInvokeMethodのを継承したカスタムInvokeMethodの定義

 public class CustomInvokeMethod extends InvokeMethod

 

案2)

もしくは、JUnitのStatementクラスが「Chain of Responsibility」パターンを利用している事を利用して、Statementのサブクラスを追加しちゃうのも面白いかもしれませんね。

@Testでは、キーワードスクリプトが処理をして、その前後で共通処理を実装できればよいので。

そうすると、テストクラスはシナリオのパターン分できますが、@Testの前後で共通の処理を固定的に実行することが出来ますね。

 

案3)

@Ruleとして必ず実行させるような仕掛けにしてしまうのも、ありかもしれません。

 

9/25追記

案4)

カスタムランナーを作らずに済ませる簡単な方法は、@Testに共通処理を書いてしまって、意図した順番で実行する―というのも、一つの手かと思いました。

github.com

これなら1クラス=1テストケースとして取り扱うことが出来ますね。

渡辺さんが仰っているように、JUnitの構造上は「1メソッド=1テストケース」ですから、この点を気にしなければこの方法が一番簡単かと思います。

自動でテストを流す時に、実行するクラスが増えますが、Suiteランナーで実行するクラスをまとめてあげれば問題ないと思いました。

 

まとめ

いづれにしてもJUnitはまだまだ奥が深いし、これを使ってやりたいことはまだたくさんあります。内容を紐解いて自分がやりたいことを深堀した結果を公開したいと思います。

SQiP2016 併設チュートリアルに参加しました (キーワード駆動テスト)

SQiP併設チュートリアルのキーワード駆動テスト勉強会に参加してきました。

www.juse.jp

 

目的

  • キーワードの粒度、他の方がどのように設計しているのか知りたい。
  • 他の方のシナリオテストの準備、検証をどういう考えで実装しているか知りたい。

 

内容

今回は.NET Frameworkを使った計算機アプリのシナリオテストを、Friendlyというフレームワークをベースとして書かれたMS PowerShellで実装していくという内容でした。

 

講義

キーワード駆動の概念といった基礎的なお話から、キーワード駆動とテストスクリプトの違い、メリット・デメリットについて教わりました。

デメリットについては、特に「テストケースの増加に伴い、キーワードスクリプト間で重複する部分が出現し、テストのメンテナンスコストを下げる可能性がある」という点が紹介されました。

 

チュートリアル

キーワードスクリプトを変更するところから始まり、キーワードテストランナーの改修といった点を学びました。

 

f:id:jugemix:20160920204804p:plain

このクラス図は、チュートリアルの資料の取扱いについて小井土さんから許可を頂いたので、テスト実行の入力となるデータも追加して全体の構造を表現してみました。

 

f:id:jugemix:20160920211952p:plain

これが具体的なテスト流れRunTest.ps1の概要です。

(ループ部分は割愛してます)

 

アクティビティ図を見ると、今回の実装方針ではテストケース(キーワードスクリプト)の実行をつかさどるテストランナーと、テストケースの読み込み、テストセットの実行(テストケースの繰り返し実行)、テスト結果の比較が独立していることが分かります。

これは、今回のテストシステムの設計がキーワード駆動テストのデメリットである「共通部分の重複」を排除することを意識している為です。

 

f:id:jugemix:20160920214624p:plain

これはテストケース実行処理部分=テストランナーのフローです。

 

例えば、ログイン→商品選択→決済→ログアウトというシナリオがあったとき、①商品選択だけ1つも選ばない、②1つ選ぶ、③配送しきれないほど選ぶ―といったバリエーションを持たせてテストをたいとします。

 

これをキーワードスクリプトに書くと、スクリプト上に①~③で3回ログイン、決済、ログアウトが現れます。

 

今後のメンテナンスでログイン処理に手が加わったらどうなるでしょうか。

上記のテスト3スクリプトとも直さなければ動かないテストになってしまいます。

 

アプリケーションの修正に伴い、自動テストもメンテナンスは必要です。

この前提に立って、3つを直すより1つを直す方が運用しやすいという考えの元、ランナー側で共通部分を実行するように実装していました。

 

実運用ではアプリケーションのライフサイクルを考慮して、ランナーを設計することが望ましいと思います。(私見)

 

自動テストシステムにおけるランナーの役割は、テストの実行順や実行方法の制御だけでなく、キーワードスクリプトにおけるコードとして実装された共通処理を実行するという役割も担っていました。

 

後日 JUnitで実装する場合の調査

同じことを自分の作る自動テストシステムでも実現できるかな?と、JUnitのランナーの構造について後日調べてみました。

 

JUnitの場合は、@Beforeや@Testといったアノテーション付のメソッドブロックをその名もBlockJUnit4ClassRunnerが、methodBlockメソッドでStatementというテストの文脈(実行順のようなもの?と理解してます)オブジェクトを作り、ParentRunnerのrunLeafメソッドでオブジェクトの一つ一つを実行することでテストを実行しています。

 

もしテスト実行の共通処理をまとめるのなら、BlockJUnit4ClassRunnerのサブクラスでmethodBlockメソッドをオーバーライドするか、methodBlockが呼び出すInvokeMethodクラスのmethodInvokerサブステートメントを実装する感じになりそうでした(JavaDocにもそう書いてありました)

この為、JUnitを使う場合でもカスタムランナーで吸収することは出来そうです。

これもParentRunnerがrunChildメソッドを子クラスに委譲してくれているおかげかなと思います。

 

ただ、JUnitの構造を理解するところから理解する必要があり、長くなりそうなのでまた後日記事にまとめます。

 

参加してよかったこと

  • ランナーを使ったテストケース間で重複したテストコードの排除の方法
  • 想定結果の準備方法
  • テスト結果の検証方法はテストの目的によって異なるので、自動化する前にテストを設計すること
  • 回帰テストは前回のテスト結果と比較すると良いこと
  • バグの再現手順をテストケースとして実装すると良いこと

 

自分がキーワード駆動テストシステムを作る上で参考になる知見、気づきを得ることが出来ました。もっと実践と研究を繰り返すことで、世の中の自動化に寄与するアイディアを生み出せるんじゃないかなーと思うようになりました。

 

参加してよかった。

Java SE Javadoc Hobber の日本語文字化けを正す手順

コーディング中にJavaSE標準のAPIマウスカーソルをかざすと、Javadocがホバーしますよね。

 

私の環境(Windows 7/Eclipse Mars)では以下の問題が発生していました。

  • Java SEのJavadoc参照先が見つからない
  • 参照できるようになっても文字化けして閲覧できない

 

ネットで情報を調べても分かりにくかったので私の解決方法をシェアします。

 

  1. メニューから、「ウィンドウ>設定」をクリックします。

    f:id:jugemix:20160717140108p:plain

  2. 設定画面で、「Java>インストール済みのJRE」をクリックします。続けて、プロジェクトでビルドに使用しているJRE/JDKを選択し、「編集」ボタンをクリックします。f:id:jugemix:20160717140521p:plain

  3. JREの編集画面で、「JREシステム・ライブラリー」をCtrl+Aキーで全選択し、「Javadocロケーション」ボタンをクリックします。

    f:id:jugemix:20160717141529p:plain

  4. 開いたJavadoc画面で、「Javadocロケーション・パス」に「https://docs.oracle.com/javase/jp/8/docs/api/」を入力し、「検証」ボタンをクリックします。このパスには、「手順2」で選択したJREのバージョンと同じバージョンのjavadocを指定してください。f:id:jugemix:20160717141902p:plainインターネットで、「Java SE 8 japanese docs」と検索すると以下のサイトが検索できますので、これを指定します。

    f:id:jugemix:20160717204148p:plain

    ※1 英語のサイトもあるので、お好みでどうぞ。※2 「アーカイブ内のJavadoc」では、Oracle社のWebサイトからJavadocをダウンロードして、ローカルファイルから参照することもできます。

  5. 次のようなメッセージが表示されたら、コーディング中にJava SEのAPIにマウスをかざすことで現れるHobberに日本語のJavadocを表示することが出来ます。f:id:jugemix:20160717142050p:plain

  6. 結果は、下図のようになります。f:id:jugemix:20160717144548p:plain
  7. この時、「手順2」で指定したjreを使用しているプロジェクトの設定が「手順8」のような設定になっていないと、下図のように化けてしまうので注意が必要です。f:id:jugemix:20160717145154p:plain

  8. パッケージエクスプローラで、「手順2」で指定したjreを使用しているプロジェクトをクリックし、Altキー+Enterキーを押して、そのプロジェクトのプロパティー画面を表示します。f:id:jugemix:20160717150004p:plainファイルのエンコードの種類は、ご利用の環境に依存する場合があるので、ご注意ください。

初めて使うAPIの場合、Javadocの有/無によって生産性が変わってくると僕は思いますので、直しました。皆さんの生産性もこれで上がればいいなと思います。

 

スプリントと振り返りについて思ったこと ~ウォーターフォールとアジャイルの議論より~

こちらのサイトで紹介されていた「スプリント」、「振り返り」の考え方を自分の置かれた状況で活かすと、長期的みて仕事の効率が上がるのではないかと考えたのでメモします。

blogs.msdn.microsoft.com

まず、このようなことを考えた経緯をまとめます。

 

ウォーターフォールアジャイル

6月21日(火)にJJUG会長の鈴木さんが主催されたワークショップに参加しました。

ita-ws.connpass.com

そこでは以下のような紹介をされていました。

 

アプローチの考え方の違い

このワークショップではそれぞれの方法論を、マネジメントの観点からそれらの違いについて説明されていました。

 私の理解を一言でまとめるとこんな感じです。

その理由は、感嘆するほど納得いくものでした。

 

ゴールまでが見通せるているなら、最初に計画を立てたほうが管理しやすいから。

一方で、見通しが立てにくい事柄に取り組まなければならないなら、見通しが立てにくいと失敗もしやすいので、それを見通しを立てやすいタスクまで分解して、その単位で計画的に進めていく方が成功しやすいから。

 

こんなブログに突っ込む人なんかいないでしょうけど、原理的な思想については、詳しくないので突っ込まれても困ってしまいます(笑)

今はこういう説明に納得しているというだけです。

 

マネジメントの観点

PDCAという言葉がありますが、鈴木さんはマネジメントの基本はこれだと仰っていました。

有期性のある活動(仕事)において、それがうまくいかない場合はこれのどれかが失敗しているということだと。

 

それぞれの方法論には粒度は違えどフェーズ(設計、製造、テストなど)があるので、フェーズごとにPDCAを実践する点においては本質的には違いはないんだなあと思いました。

おかれている状況によって、採用する仕事の管理方法が違うだけ。

 

方法論の目的、技法の適用シーンを理解することの大切さ

仕事を上手に進めるには、その仕事で採用する方法論の目的適用すると効果が上がる状況をきちんと理解して、採用するのが妥当だという鈴木さんの意見には私も賛成でした。

 

テストをされている方ならわかると思いますが、テスト方法論やテスト技法についても似たようなことが言えますよね。

例えば、(短絡的な例えですがー)設計書が無くて、テスト対象に対して深い知識やテストスキルが高い人がいるような状況なら探索的テストをやろうかとか-です。

 

効率的に仕事を進める為に

今の仕事は、開発以外にも見積や問合せへの応対など様々な作業があります。

色々な経緯から仕事量自体が去年より減ったのですが、正直もっと仕事をしたいと思っています。

こんな思いで悶々としていたときに、今の仕事をもっと早く終えられれば、同じ時間でもこなせる量は増えるよな-なんて思った訳です。

 

そこから自分の作業時間を測って自分を管理しようと考え始めました。

毎日の作業をログに残して、ログには作業時間を書きます。そうすれば自分の力量が見えるだろうと思ったわけです。

始めてから1ヶ月立つのですが、集計が大変で全然できていないのが現状でした。

 

スプリントと振り返り

そんな時に冒頭で紹介した記事を読んで、アジャイルプラクティスであるスプリントと振り返りを参考にしてみようと思いました。

 

幸いなことに、私はタスク管理表を付けているので、一定のスプリントで作業計画を立てることは出来そうです。タスクを細かい作業単位に落とし込むというところを今までやっていなかったので、ここを細分化して取り組んでみたいと思っています。

 

大変にならない程度にやってみて、スプリント終了時に振り返りをしてみたいと思います。

 

これで作業見積りの精度が徐々に上がっていけばよいですし、人に作業をお願いもしやすくなると思います。

 

状況を判断する力

私の場合は、このような仕事の仕方だったので適用できそうです。

しかし、既に仕事内容がマニュアル化されていて、その手順で最高の結果を最高のパフォーマンスで出せるのならそれでいいと思います。

私もそれに従います。

 

状況によって適切な方法を判断して、自分の力として利用できるように知識として持ってように常にアンテナを張っておきたいな、と思いました。