Funny Walking

他人の人生を掘り下げる

【Redmineが少しわかる】業務の振り返り - 2019/07 3回目

前回の課題の状況

ActiveRecord単体で取り出すとデータがYAML形式になるデータというのは、serializeされているモデルだということが分かった。 ただし、こうするとSQLで直接データを操作できないし、格納するデータのデータ型を保証できないし、外部キー制約を付けることもできない。1NF(1つの属性には1つの情報)違反である。こんな記事もある。

qiita.com

今週やったこと

RedmineのBacklogsプラグインで、ストーリーポイントの値を選択リストで制限できる機能というのがあり、ここには任意の値を入力することができる。

前回のインプリメントでストーリーポイントの値はフィボナッチ数列の値で固定化(1,2,3,5,8)させたのだが、顧客の業務がまだ完全にスクラムに追い付いていないというので、任意の値を選択できるように機能を戻した。

スクラムにおいて、ストーリーポイントは、フィボナッチ数列の値を使うことが望ましいとされる。なぜなら、見積もりの精度は見積もり工数が大きくなるにつれて粗くなるという一般原則があるため、見積もり工数が大きくなったらストーリーそのものを細分化するなりしないと予定通りに進まなくなるからだ。

ストーリーポイントはベロシティ(生産パフォーマンス)を測るためのモノなので、工数管理として使うものではない。だから正確な工数を出すことより、見積もりとの乖離がどの程度発生したかを見て、どう見積もり精度を高めてゆくかが重要なのだと教わった。

www.ryuzee.com

現場では、ストーリーポイントは1=1日として捉えていた。そのほうが管理しやすいからだという。

ちなみに見積もりには、プランニングポーカーやファイブフィンガーを使うものなんだとカイゼン・ジャーニーには書かれていたが、今回のチームでは自分が経験不足なこともあり、ストーリーポイントの設定は現場担当者にまだやってもらっている。

codezine.jp

codezine.jp

新しく出てきた課題

チームメンバーとのやりとりについて、リモートが多いことがまだ慣れない。 現場に参画して3週目となるが、まともに対面で話したのが3日もない状態で、あとはフルリモートというのがどうしても慣れない。相手の言葉をうまく理解できないし、違和感があっても言葉にして発言できない、ということが続いている。

リモートワークのツールとしては、Microsoft Teamsをビデオチャット、画面共有として使い、進捗や課題の確認はRedmineのBacklogsプラグインを拡張したスクラム開発ツールを使ってやりとりしている。

だが先週の水曜あたりから、徐々にツールの使い方にも慣れてきた。とりあえず、チケットを切ることが習慣になった。

が、ツールを使うことに慣れても、スクラム開発支援ツールをスクラムで開発するという現場の目標に対しては、まだまだ改善の余地がある。ツールを使いこなすだけでは不十分で、スクラム開発ならではの密なコミュニケーションが生み出す化学反応をこそ楽しみたいのだが、まだまだそこまで到達していない。

工夫したことについて

  • 業務カテゴリ
    • Tech
      • VirtualBox仮想環境でデバッグするのは大変。画面ロックをオフにして、不要なオペレーションを少しでも少なくできるようにした。
      • コードコメントを書くとき、目的と入出力データの形式を書くようにした。設計書がないので、コードを読みやすくするため。
      • Railsの動きを把握しやすくするため、Rails.loggerを使ってデバッグメッセージを挿入し、処理の動きを把握しやすくした。
      • Redmineのコントローラ、とくにアプリ共通のアプリケーションコントローラに定義されているauthorizeメソッドを閲覧し、機能の基本的な流れを見るように努めた。
      • Redmineプラグインガイドを参照し、プラグイン共通の設定を保持するSettingモデルの存在とデータの表示方法を知った。
    • Human
      • 文化の違いを知るために、相手の話は遮らずに黙って聞き、相槌をうち、要約して反応を返した。
      • 相手への感謝を示すようにした。自分は初めての現場で馴れないが、業務にもチームにも馴れてない自分の相手をする受け入れ担当者も大変だろう。「ありがとうございます」と適宜言葉にするようにした。
      • 病気、体調不良が発生したときなど、「大丈夫ですか?」と声かけをするようにした。また、なるべく雑談を入れるようにし、なんでもない発言をしても大丈夫なんだという雰囲気を作るように努めた。
  • キャリアカテゴリ
    • SQLアンチパターンLinuxコンテナ技術、Rails RSpec、一般システム思考入門など、書籍を参照しながら手も動かしつつ、バックエンドエンジニアとしての一般教養を取得するよう努めた。SQLアンチパターンのサンプルスクリプトの誤植は、オライリーのサポートサイトへ報告した。
    • メルカリのエンジニア事業説明会へ参加し、自分のやりたいことを企業がどのような形で実現しているか調査を行った。

      • mercari.connpass.com
        • 興味深かったのは、メルカリほどの企業でも、モダン開発への対応が始まったのはここ一年ほどの間なのだということだ。しかし、エンジニア、営業、事務、など、多様な人たちが働き、しかも外国籍の方が5割を超える組織を誘導してゆくことは、それだけ大変なことなのだろうなと思った(このイベントは社外秘が多かったため、ブログでのアウトプットは控えようと思う)
    • いくつかの企業様へ、自身のキャリアと、求めてるエンジニア像とのギャップ分析を行った。
    • モダンインフラをキャッチアップし、エンジニアの仕事環境を効率化するために、CI/CDの調査・学習を開始した。
    • 技術書同人誌博覧会へ参加し、キャリアについての考え方および、メール技術についての技術書を購入し、勉強会でお世話になった方へご挨拶をした。
    • 日記をGitHubからGoogleカレンダーに移行した。日記は見返してこそ価値があるので、見返しやすいGoogleカレンダーで管理することにした。日記は「不安ワーク」と称し、不安なことを毎日5分くらい思いつくかぎり書きだすようにした。