Photoruction工事中!

Photoructionの開発ブログです!

エレガントなIoUの計算方法

はじめに

こんにちは、AIエンジニアの志賀です。

最近はとっても暑い毎日が続いていますね。つい1ヶ月前と比べるとこんな暑さは信じられないですね。冬には「極寒より猛暑の方がマシ」と考えるのですが、やはりいざ夏になると「猛暑より極寒の方がマシ」と考えてしまいます。

最近、行動経済学に関連した本を読んだりするのですが、これもアンカリング効果とやらの所業なのでしょうか?

さて、今回はIoUの様々な計算方法の中でも、numpyのclip関数を使用したIoUの計算方法を紹介していきたいと思います。個人的には、最もスマートでエレガントだなあ。と思った計算方法だったので、この計算方法を紹介する次第です。

おさらい

IoUとは

IoUとは、Intersection over Unionの略で、2つの領域の重なり具合を示す指標となっております。

具体的な計算方法は、仮にAとBの領域があった場合に、AかつB / AまたはBとなります。

より詳細を知りたい方はこちらの記事を参照すると分かりやすいです。

 

参考図:

intersection = オレンジ部分

union = オレンジ部分 + 青部分



numpyのclip関数を使ったIoUの計算方法

numpyのclip関数とは

numpyのclip関数は、入力されたnumpy配列の各要素を指定された任意の値の範囲に収める加工を行う関数です。clip関数の第一引数にnumpy配列、第二, 第三引数にそれぞれ最小値、最大値を入力します。

以下、使用例になります。

x = np.arange(10)
print(x)
# [0 1 2 3 4 5 6 7 8 9]

print(np.clip(x, 3, 6))
# [3 3 3 3 4 5 6 6 6 6]

numpyのclip関数を使ってどのようにIoUを計算するか

clip関数は、IoUの計算の中でも、分子であるintersectionの計算に使用します。

具体的には、x, y座標のそれぞれにおいて、片方のbox1の最小値最大値を使って、もう片方のbox2に対してnp.clipを適用します。

このようにする事で、box1とbox2が重なる部分、つまりintersection領域のみが残るという具合です。

例えば、box1 = [0, 0, 10, 10], box2 = [5, 5, 13, 13]だった場合、

box1の最小値、最大値を使用したclip関数をbox2に適用してあげると次のようになります。

box1 = np.array([0, 0, 10, 10])
box2 = np.array([5, 5, 13, 13])
x_min, y_min, x_max, y_max = box1
# x軸方向にclip関数を適用
box2[0::2] = np.clip(box2[0::2], x_min, x_max)
print(box2)
# [ 5  5 10 13]

# y軸方向にclip関数を適用
box2[1::2] = np.clip(box2[0::2], y_min, y_max)
# intersectionの領域を獲得
print(box2)
# [ 5  5 10 10] (= intersectionの領域)

あとは intersectionの領域の面積(=intersection)の計算及びunionを計算してあげれば、IoUが求まります。

unionは、box1の面積 + box2の面積 - intersectionによって求まります。

実際のコード

以下実際のコードです。

より利便性を追求する為に、1つの領域(box)と他の複数の領域(other_boxes)のIoUsをまとめて計算します。

def calc_ious(box, other_boxes):
		eps=1e-5
    other_boxes = np.array(other_boxes).reshape(-1, 4)
		#intersectionsの計算
    other_boxes_cpy = np.copy(other_boxes)
    np.clip(other_boxes_cpy[:, 0::2], box[0], box[2], out=other_boxes_cpy[:, 0::2])
    np.clip(other_boxes_cpy[:, 1::2], box[1], box[3], out=other_boxes_cpy[:, 1::2])
    inters = (other_boxes_cpy[:, 2] - other_boxes_cpy[:, 0]) * (other_boxes_cpy[:, 3] - other_boxes_cpy[:, 1])
		#unionsの計算
		box_area = (box[2] - box[0]) * (box[3] - box[1])
    other_boxes_areas = (other_boxes[:, 2] - other_boxes[:, 0]) * (other_boxes[:, 3] - other_boxes[:, 1])
    unions = other_boxes_areas + box_area - inters
		#iousの計算
    ious = inters / (unions + eps)
    ious = ious.tolist()
    return ious

box = [5, 5, 12, 12]
other_boxes = [[5, 5, 13, 13], [10, 10, 30, 30]]
ious = calc_ious(box, other_boxes)
print(ious)
# [0.7656248803711124, 0.008988763842949127]

感想

個人的には、この計算方法を知った時はスパイファミリーのヘンダーソン先生並みに「エレガント!」と感動したのですが、如何だったでしょうか。中にはそんなの最初から知ってるよという方もいるかもしれませんが、温かい目で見て頂けると嬉しいです。笑

 

株式会社フォトラクションでは一緒に働く仲間を募集しています

WEBエンジニアからQAエンジニアへキャリアチェンジして良かったこと

こんにちは。

PhotoructionでQAエンジニアをしている内田です。

私はPhotoructionでWEBエンジニア→QAエンジニアとしてのキャリアをスタートさせました。

今回はWEBエンジニアを経てQAエンジニアになったことで、活かせた経験やよかったことをお話させてもらおうと思います。

 

QAエンジニアへキャリアチェンジしてよかったこと

  • 機能に詳しくなれる。サービスの全体像がわかる

前職でWEBエンジニアとして働いているときは、自分が開発した機能以外の機能を知る機会がありませんでした。当時は「そんなことしてる暇があったら早く機能実装してよ」的な圧がありました。もちろんPhotoructionのWEBチームはそんな圧は無いです!

私は全体像をとらえてから詳細部分を知っていくタイプなので、QAエンジニアとしてサービスの機能全てを把握できたのが大変うれしかったです。サービスに対しての愛着も湧きました。

 

  • コードを書きたいときに書ける

WEBエンジニアとして働いていたときは毎日プログラムを書いていました。今現在QAエンジニアとしてコードを書くことはほぼありません。E2Eテストの実装で書こうと思えば書けるし、書く量もある程度自分で調節できるのが素晴らしいなと思います。

 

  • 開発の全行程に関われる

要望が挙がってきてからUIが固まるまでのいわゆる上流工程からリリース完了までずっとプロジェクトに参加できます。UIがFIXする前の段階で、ユーザー目線になって考えたときの良い所や改善点を伝えることができます。

その会社の開発手法にもよるかもしれませんが、私がWEBエンジニアのときはガチガチのウォーターフォール型開発でしたために上流工程にはあまり参加できませんでした。

QAとなった今ではがっつり関わることができるので、良いプロダクトを自分で生み出せている感覚があり、リリース完了したときの達成感が大きいです。

 

  • 他チームとの会話ができる

前述でも書きましたが、WEBエンジニア時代は他部署との関わりがあまりありませんでした。QAエンジニアはサポートチーム、WEBエンジニア、モバイルエンジニア、PMと非常に関わる人が多いです。

コミュニケーション取りながら仕事するっていいですよね。一人じゃない感があります。

 

WEBエンジニアを経てQAエンジニアになってよかったこと

  • 開発用語がわかる

こちらは言わずもがなですね。ワーカー環境、ビルドなどなど、開発時のエンジニアから発せられる用語が理解できました。踏み込んだ質問もエンジニアにできたりするので、WEBエンジニア時代の経験が活きてると感じます。

 

  • 不具合が出そうな箇所が感覚でわかる

プログラムを書くエンジニアにはわかると思うのですが、自分が出した不具合って強烈に覚えてますよね(笑)トラウマレベルの不具合もあるのですが、過去自分が出した不具合を参考にして「ここも不具合出そうだな」というアンテナが立ちます。

そのアンテナをテストケース化して不具合を検出した経験もあります。地味に一番よかったと思えることです。

 

  • 開発エンジニアと深堀った会話ができる

不具合が出た時に、「なぜ発生したか」「どうやったら再発防止できるか」といった会話ができました。技術的な話が出た場合は深堀った質問もできました。サービス品質の向上につなげられたので良かったと思います。

以上が私のWEBエンジニアを経てQAエンジニアになって良かったことになります。

最後まで読んでいただき、ありがとうございました。

 

株式会社フォトラクションでは一緒に働く仲間を募集しています

 

フォトラクション(建設業界特化型のSaaS)のテスターって実際どうなの?

QAエンジニアの山本です。

「フォトラクションのテスターって実際どうなの?」という疑問をお持ちの方もいらっしゃるかと思うので、今日はそれについてQ&A形式で回答していこうと思います。

Q&A

Q:仕事内容の詳細について教えて下さい。

A:主に下記の仕事をして頂きます。

  • (案件の)総合テスト・機能テスト
  • (リリース前の)リグレッションテスト
  • テストで検出したバグに関するバグチケットの起票
  • 本番環境で検出したバグに関するバグチケットの起票
  • お客様からお問い合わせ頂いたバグの調査・バグチケットの起票
  • バグの改修確認


Q:残業はありますか?

A:基本的には、ありません。

※もし今日が期限のタスクが時間内に終わらなかった場合でも、他の人に引継ぎをして、定時退勤が出来ます

 

Q:体調不良等による急な欠勤は出来ますか?

A:はい。出来ます。

 

Q:フルリモートワークですか?

A:はい。フルリモートワークです。

 

Q:地方在住/地方へ移住したいです。

A:地方在住/地方へ移住したい方も積極採用中です。

 

Q:コミュニケーションはどうしていますか?
A:普段はSlackで業務連絡をし、会議はGoogle Meetで実施しています。

 

Q:強制参加のイベント等はありますか?

A:ありません。

イベント自体はたまに(年に数回程度)ありますが、任意参加です。

 

ーーー下記の質問はテスターさんに、直接ご回答頂きましたーーー

 

Q:社内の人間関係はどうですか?

A:皆さん親切丁寧で、分からないことも聞きやすい環境です。

おかげさまでストレスなく作業ができています。

(Iさん)

 

何か困ったことがあった時でも質問をすればすぐに対応してくれる等、優しい人が多いので働きやすい。

一方、業務がフルリモートなので深い人間関係の構築を図ろうとすると難しいということもある。

(Kさん)

 

わからないことは、すぐに聞ける環境であり、皆さん優しく教えてくださりますので、

人間関係は良好だと思いました。

(Yさん)

 

Q:応募する前と実際に働き始めてからのギャップはありますか?

A:テスターと聞くと、淡々とバグを見つける作業だと思っていましたが、いざやってみるとバグの原因調査、定期テスト、改修確認と様々な工程があり、やりがいのある仕事だと思いました。

(Iさん)

 

SlackというSNSツールで基本的に連絡を取り合うので、一緒に働いている人と顔を合わせる機会がないのでは?と考えていたのですが、週1でオンラインによる会議(作業の進捗確認等)があるので意外に顔を合わせる機会はあること。

(Kさん)

 

まとめ

ここまで、当社でテスターとして働く事の魅力についてお伝えしてきました。

もちろん当社はスタートアップなので課題は色々あります。

ただその課題を踏まえた上でも、私は当社で働く事に魅力を感じています。

それはネガティブな事でも率直に相談出来るメンバーがいるので、数年後必ずそれらの課題を解決出来ると信じているからです。

最後まで読んで頂き、ありがとうございました(^_^)!!

 

株式会社フォトラクションでは一緒に働く仲間を募集しています

スクラム開発始めました!!

はじめに

こんにちは!株式会社フォトラクションでWebエンジニアをしています南風原です。

早速ですが、タイトルにもある通り私たちテクノロジーサービス部は3月から本格的にスクラム開発を始めました!!👏👏👏

今回はスクラム導入にあたっての取り組みや導入後の経過などを私目線でまとめてみたのでぜひ最後まで読んでいただけると嬉しいです!

スクラム導入の背景

これまでウォーターフォールのようなフローで開発を行ってきたのですが様々な問題が発生するようになりました。

問題点の一部を挙げると以下のようなものがありました。

  • プロジェクトの規模が大きくなりリリースするまでの時間が長い
  • 改修による影響範囲が大きくなりがちであり工数が増える
  • プロジェクトごとにチームが結成されリリースしたら解散されるためチームとしてのノウハウの蓄積やコンセンサスを取りながらの開発がしにくい状態になっている
  • 上から降りてくる要件を作るといった状況が多く社内受託感が強い

このような問題点から開発体験がよろしくない状態にあり、開発チームとしてこの状況を改善していく必要があると考えました。

そこで、従来の開発体制を改善していくためにウォーターフォールのような開発からアジャイルな開発にシフトしていく取り組みを始めることになりました。

スクラム導入までの流れ

アジャイルな開発にしていこう!スクラム開発やるぞー!と言ったものの社内にそういったことに知見がある方が当時はいなかったため、アジャイルコーチとして永和システムマネジメントさんにサポートしてもらいながらスクラムへの移行を行なっていきました。

スクラム移行に向けて取り組んだこととしては以下になります。

  • 開発フローの現状把握と問題点の洗い出し
  • フォトラクションが望むアジャイルの進め方の提案と移行するにあたってのアクションの相談
  • プロダクトロードマップの作成とチーム体制の検討

スクラム開発スタート

3月から開発組織の構成をガラッと変更しスクラム開発を開始しました。

これまではWebグループ、モバイルグループといった技術領域でグループ分けをしていましたが、これからはプロダクトチーム軸でチームを作りそれぞれのチームに開発テーマがありチームドリブンで開発していくような組織に変更されました。

さらに、より良いスクラム開発を進めて行くために、各チームのスクラムマスターには認定スクラムマスター研修を受講してもらいました。(ありがたい👏)

スクラム導入後の現状

私が所属するチームでの話になりますが、実際にスクラムを導入してチーム開発を行なってきて2ヶ月くらい経ったので今の現状とこれからについて書いていこうと思います。

まず初めに、個人的な話からすると、私自身所属チームではスクラムマスターも担当させていただくことになりました。

ただ、スクラム初心者だったのでそもそもスクラムとはなんぞや?から勉強を始めました。

スクラムに関する勉強で取り組んだことは以下になります。

チームとしてもスクラム経験者が少なかったのでチーム内でもスクラムに関する勉強会を開催しました。

チームメンバー全員でスクラムに対しての疑問点やチームとしてどういうふうに進めて行くのがいいのかなど話し合う時間を作りました。

現状、スクラム開発を始めて2ヶ月ほど経過しましたがまだまだ手探りで進めているところもあり、ちゃんとスクラムとして運用できている状態かでいうとまだまだな部分もあります。

ただ、スクラム導入前よりもチームメンバー内でコミュニケーションを取って進めていく形が取れているので引き続きよりいい状態でチーム開発が行えるように取り組んでいきたいと思います。

今後の展望

私個人としては、スクラムマスターとしてまだまだ未熟な部分が多いので自分のチームがよりいい形でスクラム開発を行なっていけるように精進していきたいと思います。

方法としては、他チームのスクラムマスター同士での振り返りを通してチーム間の意見交換を行ったり、スクラムに関する情報のインプットを継続して行うのとそれをチームにも発信していけるようにしたいです。

開発組織全体でいうと、スクラムを導入してこれまでの開発体制を改善していきつつあるもののまだまだ改善するべき問題が多いです。その課題を開発組織一丸となって解決していき価値あるプロダクトをユーザーに提供し続けられる強い組織を作っていくためにも一人一人が自分にできること、チームに貢献できることは何かを常に考えて行動していくのが大事なのかなと思った次第です。

よりいい環境で、楽しく働き続けるためにも自分たちの手でどんどん改善していきたいものですね😉

以上、ざっくりした内容になりましたが、スクラム開発始めたよって話でした〜👏

最後まで読んでいただきありがとうございました!

株式会社フォトラクションでは一緒に働く仲間を募集しています

AWS Lambdaを変えてしまったかもしれないお話

PhotoructionのWebエンジニアの下川原です。

今回は、AWS Lambdaについて語ろうと思います!

 

関連ワード

  • Lambda
  • nodejs
  • sharp
  • 画像処理
  • 雑談

 

もくじ

 

1.AWS Lambdaが変わったこと

参考:https://aws.amazon.com/jp/blogs/aws/aws-lambda-now-supports-up-to-10-gb-ephemeral-storage/

Lambdaはもともと512MBのtmpが提供されていた。

しかし、2022/3/24にアップデートがされた。要約すると

Lambdaが提供するtmpを512MBから10GBまで増やせるよ!

※ただし512MB以上の容量追加は追加料金あるよ!

やったね!

2.Lambdaに何をしてしまったのか

'use strict';
const sharp = require('sharp');

exports.mainHandler = async (event, context, callback) => {
    let work_folder = createWorkDirectoryStructure();
    //画像をDLしてくる処理
    let src = getSourceData(event.data.bucket, event.data.image_path, work_folder);
    toProcessImage(src, work_folder, event.data.image_name);
    CleanupTempDirectory(work_folder);

    return true;
};

const toProcessImage = async (src, output_base_path, slice_file_base_name) => {
    let src_img = sharp(src);
    let tmp_path = path.join(output_base_path, slice_file_base_name);

    //切り取り処理 数字は適当
    await src_img.extract({
        left: 100,
        top: 200,
        width: 500,
        height: 500,
    })
        .toFile(tmp_path);//加工した画像を配置する処理
}

const createWorkDirectoryStructure = () => {
    let work_folder = path.join('/', 'tmp', 'work-' + shortid.generate());
    if (!fs.existsSync(work_folder)) {
        fs.mkdirSync(work_folder);
    }
    return work_folder;
}

const getSourceData = (bucket, key, directory) => {
    let file_extension = path.extname(key);
    let dst = path.join(directory, `src${file_extension}`);
    return downloadFile(bucket, key, dst);
}
//ディレクトリを削除する処理
const CleanupTempDirectory = (dir) => {
    if (fs.existsSync(dir)) {
        fs.rmdir(dir, {"recursive": true}, (error) => {
            if (error) {
                console.log("clean up progress: " + error);
            }
        });
        console.log("Cleanup complete");
    }
}

こんなように、適当に画像を切り出す処理があったとする。

AWSコンソールから、

テスト実行・・・成功

テスト実行・・・成功

テスト実行・・・失敗

エラー:No space left on device

短い期間、ほぼ連続で実行するとエラーになる

なぜ?

容量不足と出ているなら、この処理のどれかが悪さをしているのだろう。

・画像をDLしてくる処理

・加工した画像を配置する処理

ディレクトリを削除する処理

Lambdaコンテナの中で何がおきてるか、確認するのが早いだろう(Linuxのコマンドが使えてよかった・・)

処理のはじめと終わりに以下のコードを追加

console.log(execSync("df -h").toString());
console.log(execSync("du -h /tmp").toString());

コード挿入後の実行ログ

1回目テスト実行・・・成功

INFO	Filesystem                                                       Size  Used Avail Use% Mounted on
/mnt/root-rw/opt/amazon/asc/worker/tasks/rtfs/nodejs14.x-amzn-2  9.8G  8.8G  947M  91% /
/dev/vdb                                                         1.5G   14M  1.4G   1% /dev
/dev/vdd                                                         526M  872K  514M   1% /tmp
/dev/root                                                        9.8G  8.8G  947M  91% /etc/passwd
/dev/vdc                                                         9.5M  9.5M     0 100% /opt
INFO 4.0K	/tmp
INFO Cleanup complete
INFO Filesystem                                                       Size  Used Avail Use% Mounted on
/mnt/root-rw/opt/amazon/asc/worker/tasks/rtfs/nodejs14.x-amzn-2  9.8G  8.8G  947M  91% /
/dev/vdb                                                         1.5G   14M  1.4G   1% /dev
/dev/vdd                                                         526M  178M  337M  35% /tmp
/dev/root                                                        9.8G  8.8G  947M  91% /etc/passwd
/dev/vdc  
INFO 4.0K	/tmp
2.7M	/tmp

2回目テスト実行・・・成功

INFO	Filesystem                                                       Size  Used Avail Use% Mounted on
/mnt/root-rw/opt/amazon/asc/worker/tasks/rtfs/nodejs14.x-amzn-2  9.8G  8.8G  947M  91% /
/dev/vdb                                                         1.5G   14M  1.4G   1% /dev
/dev/vdd                                                         526M  178M  337M  35% /tmp
/dev/root                                                        9.8G  8.8G  947M  91% /etc/passwd
/dev/vdc                                                         9.5M  9.5M     0 100% /opt
INFO 4.0K	/tmp
INFO Cleanup complete
INFO Filesystem                                                       Size  Used Avail Use% Mounted on
/mnt/root-rw/opt/amazon/asc/worker/tasks/rtfs/nodejs14.x-amzn-2  9.8G  8.8G  947M  91% /
/dev/vdb                                                         1.5G   14M  1.4G   1% /dev
/dev/vdd                                                         526M  355M  160M  70% /tmp
/dev/root                                                        9.8G  8.8G  947M  91% /etc/passwd
/dev/vdc  
INFO 4.0K	/tmp
2.7M	/tmp

3回目テスト実行・・・失敗

INFO	Filesystem                                                       Size  Used Avail Use% Mounted on
/mnt/root-rw/opt/amazon/asc/worker/tasks/rtfs/nodejs14.x-amzn-2  9.8G  8.8G  947M  91% /
/dev/vdb                                                         1.5G   14M  1.4G   1% /dev
/dev/vdd                                                         526M  355M  160M  70% /tmp
/dev/root                                                        9.8G  8.8G  947M  91% /etc/passwd
/dev/vdc                                                         9.5M  9.5M     0 100% /opt
INFO 4.0K	/tmp
INFO Cleanup complete
INFO Filesystem                                                       Size  Used Avail Use% Mounted on
/mnt/root-rw/opt/amazon/asc/worker/tasks/rtfs/nodejs14.x-amzn-2  9.8G  8.8G  947M  91% /
/dev/vdb                                                         1.5G   14M  1.4G   1% /dev
/dev/vdd                                                         526M  512M  2.4M 100% /tmp
/dev/root                                                        9.8G  8.8G  947M  91% /etc/passwd
/dev/vdc  
INFO 4.0K	/tmp
2.7M	/tmp

順調に増えてる・・・

画像はそこまでインパクトは無い・・・

作業ディレクトリはエラー無くしっかり消せている・・・

・画像をDLしてくる処理

・加工した画像を配置する処理

ディレクトリを削除する処理

    //切り取り処理 数字は適当
    await src_img.extract({
        left: 100,
        top: 200,
        width: 500,
        height: 500,
    })
        .toFile(tmp_path);//加工した画像を配置する処理

どうやら、toFile時に

関数とは違う実行ユーザーでファイルが置かれてしまうらしい

lrwx------ 1 sbx_user1051 990 64 Dec  3 01:43 24 -> /tmp/vips-0-3816661850.v (deleted)
lrwx------ 1 sbx_user1051 990 64 Dec  3 01:43 25 -> /tmp/vips-1-2724960011.v (deleted)
lrwx------ 1 sbx_user1051 990 64 Dec  3 01:43 26 -> /tmp/vips-2-485543279.v (deleted)
lrwx------ 1 sbx_user1051 990 64 Dec  3 01:43 27 -> /tmp/vips-3-930892267.v (deleted)

どおりで、/tmp配下に存在しない”ように”見えてしまっていたわけ

3.解決方法

では、上記の問題をどう解決したか?

ファイルを開く時に、メモリ経由かディスク経由かを判定するために

サイズを指定するパラメータ(VIPS_DISC_THRESHOLD)があり、

これを適切に設定しないと、ストレージが枯渇してしまう問題を見つけた。

https://github.com/lovell/sharp/issues/707

https://github.com/lovell/sharp/issues/1851

つまり、VIPS_DISC_THRESHOLDの設定を極端に少なくすれば常にメモリ経由で処理を継続してくれるというのだ。

Lambdaの環境変数に次のように追加することで設定可能

VIPS_DISC_THRESHOLD=10M

すると何回連続して実行を行っても、問題がおきることは無くなった。

4.さいごに

このような問題を発見、解決した数日後に「tmpを拡張可能にしたよ!」の記事が・・・。

さすがに数日で対応したわけは無いと思う、自由に使えるtmp容量を増やしてほしいという声は、

LambdaでAWS EFSを活用する記事をみると前々から需要があったのだろう。

気軽にtmpを拡張することができるので、ディスク上で操作する幅が広がったLambda

最後に改めて紹介しよう。

https://aws.amazon.com/jp/blogs/aws/aws-lambda-now-supports-up-to-10-gb-ephemeral-storage/

 

株式会社フォトラクションでは一緒に働く仲間を募集しています

「工数見積」を受け取る側のマインドの話

はじめに

おはようございます。PMグループの神澤です。

今回は、プロジェクトを進める上で欠かせない「工数見積」の受け取り方について語ろうと思います。

今回のテーマ

工数見積は、簡単に言えば「どれくらいの期間でリリースできるか」を考えるための要素です。

プロダクトを販売する企業の人であれば、自社が作るプロダクトがいつ進化してユーザーに提供され始めるかは、誰しもが気になる点だと思います。

ただ、Amazonの配達時刻のような、想定外の事が無ければ予定通り行きます、といった期待感と異なり、多くの人は一度はリリース延期というイベントを経験していると思います。

ここでは、リリース日を決めるための内訳、工数見積に焦点を当てて、どのような要素が含まれるかを説明します。

工数見積に関係する人

プロダクトの開発の流れは、大きくは「要求→設計→開発→リリース」という形です。

この開発の流れに関わる人は、ビジネス、PM、エンジニアが主となり、デザイナー、QA、クライアント、といった関係者がいます。

一つのプロジェクトに対して、関係者が多くなるほど、「専門知識」や「把握情報量」に差が出ます。逆にいうと、開発の仕方を詳しく知らない人、運用を詳しく知らない人も発生します。(そのため関係者全員をチームとして考え、補いながら専門分野の役割分担をして開発を行います)

この「関係者が多くなるほど」という点が重要です。

限りなく少人数なチームであれば、コミュニケーションロスは起きづらく、どこまでどのように分からないのか、という温度感が理解しやすく、結果、工数見積もその内訳に対する期待感がズレにくいです。

逆に、関係者(開発チーム外だけでなく、開発チーム内メンバーも含む)が増えれば増えるほど、把握情報量を全員が100%持つ事が難しくなり、コミュニケーションによる伝達が難しくなります。

では、このコミュニケーションロスの内容にはどのような事例があるかを挙げていきます。

受け取り手の期待ズレ

  • 開発者は、全ての開発を事前に設計できるとは限らない(知識や経験の期待ズレ)
  • 開発者は、自分の技量を正確に把握しているとは限らない(=1日で出来るかという予測の難しさ)
  • 要件を決める人(PM等)は、要求を達成するための項目洗い出しを網羅できているとは限らない
  • 要求する人は、相手に全てを伝え切れているとは限らない

見積側の技量とは異なる問題

  • 要件が漏れているとは、予想する対象が存在していないということ(=見積項目抜け)
  • 要件が期待と異なっていると「訂正」と「再開発」という作業が生まれる
  • 要件が曖昧だと、実際の作業内容も曖昧となる。曖昧な箇所には、予想さえ出来なかった「やるべきだったタスク」が含まれる

じゃあどんなことに気を付ければいいんだろうね

工数見積」の捉え方には難しさがあり、その内容をコミュニケーションロスの具体例を使って一部書いてみました。

ではどうするか。全ての要件を完璧にすれば問題ない、と言ってしまえば、それも選択肢としてありますが、現実は非常に難しいです。

見積内容の認識齟齬以外にも、テキストの用語が相手に伝わるか、背景理解に差があるか、十分に内容把握する時間的人的余裕があるか、等、懸念すべき事は多くあり、辞書のような仕様書にも、街宣広告のような洗練されたテキストにも、万能な価値はありません。

私が思う重要な点は、関係者同士の「相互理解」です。

ビジネス側にも開発側にも、「専門知識」があり「把握情報量」があります。関係者を各専門家として対等に問題に向き合い、チームとしての調和が必要だと考えます。

業務上のメンバーは、言ってしまえば寄せ集めのメンバーとなる事が多いです。スポーツでいうと近所の人を集めた草野球や、偶然同じ学校にいた部活動のような状態です。プロチームのようにドラフトで人を集める手法もありますが、どの企業でもそれが可能とは限りません。

このような状態で考えるべきは、「このチームで出来る最善の策は何か」を「考え続ける」ことだと思います。

上記の箇条書きは、「あの人なら出来ると思ってた」「自分なら出来ると思ってた」というマインドだと特に起こりやすいと思っています。実際には誰しも不完全な点はあり、得意だから全能ということはなく、だからこそ集団で物事に当たることに、価値があると思っています。

工数見積」(だけに限る話ではありませんが)でも、工数を計算する上での内訳内容や、どのような人が考えたか、そのシチュエーションや環境はどうだったか、を全員が考慮し、今いる人が出来る最大限のパフォーマンスを出そうというマインドを持っていられると、自然と把握情報量の差異が減り、徐々に信頼できる工数の、算出が可能、もしくは受け取り方が可能となるかなと思います。

あとがき

私はブログのような形で長文を書くことが苦手なので、お見苦しい点もあるかと思います。今後の課題です。

ちなみに、フォトラクションでは「あの人がやってくれるから」という他者頼りなマインドを持つ人がおらず、常に課題を見つけ解決していきたいと考える人が多いため、上記のような問題に直接ぶつかった事はないです。可能性の話や懸念の検討の際に出たものをメモしていた内容となります。

今後もフォトラクションのチームやメンバーが進化していくことで、更に細かく本質的な課題にぶつかっていく機会があると思うので、その際にはまたこのような形で共有が出来ればと思います。

 

株式会社フォトラクションでは一緒に働く仲間を募集しています

新規プロダクト開発におけるPMの取組み

フォトラクションでプロダクトマネージャー(PM)をしています千葉です。

3月から新規プロダクトの担当になりました。

初めて携わるプロダクトのためサービス内容や社内の運用体制などわからないことばかり・・・。

そんな状況から開発する機能を具体化するまでの取組みについて振り返ってみました。

目次


すぐに取り組んだこと


まずはプロジェクトの現状把握からです。次のことがわかりました。

  • 顧客の課題・サービスの問題点は明らかになっている。
  • 事業戦略には「○○月には使える状態にする」という開発の大まかな目標は描かれている。
  • 画面イメージや要件定義書など開発するものを具体的に示すものはまだない。

なのでプロダクトを通して顧客をどのような姿にしたいのかと、そしてそれを実現するために開発するものを決めることから着手しました。

取組み①ターゲットユーザーとフォトラクションの強みを整理


私が担当するプロダクトは初期フェーズなので、狙いたいユーザー層に価値をしっかり提供することが大事だと考えました。そこで、事業戦略・ビジネス戦略をよく理解し、プロダクトの位置づけを明確にしました。それからターゲットユーザーやフォトラクションの強みを整理していきました。

取組み②顧客の声を聴く・ニーズを理解する


続いて顧客ニーズを明らかにするために顧客の声を聞くことにしました。フォトラクションは多くの建設会社と定例を実施しており、ユーザーから率直な意見を聞く機会に恵まれています。

ヒアリングを通して自分の想像していた業務以外にも手間がかかっている現状を知ることができました。顧客の言葉を紐解きながら潜在化する顧客ニーズが少しずつ見えてきた気がします。

やはり誰のフィルターもかかっていない1次情報を見ることの大切さを改めて感じました。

取組み③顧客ニーズから顧客の理想像を具体化


顧客のニーズの実現には、多角的な目線でプロダクトを設計することが大切だと考えています。

そのため、顧客ニーズを整理した後、顧客をどのような状態にしたいのか、どのようなユーザー体験(UX)が良いのかUIデザイナーと時間をかけて議論しました。

初期段階の議論は、具体的なUIなどはまだないので、空中戦になりがちでした。

そこで具体的なアイディアを持ち寄ることで認識を合わせ、少しずつ目線を合わせていきました。

参考までに、今回はアイディア出しでmiroを活用しました。業務フローや考え方の整理・可視化に使えるので描画ツールはとても有効でした!

f:id:photoruction_tech_blog:20220404102543p:plain


これから

現在は理想のUXを機能要件に落とし込み、機能の設計を行っています。WebエンジニアやQAエンジニアもうすぐ合流していよいよプロジェクトが本格的に稼働します。

今後チーム開発・スクラムの導入により、ノウハウの蓄積やニーズへの柔軟かつ即応性が高い開発体制も構築していけるようになるでしょう。

まだまだ一歩目を踏み出したばかりのプロジェクトですが、ニーズを叶えるプロダクトを実現できるように一歩一歩前進していければと思っています。

建設業は2024年労働時間の上限規制を控え、生産性向上が急務となっています。テクノロジーで産業を変えていきたい方、ニーズを模索しながら実行してくプロダクト作りに共感や面白みを感じてくれる方、ぜひお待ちしております!

株式会社フォトラクションでは一緒に働く仲間を募集しています