笑えない進捗率80%

会社でプロジェクトを進める上で進捗を管理する方法はなにがあるだろう。

基本的には作業者が記述する進捗率ではないだろうか。

システム開発ではよく、設計・製造・テストの工程があり、各自作業状態から進捗を入力しているだろう。

さぁ、自分の入力している進捗率の基準はどういう数値で入力しているだろう。

実際にあった進捗率80%というエンジニアの闇を書いていきましょう。

(4000字ぐらいあります。)

始まり

要件定義、設計、製造、運用まで含めたリプレイスの仕事を受注し、プロジェクトが始まった。

リリースまで1年を計画しているプロジェクトである。

要件定義と設計に関してメンバー全員で取り組み、製造の段階に突入した。

いままで使ったことがない言語とフレームワークを利用し、製造を開始した。

フロントエンドとAPIで分かれており、開発者もフロントエンドとAPIで分かれて開発している。

APIのドキュメントを用意し、フロントエンドはドキュメントを元に開発を行なっていた。

開発メンバーは10人未満で、開発レベルは新人レベルと中間層レベルの人たちで行なっていた。

APIのプロジェクト基盤は別の人が作成しており、プロジェクトにはまだ参加していなかった。

進捗報告

朝のミーティングにて進捗報告を行なっている。

基本的には、作業の予定と先日の進捗報告になっている。雑談も少しするが、進捗報告が終わればすぐ終わるミーティングになっている。

設計段階は終わっており、画面イメージと機能は共有されている状態であり、製造段階から要望を受けつつ開発する流れになっていた。

進捗報告はwebのツールで管理されており、各自機能ごとの進捗率を記入するようになっている。

いまのところ進捗で問題がある。と報告するメンバーはいない状態で、開発の期限の1ヶ月前を迎えていた。

メンバーからの進捗の問題は提起されていないが、マネージャーは進捗率が芳しくないことを感じており、メンバーの増強を考え一時的に開発に参加してくれる人をアサインした。

アサインされた人物はAPIのプロジェクトの基盤を作成していたため、プログラム言語の記述には問題がない人物であり、仕事が空いていたため参加した。

プロジェクトの概要をしらない新規の参加者は、進捗をみてある程度終えていることから順調そう。と感じており、自分の担当分のみ消化していた。

ある程度の作業が終わり自分の担当部分の目処ができたため、フォローに回るべく全体的にプロジェクトを見てみることにした。

全体を見ることでようやくプロジェクトの状態を理解していき、仕事の時間を増やす必要があることを覚悟した。

全体の状況確認

進捗状況を確認したところ、全体の8割の作業には手がついており終わりに向かっていると感じてれる内容になっている。

ただし、機能ごとの難易度はこれに考慮されておらずちゃんと確認したところ、難易度と技術的要素が不確定の内容のみ残されている状態になっていた。

「できるところから進める。」という新人にお願いするような内容をメンバーが選んで仕事をしていたためプロジェクトのコアの部分が残る結果になっていた。

新しい言語ということもあり、「できる部分をまず作ってみよう。」という意識で始まったのは理解できるが、開発後半になってもその意識で進めているのはかなり問題があった。

とにかく終わる目処をつけるために、できそうな部分は放置しコアの難易度が高い部分に手をつけ始めたが、設計に参加もしていないため仕様が理解できない内容も多く、業務知識を理解するところ含め説明を求めながら作成していくことになった。

この時点で終わらないことをマネージャーに説明していたが、社員から進捗に関する提起は発言されていなかった。

開発終了目処の1週間前にようやく開発者から、「間に合いません。どうしましょう」という発言がされた。

進捗率80%

マネージャーも終わらないことは理解し、クライアントに説明と開発期間の延長の話を行い、なんとか延長されることが決定した。

機能のコアの部分を作成するうちに、影響する機能も確認するようになった。他のAPIで設定を行なっていたためデータを作る際にAPIを使用したほうが早そう。と思ったため必要なAPIを使ってみた。

開発終了日が記入されているAPIを使ってみたが、どうも期待通りに動作しない。

進捗率は80%である。

80%だから動作しないのか。と思い、コードを確認すると怪しいコードを見ることになる。

「このコード、確かに限定的な条件で動作するけど、期待している動作はしない気がするけど、なんだろう。完成度80%のコードでもない気が・・・」

理由としては、

• 動かないAPIがある
• 必要なパラメータが全部正しいことが必須条件
• validateがない
• エラー処理がない
• 受け取るパラメータが多すぎる（これについては、別途記述）

会社で働いたことがあるエンジニアは、大半の人がエラー処理が大変であることを知っていると思う。

エラー処理がない時点で、かなり怪しい。と感じていたが、80%の基準はなんだろうか。

マネージャーに確認してみたが、「validateが難しいと言われたから、ない状態でちゃんと動作すれば80%で」と言っていたみたい。確かにvalidateだけ書けばいい状態なら、80%でもいいと思ったがエラー処理は別だろう。

一つでも見つけてしまうと、他の80%も怪しくなる。

APIだけならなんとかできたかもしれない。だが全体をみることを覚悟してフロントエンド側も確認したところフロントエンドは別の問題を含んでいることに気づき全部書く覚悟をすることになる。

フロントエンドとAPIの溝

開発効率のため、フロントエンドとAPIで開発が分かれていた。

APIはツールを使いパラメータを渡しながら開発し、フロントエンドはデータを自分たちで作成し開発していた。

開発終盤になるまで、フロントエンドとAPIを連携したテストを行なっていなかったのだ。

フロントエンド側の開発がほとんど終わったらしく、APIと連携してシステムとして動作するか確認する段階をしていた。

フロントエンドの開発者から動作しないことを報告され、確認してみたがAPI単体では動作していた。

フロントエンドの画面をみてみると、渡されるパラメータが数値の内容だがint型やstring型で渡されることでエラーになっていた。

確かに起こり得る現象でフロントエンドとAPIでの連携を試していなかったことに反省したが、修正方法もわかったため修正に取り組むことになる。

修正方法がわかったので、先に進める。よかったよかった。

もう一つの気になっていたことで「受け取るパラメータが多すぎる」件について、フロントエンドの開発者に確認しており入力値が多いのか確認してみたが全然違っていた。

どうやらAPI側の開発者が渡されたパラメータをそのままデータベースに登録するためにフロントエンドに処理を書かせていたみたいで、API側が楽をする構造になっていた。

それは違うだろう。ということで、APIの仕様を書き直しフロントエンドのデータ送信部分も自分で書き直すことになった。

どうやらちゃんと話し合いをしているわけでなく、APIのドキュメントにあったように送る。ということで作業をしていたらしい。

あまり見ないパラメータセットになるわけで、よくない仕様になっていると感じた。

実はあまり雑談以外の会話はなく、プロジェクトに関する話し合いはしていないことに気づき、現状になったらしい。

マネージャーと開発者の溝

マネージャーも開発を担っている部分があり、作業者がきまっていない作業はマネージャーの開発として振り分けられていた。

難易度の高い機能については、マネージャーの名前が作業者に割り当てられており、手が空いた人に割り当てる予定だったみたいだが、他の機能の進捗が芳しくなく、他の機能を優先させる判断をしたらしい。

結果として、難しい部分が残り開発者は自分の割り当てのみ完了すればいいと判断し、悪循環のプロジェクトになっていた。

途中参加のエンジニアが機能ごとの難易度を判断することもできず、とにかく難しい機能を担当をすることでなんとかプロジェクトの終わりが見えてきた。

マネージャーも開発者のレベルを把握していることと、任せらる開発者が不足していたため難しい部分を任せることができなかった。というジレンマになった。

社員とフリーランスの意識の違い

割り当てられた作業のみ完了させようとする社員。

プロジェクトをちゃんと完了できるよう取り組む外部のフリーランス。

この構造になること自体珍しいが、世の中にはそういうプロジェクトもあったりする。

ちゃんと終わってよかった。

終わり

最初からすべてうまくいくプロジェクトはないと思う。

悪かった点をどう見つけるか、どう改善するかが重要だと思います。

同じケースをどう解決したのかの情報を集めることで気づきが多くなるので、常に意識していろんな情報を集めることがいいことだと思います。

意識するだけで結構入る情報が変わりますね。

管理する側だけが意識する話ではなく、チームとして意識する必要があるので、人ごとではなく自分ごととして捉えて仕事をしていきたいですね。