私たちのお仕事についてその2 -astah*開発メンバーの業務-

こんにちは、astah*開発チームの『りりぃ』です。
前回の記事『私たちのお仕事についてその1 -サポート業務-』は読んでいただけたでしょうか？
今回も私のお仕事についてのお話しです。

前回、サポートメンバーはastah*を開発する人と次期製品を開発する人のお仕事であると説明しました。私はサポートメンバー兼astah*を開発する人に当たります。『通常業務』は何をしているかをステートマシン図で見てみましょう。

通常業務を行っているときはまずかんばんを見て、自分が何をしなくてはいけないのかを確認します。かんばんは、過去にはアナログのかんばんやTrelloを利用していましたが、今はWaffleを使っています。こんなのです。

ステートマシン図「astah*を開発する人の業務の状態遷移」を見てください。最初は通常業務中の作業内容候補確認中です。

図には一応描いたたんですが、優先業務ありやリリース作業期間内である場合の話はスキップします。

まずかんばんのReadyの列を見て、自分が過去に修正したプルリクエスト（以下PR）がないか確認します。あればそれはreopen扱いになっているPRです。issueの状態をIn Progressにして問題を修正し（ステートマシン図での状態は開発中）、PRをAcceptingにします（このPRがアクセプト待ち扱いになります）。ステートマシン図の作業内容候補確認中に戻ります。

次にかんばんのAcceptingの列を見ます。自分以外の人が開発したPRがあればアクセプト待ちなので、それをアクセプトします（ステートマシン図での状態はアクセプト中）。問題があればPRに指摘事項を記入し、Readyに移動します（このPRがreopen扱いになります）。問題がなければPRを受け入れ、issueを閉じます。ステートマシン図の作業内容候補確認中に戻ります。

かんばんにreopen扱いのものもアクセプト待ちのものもなくなれば、Readyにあるだれも手を付けていない新しいissueの状態をIn Progressにして開発を開始します（ステートマシン図での状態は開発中）。開発が済めばPRをAcceptingにします（このPRがアクセプト待ち扱いになります）。

通常業務中に問い合わせが来た場合、サポート業務を行わなくてはいけない場合があります（詳しくは私たちのお仕事についてその1 -サポート業務-を参照）。その場合は通常業務中のどの子状態だったとしても、サポートが終了すればその状態から再開されます。

新しいissueは、プロダクトオーナーが適宜かんばんのReadyに追加しています。

開発のやり方は、ツールのアップデート等やメンバーの変更によって適宜変更されていますが、大筋は変わっていません。このやり方は、如何に効率よく製品の品質を上げるかということに特化していると思います。利点は下記だと思います。

誰かがいちいち指示を出さなくても作業できる
自分がやりやすい仕事を選べる
開発メンバーが休んだり、メンバーを増員したり等にも対応しやすい
開発者とアクセプターが違うので問題が見つかりやすい
悪いところをPRで指摘することでメンバー間で知見が溜まる
品質を十分に高めてから修正が製品に取り込まれる

開発メンバーが急に風邪で休んだり、大雪で仕事ができなかったりしても、仕事ができるメンバーで開発やサポートは進められます。私は体がそんなに強くはないので時短勤務していたこともあるし、急に入院して1週間仕事を休んでしまったこともありますが、このやり方のおかげで安心して療養できました。
全てを開発メンバーの知見や経験に頼るのはよくありませんが、製品の開発にはそれがあればあるほど有利です。私自身は良いエンジニアかはわかりませんが、私もastah*の開発に携わって長くなり、開発の腕もアクセプトの腕も格段に上がったという自覚があります。
私は1年前から家庭の都合で県外に引っ越してしまったのですが、ありがたいことに会社を辞めることなく自宅で仕事をしており、このやり方のおかげで、引き続き知見を活かせています。いろんな働き方ができるのもastah*の品質向上に一役買ていると思っています。

ありがたいことに、最新版の7.2では図要素をまとめて移動の新ロジックを開発させていただきました。今も次期バージョンに向けて新しい機能を実装しているので楽しみにしててくださいね！