2022年も残すところあと僅か、大晦日にこの記事を書いているツナかふぇです。
今年はフリーランスになって初めて人間関係に悩まされた1年でもありました。それを踏まえて、1月~12月の振り返りをしていこうと思います。
昨年の5月からスタートした案件も残りわずか、結合テストフェーズで出た不具合を改修していきます。
昨年の10月に山場が収束したこともあり、平穏な空気が流れています。
このまま同プロジェクトの保守担当になるのは嫌でしたし、「そろそろ別の案件に移ろうかなぁ」と考え出す時期でもありました。
客先要望による機能追加対応を行っていましたが、仕様がブレにブレて、結局なかったことに。もちろん時間換算でお金は貰いましたが、2週間の作業がお蔵入りになったのは結構ショックでした。
いつか日の目を見るかも…と使わなくなった機能をローカルに退避させておくのは、エンジニアあるあるだと思います。結果、案件撤退まで使う事は無かった、というのがほとんどだったりしますが…。
プロジェクトはエンドユーザーの運用試験フェーズに入り、プロジェクトルームも解散のお触れが出ます。
ここらが潮時か？ という事でマネージャーに退団の意思を伝えると、「来月から別のプロジェクトが立ち上がる予定であり、単価も○万円上乗せするから残って欲しい」と言われました。前回プロジェクトと同様、準テックリード待遇です。
技術的には前プロジェクトから目新しいものは無く、正直悩みました。
が、金額の上がり幅がソコソコあり、かつ要件定義フェーズから参画可能であることから、上流工程の経験を積む為にこの提案を承諾する事にしました。
こうして私は「炎上しそうだったプロジェクトを収め切った」実績を得、同現場の別プロジェクトに参加する運びとなりました。
4月頭から、さっそく別プロジェクトが動き始めます。最初の布陣はPM1名、要件定義に2名+私、DB設計に1名、アプリケーション設計に私、mock作成に私+1名、インフラに1名という省エネ体制。色々なことに首を突っ込みまぁ最初はこんなもんか？ と思いながら4月はゆる~くスタートするわけなのですが、1つだけ嫌な予感がしていました。
それは「要件定義に参画した1名にコーディング経験が一切ない」事でした。30歳後半、ずっと某SIerで要件定義&設計のみを担当してきた、という経歴の持ち主。Uさんとしておきます。
経験上、上記のようなプレイヤーはユーザーの声を技術的に実現可能か判断がつかない為「エンドユーザーの意見を現場に卸すだけ」になりがちです。結果、エンドユーザーと現場の声を両方受け止めきれなくなり、病んで撤退 or 仕事が雑になってプロジェクト炎上というのがよくあるパターン。
さらに、今回はそれにアジャイルという要素が加わり、状況がさらに悪化していくことになります。
顧客の要件がモリモリ増える中、一向に参画メンバーが増える兆しがありません。さらには今回作る大本のWEBシステムのサブWEBシステムが追加で2つも必要になる、という玉突き具合。完全に各人キャパオーバーです。
大本システムのmock、新規に増えた2つのシステムのアプリケーション設計、それぞれの基底処理を作るのに必死で、要件定義に首を突っ込む暇がありません。頼むから他の2人で何とか受け止めて欲しいとお願いはしましたが、先述のUさんともう一人の要件定義担当者も要件の無法地帯っぷりにイライラしていたのか、1週間に何度も口論によるぶつかり合いが発生していました。背後の言い争いを聞きながら作業に集中できるわけもなく、チーム全体の士気も下がる一方です。
この状況が続くなら10月には他の現場に移るなぁ、と考え始めたころ、流石にPMも見かねたのか、開発方針にメスが入ります。
やはり開発ボリュームが巨大すぎる、という事になり、PMが納品先と予定を調整し、一部機能を別ベンダーにお任せする事になりました。私が所属しているチームはその商流には噛まずに、完全に別責任の成果物という扱いとなり、それをこちらのチームが引き取る形で開発を進める、という形です。
これによりなんとかギリギリ要件定義フェーズを持ちこたえ、基本設計フェーズと開発を平行して実施する段階になりました。
ただし、この時既にチームの雰囲気はかなり悪化しており、特に横柄さを前面に押し出す形で仕事をしていたUさんとは口を聞きたくないと思うぐらいでした。雰囲気的に他のメンバーも同じことを思っていたでしょう。
画面を作成するための一通りの基底処理を作成した所で、Ｕさんの作った設計書を元に、本格的にシステムの開発に取り組むことになるのですが…これがまぁヒドい出来でした。
「XXXという状態であるとき、YYYを実施する」と書いてあるのですが、いや、『XXX』って画面がどういう状態の事を指してるのか？ DBのどのカラムがどういう値の時を指してるのか？ という事が何も書いてないのです。設計書の粒度が完全に基本設計で止まっています。その他にも同じ意味の言葉が一貫しなかったり、参照元も定義値も書いていない固有名詞があったりと、顔をしかめる機会が多すぎてシワが増えたんじゃないかと思っています。
これでは実装できないので都度Uさんに確認に行くわけですが、「こういう意味で言った/書いた」「普通に考えたらこうでしょ」「設計書見れば分かる」などと言い訳ばかり。「俺は悪くねぇ！」と心の声がダダ漏れです。もし、設計者の意図を都合よく読み取らないと実装できないなら、それは設計書ではない。設計者の自己満足だけが反映されたゴミです。
と、ダメダメな設計内容に加えて上記のような無能臭漂う減らず口が必ずオマケで付いてくるので、早々にUさんは無視して、納品先のシステム担当者に直接話を聞いて設計書を書き換えながら作業していました。これで設計暦15年()かぁ…と本気で呆れていました。私の出会ったメンバーの中でTOP5に入る無能っぷりです。
開発が過渡期に入る中、フリーランスなのに何故こんな馬鹿と一緒に仕事をせねばならない？ と紋々しながらの開発が2か月ほど続きます。もちろんPMに彼の無能っぷりは報告したので、彼は契約を切られる方向で話が進んでいます。そりゃそうだ。
ガントチャートは開発フェーズの後期に結合テスト工程が食い込む形になり、今回も完成した機能から内部結合テストを順次行う事に。
で、単体テスト、内部結合テストの仕様書は設計書から「本当にこの挙動になっているか」をテストするわけですが、私が直した箇所はともかく、前述の通り設計書が基本設計レベルが多々ある為、テストするにあたって何が正しいのかが分からない。という状態が頻発していました。
そんな状態で「アジャイル」という性質上、ユーザーからあれこれ意見が出てきて改修が発生するものですから、溜まったものではありません。開発チームもテストチームもUさんへの不満は爆発していました。
開発フェーズと同様テストフェーズも難航し、テストチームは残業でカバーする形になっていました。『設計がダメだと全てダメ』がシステム開発の常ですが、それが如実に出た結果と言えます。
私はこの時既に「これ以上Uさんと仕事はできない。チームが変わらないのであれば現場を抜ける」とPMに直訴していた為、来年度からは新しいプロジェクトに参画する予定となっています。本プロジェクトでもUさんを押しのけて一定の活躍をしたことが評価され、単価もUPする予定です。
来年から別プロジェクトに配属することになった私は、主に画面のレイアウト調整や不具合修正などを担当していました。私宛にタスクが振られる事も少なくなり、年末まで消化試合が続きました。
フリーランスになってまで設計者に振り回されるとは思っていなかったです。スルースキルは磨かれましたが、それ以外は得るものもありませんし、二度とコーディング経験のない設計者と一緒に仕事はしたくないと強く思いました。
来年も皆さんに、よき技術の場が与えられますように。
入会申込
ログイン
