Help us understand the problem. What is going on with this article?

納期守れない系エンジニアが遅延無しでちょっと頼りにされるまでに学習したこと

初めに

この記事は、私が納期をまともに守れなかったころから、
遅延しなくなり後輩の遅延を手助けするまでに
学習したことや心がけていること及び失敗談を記述します。
暇つぶしに読んでいただければ幸いです。

前提:どれぐらいできなかったか

・イケると思った機能が1週間遅延して更にバグまみれ。
・プロトタイプ版開発に時間をかけすぎて仕様変更によって結局遅延。
・ユーザーが欲しいと思った機能が、完成とほぼ同時に不要になってしまった。

この記事の内容は、主観と経験に基づくものが多いです。筆者はよく言っても中堅エンジニア
なので、記述内容が必ず参考になるとは限りません。

勉強した事

交渉&見積もり編

・正確な工数見積もりは「不可能」である事を認識する。
実際に機能を作る前には、「だいたいどれくらいでできるのか」という事を絶対に確認されます。
その時に、過去の経験からn日でできるな…と考えても、それはたいてい失敗します。
なぜなら、全く同じ機能を2度作ることは殆どない為です。かなり近しい事をしたことがあっても
前回とは違う部分が必ずあります。そして大抵の場合、そこが大きなボトルネックとなって死を迎えます。
その中で見積もらなくてはいけないので、最低でも自分のできると思った日数+2日はかさまししておきましょう
(バッファという事が多いです。)

特に経験が浅かったり、転職や派遣されたばかりでシステムの内容を知らない場合は
「初めてなんで、5日かさまししました。」とかいっても有効です。
主観ですが、全ての作業が完璧に見積もれるといった状態になると楽しさってあるのかなぁと思います。

・どれくらいでできるか?と聞かれたとき
実は大きな罠です。即答してはいけません。まずは「ちょっと調べてみますね~1日くらいかかっちゃうかもです」とかいって
濁しておきましょう。逆に、リーダーをやるときは濁されずに即答されたとき、少し疑って質問すると
うまくいく結果になることが多かったです。

開発モデル別バッファのかさまし目安
筆者はウォーターフォール開発、アジャイル開発の経験しかないので、その2つしか語れませんが
・ウォーターフォール開発なら、自分の見積 + 5日or期日の限界まで
・アジャイル開発なら、自分の担当する機能の2回目のスプリントレビューまで
をかさましし、半分を過ぎたところで7割がた完成、という状態を目指せば事故率は下げられました。
どちらも、適宜指摘を受けながらできるとなお良いです。
それが難しい場合は、人を増やしたり有識者の時間をいただいたりするような調整をするとよいです。

設計編

要求を全て満たす。という事のみを考える。
設計工程で作るドキュメントはソースコードと違い、納品物となる場合とならない場合があります。
また、納品物として指定されている場合はたいていフォーマットが決まっています。
そしてフォーマットはお粗末であることが多いです。
つまり、力を入れるところではあるのですが、力の入れ方は
イケてるドキュメントを作ることではなく、
製造工程のイメージを固めること、または製造工程で楽ができること
に注力する必要があります。
筆者の体験談ですが、それはそれはきれいなレイアウトの設計書を作ったはいいが、
肝心の中身がお粗末すぎて結局手戻りが発生した。という事が何度かありました。
中身で勝負しましょう。
また、ここで作成したものをベースに他のメンバーが製造する場合は、
その人が作りやすいという事を考えるとより良いです。

誤字・脱字をしない
これも良くやってしまうのですが、誤字・脱字は想像以上に工数を無駄にします。
誤字脱字のある設計書→レビュー指摘で誤字を指摘される→修正して再レビュー→確認して終わり
と、本来確認しなくてはならない設計の破綻や設計漏れにまで目がいかなくなり
手戻りの原因となる=遅延に近づくという、多くの場合想像以上のダメージを被ります。
細心の注意を払いましょう。
プログラムで考えるなら、コンパイルエラーの状態でプルリクエストしているのと同じです。

少しの体裁の違いは許容する
これはレビュー時なのですが、少しの体裁の違いも許さず指摘し続け、
工数を食いつぶすレビューアにならないことを意識しています。
なぜなら、上記の通り中身が大事なのであって、多少の見た目の違いは
(納品物として指定されていなければ)気になる、レベルで終わることだからです。
その為、是が非でも指摘しようという精神でレビューするのはあまりお勧めしません。

製造編

※サンプルとして、JavaとPythonを使いますが、どの言語でも共通かなと思います。

異なるパラダイムをつまみ食いする
例えば、私は普段Java、Pythonを使ったバックエンドを主担当としていますが、
どちらもオブジェクト指向型プログラムに適した言語です。(最近は両方マルチパラダイムっぽいですが)
なので、普段の時間で関数型プログラミングのメリットを学習し、その一部を取り入れることで、
より簡潔な記述が出来、簡潔であるためにバグも少なく製造中にエラーが発生しても
簡単に対処できる。といったいいことずくめです。
ここでは、関数型プログラミングの思想や詳解はしません(奥が深すぎてできません)
普段オブジェクト指向向けの言語を利用している方であれば
・引数に渡した値が同じなら、返却される値も同じ
・変数の再代入を可能な限り少なくする
という2点と
・標準ライブラリの機能をふんだんに使う
を意識するだけでもかなり後工程の難易度を下げてくれます。

sample.java
    // 渡された引数をベースに処理をする。引数がHelloなら、常に結果はHelloWorldとなる。
    // 引数の値次第で結果がわかるので、テストもしやすい。(マジックナンバーなのはご愛敬)
    public String convertGreetingMsg(String msg) {
        return msg + "World";
    }

    // 入力値をベースに処理をする。入力値によって値が変化するため、バグの温床となりやすい
    // このような機能を使わなくてはならない場合、より効率的な設計があるはず
    public String convertGreetingMsg(String msg) {
        Scanner inputScanner = new Scanner(System.in);
        return msg + inputScanner.toString();
    }

    // 呼び出しているメソッドの内容がわかれば流し見でもわかる。
    // バグが発生しても、引数に何を渡しているかだけを見れば原因がわかりやすい
    public int sumNumberStream(List<Integer> numList) {
        return numList.stream().mapToInt(Integer::intValue).sum();
    }

    // 基本構文を知っていれば誰でも読めるが、一度処理を読まないと何をしているか
    // 比較的わかりにくい
    public int sumNumberLoop(List<Integer> numList) {
        int sumResult = 0;
        for (Integer num : numList) {
            sumResult += num.intValue();
        } 
        return sumResult;
    }

実務で使わない他の言語を触る
エンジニアなら当たり前の事なのかもしれませんが、上と同じように
「知らないこと」を知ることで、普段のソースコードの作成がより速くなったり
より品質が上がるのは間違いないです。
私はJavaで開発しているときにPythonを学び、Pythonの思想を身につけることで
よりJavaの理解が深まりコーディングが簡潔になったことがあります。
見たところ「納期を守る」ことに直結しないようにも見えますが、
開発中の品質向上はエラー発生や考慮不足を減らし、結果として工数の削減につながります。
あまり普段他の言語見ないなぁといった方にはおすすめです。

sample.py
    ''' 
        上のJavaをPythonで書くなら…
     例が悪いから若干だけど、型がない分Pythonの方が短いなあとか気づける
     でも型ほしいなぁとかも…
     '''
    def convertGreetingMsg(msg) :
        return msg + "World";

    '''
    stream()とmapToInt()が減った分より何をしているかわかりやすい
    '''
     def sumNumberFunc(numList) : 
        return sum(numList);

終わりに

これは私の考えであり、全ての人に当てはまるとは思っていません。
ですが、納期を守れずつらい思いをしているのであれば、どこの工程でしくじることが
多いかを分析し、その結果に応じてここに書いてあることを意識すると
遅延もなくなり、頼りにされるかも?保証はしません。

追記(2020/06/12)

トレンド入りしました!
たくさんの閲覧、大変ありがとうございます。
よろしければ、コメント欄に有用な記事を添付していただいているので
そちらも参照してみてください。(@error_401 様ありがとうございます。)

mamoru12150927
常駐エンジニアとして働き出して4年目です。 Python、Java、Node.jsを利用することが多いサーバサイド寄りのエンジニアです。
Why not register and get more from Qiita?
  1. We will deliver articles that match you
    By following users and tags, you can catch up information on technical fields that you are interested in as a whole
  2. you can read useful information later efficiently
    By "stocking" the articles you like, you can search right away
Comments
No comments
Sign up for free and join this conversation.
If you already have a Qiita account
Why do not you register as a user and use Qiita more conveniently?
You need to log in to use this function. Qiita can be used more conveniently after logging in.
You seem to be reading articles frequently this month. Qiita can be used more conveniently after logging in.
  1. We will deliver articles that match you
    By following users and tags, you can catch up information on technical fields that you are interested in as a whole
  2. you can read useful information later efficiently
    By "stocking" the articles you like, you can search right away
ユーザーは見つかりませんでした