業務の振り返り - 2019/07 1回目
結論
- Keep
- Problem
- リモート対応が初めてで馴れない
- テスト自動化をやることが顧客のどんな問題を解決するか明確でない
- Try
- 現場担当、顧客から、実装の経緯、開発の経緯について、質問の回数を増やす
- 現場担当、顧客の話を聞く。「なぜそうなったのか、その状態を改善したがっているか」について特に詳しく聞く。
本文
7月から新しい現場に入り、新しい技術を学ぶ日々を過ごしている。
扱うサービスはRedmine。プラグインを入れてスクラム開発が出来るようにするのだが、このプラグインの拡張開発を担当している。
顧客は開発プロセス支援を業務パッケージとして所有しており、このノウハウをツールという形で提供しているというわけだ。
よって、業務知識とは別に以下の知識が必要となる。
Redmineについては、現場担当者とコミュニケーションしながら操作して覚えつつ、操作ログを見てBacklogsプラグインの流れを追う、といったやり方で進めている。
Redmineのプラグインは、Remineの提供している機能を拡張するものだ。 よって、実装としてはDecoratorパターンが使われているのだと現場担当者に教えてもらった。
12. Decorator パターン | TECHSCORE(テックスコア)
上記の記事はJavaで解説されたものであるが、RedmineはRailsで実装されているのでプログラムの構成はだいぶ違った。 具体的には、拡張機能のmoduleはRedmineの基本モジュールをincludeし、includeされたタイミングでinclude元に定義されているメソッドをalias_method_chainで機能拡張するように実装されている。alias_method_chainはRails5では非推奨となるようだ。
BacklogsプラグインはRails3の記法が多い（before_filterなど）ので、記法について調べなければならないことも頭を悩ませている。環境だけでも、以下のように異なっている。
現場ではあまり単体テストを重視していないようだが、これはテストデータを作るのが単純に複雑なので、Redmineを実際に操作してデータを作るほうが効率的だということが挙げられる。こちらについては、徐々にCapybaraやSelenium単体のモジュールを使ったテストで自動化してゆけたら良いな、と思っている。
ただし、現場のこれまでの開発経緯を知らないままにプロセスを導入するのは危険なので、まずは現場担当者のこれまでの経緯をリサーチしなければならない。
そうしなければ、「何が効率的なこと」なのかが分からない。 本当にテストを自動化することを求めているのか？それよりも優先されることがあるのでは？その優先されることが、テストを自動化することで解決できるのかどうか？
つまり、「相手は何を課題と感じていて、何が解決されることを望んでいるのか」について具体的に考えることが必要だと思う。
自身のパフォーマンスを上げるために知識をキャッチアップするのと同時に、組織のパフォーマンスを上げるためにこれまでの経緯とステークホルダーの求めていることを調査する。