受託開発補佐のアルバイト:9月度業務日誌

就労条件

 就労条件は以下の通り。

  • 業務時間は月に50時間まで。
  • 時給は3,000円。
  • シフトは自由。月に50時間を、平日の9~19時であれば自由に割り振ってヨシ。
  • 契約形態は業務委託。

 2025年8月の「業務改善のアルバイト」でのムーヴが評価されて、同じ会社の別部門から仕事をいただけた。「いい成果を出せると次の仕事に繋がる」ということを実感した。

 まぁとはいえ、収入も労働時間もこれまでのヤツで満足してたが、契約は3ヵ月更新なので「いつ仕事がなくなるかわからない」ということを考えると、稼げるときに稼いでおくというムーヴは必要か。

業務日誌

2025年9月20日

契約総合時間
50時間
累計実働時間
34時間
本日実働時間
4時間
  • 引き続き「システムの利用率向上のためのムーヴ」をやった。具体的には資料作りと呼びかけである。
  • しかし、「モノを作って読んでもらう」ってのじゃチームは動かないようなので、来月は個別面談を仕掛けていこうかと思う。
  • 「給与計算スプレッドシート」については、一旦は不要なデータをカットしてみてシート自体を軽くする方法をやってみた。こちらも担当者からのフィードバック待ちである。まぁ待つのには慣れてきたので問題ない。

2025年9月18日

契約総合時間
50時間
累計実働時間
30時間
本日実働時間
3時間
  • 「システムの利用率向上」のために、現状の利用率と「だれがどうすればいいのか」という具体案を資料にまとめてチームに展開した。
  • また、別件で「給与計算に使っているスプレッドシートが重くて使えない」という課題をもらったので、そちらに着手した。
  • しかし、そういう大事なデータはスプレッドシートで運用すべきじゃないと思うんだが。。。

2025年9月19日

契約総合時間
50時間
累計実働時間
29.5時間
本日実働時間
6時間
  • 「できそうな一般的な動作確認とセキュリティ診断」を元にPMと打ち合わせMTGを実施した。
  • 上記の項目について説明して、それで問題なさそうだったので、それを実際にやるにあたって、システムを調査しながら工数見積もりをやった。

2025年9月18日

契約総合時間
50時間
累計実働時間
23.5時間
本日実働時間
6時間
  • 「お客さんの知り合いが作ったシステム」を見せてもらって、その上で「できそうな一般的な動作確認とセキュリティ診断」をまとめて、todoとした。
  • 関係者が増えたことで、質問事項が発生すると、筆者=>PM=>お客さん=>開発者、という流れで伝言ゲームが発生するので、レスポンスの都合がだいぶ悪くなった。

2025年9月16日

契約総合時間
50時間
累計実働時間
17.5時間
本日実働時間
6時間
  • 前回からさらに話が変わり、「システムの追加開発と運用保守はお客さんの知り合いがやる」ということになった。
  • そうするにあたっては、システムのソースコードや動作環境は一切明かさないということになった。
  • その上でこちらがやることは、ブラックボックステストでのセキュリティ診断と動作確認ということになった。
  • これをやる意味については正直よくわからないが、お望みならやるとする。

2025年9月12日

契約総合時間
50時間
累計実働時間
11.5時間
本日実働時間
4時間
  • 前回までの話し合いから一転して、「お客さんの知り合い」が似たようなシステムをソロで開発しているらしく、「それを元に機能追加や運用保守をやってもらいたい」という依頼に変わった。
  • まぁフルスクラッチは厳しいと思ってたので、それはそれでよし。
  • まだそのシステムを触っていない段階だが、こちらでシステムの運用保守をやる場合にどういうtodoがあるかと、一般的な業務システムにおける工数を概算で見積もってPMに提出した。

2025年9月9日

契約総合時間
50時間
累計実働時間
6.5時間
本日実働時間
4時間
  • 前回の「欲しい機能全部盛りのリスト」眺めつつ、PMと現実的な工数だったり、実装難易度だったりを話し合った。
  • その一環として、とりあえず、真似して作りたい今使っているSaaSを見せてもらうことにした。
  • 当然、すでに稼働しているSaaSなのでいろいろと「すごい」わけだが、これをフルスクラッチで、しかも開発リソースが少ない我々で対応するのはだいぶ厳しい感じがした。

2025年9月8日

契約総合時間
50時間
累計実働時間
2.5時間
本日実働時間
2.5時間
  • オンボードMTGで「現在のお客さん」に関する情報を教えてもらった。
  • どうやら、現在利用している「チャットを中心とした業務システムのSaaS」の利用料と機能に不満があるらしく、自社で内製化して課題を解決させたい、というモチベーションを持ってるらしい。
  • 開発リストを見てみると、実装コスト度外視のサービス開発のローンチの時あるあるの「欲しい機能全部盛り」だった。
  • こういうのはいたるところで起きているんだなぁと思った。

コメント