確かに設計書の間違い何回もしてるしなぁ。。
でもプログラマーの方だって、バグ出してるからおあいこだろ！
こんにちは、古賀です！
本記事では、
はてな
「プログラマーから信頼されない。。」
「プログラマーから品質の良いプログラムがあがってこない。。」
こんな悩みを解決するために、
システムエンジニアが意識すべきことを「３つ」お話したいと思います。
良い品質のプログラムがあがってこない原因は、
プログラマーに「良いパス」を出せていないことが原因です。
プログラマーへの「良いパス」が、
「お客さんの満足」
「プロジェクトの成功」
に繋がります！
プログラマーへの「配慮」を大事にして、
信頼されるシステムエンジニアになりましょう！
自己紹介が遅れましたが、
わたしは大学卒業後、上場IT企業に就職し、プログラマー、システムエンジニアとして
約１０年間働いておりました。
プロフィールの詳細はこちらです。
-
-
プロフィール
こんにちは、古賀正雄です。現在３６歳です。 簡単ではありますが、こちらのページで自己紹介とこのブログについてお話します。 高校時代 学生時代は主に野球をしていました。 進学先の高校も野球で選びました。 ...
続きを見る
意識すべきポイントは、以下の３つです。
ポイント
- 開発してもらう順番を考慮する
- 部分的な引継ぎはしない
- 出来立てホヤホヤの設計書ですぐ引継ぎしない
※YouTubeに同内容を公開しております。
詳細設計はプログラマーに開発してもらう順番を考慮して作成する
意識すべき１つ目のポイントは、
「開発してもらう順番を考慮する」
です。
その順番ですが、
ポイント
「インプット系からアウトプット系の順番で開発する」
この順番を守ることが大事です。
インプット系から作ることで、以下のメリットがあります。
- 詳細設計書の後戻りが少なくなる
- プログラマーのテスト精度が上がる
会社によって、設計書が全て出揃ってから、開発を進めることもあると思いますが、
スケジュールの関係上、詳細設計書が完成したプログラムから開発を進めることが多いと思います。
（わたしがお世話になった会社もそうでした）
そこで、楽だからといって、
注意ポイント
「ボリュームの軽いアウトプット系から開発してはいけない」
誰もがやりがちなので、ここは注意しておきましょう。
詳細設計書の後戻りが少なくなる
詳細設計書の後戻りが少なくなる理由は、
「インプット系の設計書を作ることで、システム全体を見渡すことになる」
からです。
システム上で考慮しておくべきことを、半強制的に考えさせられます。
インプット系の詳細設計を先に作ることで、
テーブル設計書を始めとした「詳細設計の土台」ができます。
逆にアウトプット系から作ると、
そのプログラムのことだけを考えてしまいがちです。
全体を見渡せていない詳細設計は、後でミスが見つかります。
プログラマーの舌打ちが聞こえてきます。。
なので、
システムの根幹部分のインプット系から作りましょう！
「めんどくさいことは先にやる！」
これを徹底しましょう。
プログラマーのテスト精度が上がる
プログラマーのテスト精度が上がる理由は、
「インプットプログラムで、アウトプット系プログラムのテストデータが作れる」
からです。
アウトプット系プログラムを先に開発したとしましょう。
そうした時に、
アウトプット系プログラムをプログラマー側でテストをしようとすると、
「データを手作業で作ってテストするしかない」
という状況になります。
しかも、アウトプット系のプログラムは経験の浅いプログラマーが担当しがちです。
「なんとなくデバッグして終わり！」
これで納品してきます。
インプット系のプログラムを先に作っておけば、
適当にデバッグされて納品されることはありません。
プログラマー側で、インプット系プログラムでデータを作って、
アウトプット系プログラムのデバッグをする、
「簡易結合テスト」を自動的にしてくれます。
しかも、アウトプット系プログラムの開発担当者が、
インプット系プログラムを動かしてますので、
インプット系プログラムのテストも自動的にしてくれます！
さらに、システムの繋がりをプログラマー側が意識するようになります。
そこまでくると、
「プログラマー側で詳細設計のミスを拾うようになる」
ここまでくれば、もう無敵です！
テスト工程でなく、開発段階でミスをキャッチできるようになります！
詳細設計が未完成！SEはプログラマーに対して部分的な引継ぎはしない
意識すべき２つ目のポイントは、
「部分的な引継ぎはしない」
です。
引継日までに設計書が出来上がらずに、
「出来たところまで一旦引継ぎするから、そこから作り始めておいて！」
と言ってしまうことがあると思いますが、これはNGです！
段階的に引継ぎをすることで、プログラマー側で以下のようなことが起きます。
「保留部分が多くなり、作りにくい（作業効率が悪い）」
「後から付け足していくことで、バグが出やすくなる」
開発する内容が、
システムエンジニア側から見れば繋がっていなくても、
プログラマー側から見れば繋がっていることがあります。
部分的な引継ぎは、
プログラマーのやり直し作業が発生しやすくなってしまうのです。
設計が出来た部分だけ先に開発してもらえば、
一見早くプログラムが完成しそうですが、
時間と質の両方の面を考えると、プラスではありません。
システムエンジニアにとっても、
プログラマーにとっても良いことがありません。
しっかりと設計書を完成させた後に、引継ぎをしましょう！
SEは出来立ての詳細設計書ですぐプログラマーへ引継ぎしてはいけない
意識すべき３つ目のポイントは、
「出来立てホヤホヤの設計書ですぐ引継ぎしない」
です。
「部分的に引継ぎするな！」
と言われて、
しっかり設計書を完成させたのに「まだ！？」と思われたかもしれません。
すぐに引継ぎしてはいけない理由は、
「プログラマーに設計書を見る時間を与えるため」
です。
システムエンジニアは自分で設計書を作っていますし、
お客さんと何回も打合せをしているので、
開発内容はしっかり頭に入っている状態です。
それに対してプログラマーは、頭の中の開発内容はゼロです！
余程うまく話をしない限りは、開発内容は基本伝わりません！
引継ぎする前に、プログラマーにしっかりと設計書を読んでもらいましょう！
そうしておくと、
「引継ぎ時間が短縮される」
「プログラマーから設計書の指摘をしてもらえる」
「プログラマーから設計の改善案を言ってもらえる」
「プログラマーの開発内容の理解が深まり、プログラムの質が高まる」
こんなことが起きます。
開発内容が正しく伝わっていないと、
プログラマーはどうやってテストをしたらいいのかわからず、
質の低いプログラムが生まれます。
少しの時間で大丈夫です。
プログラマーが設計書を事前に読む時間を作ってあげてください！
先程の部分引継ぎと合わせて、
プログラマーの準備については、こちらの記事にまとめています。
-
-
優秀なプログラマーは準備が違う！勝負はコーディング前に決まる！
プログラマーとして働き始めたけど、 まだまだバグも多いし、作業スピードも、周りからの信頼もいまいち。。 なんか効率が良くなる裏技みたいなやり方はないかな。。 こんにちは、古 ...
続きを見る
最後はSEからプログラマーに気持ちを伝えよう！
詳細設計で意識すべきポイント３つあげましたが、
「気持ちを伝える」
ことも大事ですよ！
詳細はこちらの記事を参考にしてください。
-
-
Go言語(Golang)の概要＆特徴とWEBサービス開発で使用した感想！
バックエンドではGo言語が流行ってきているって言うけど、他の言語とどう違うんだろう？ こんにちは、古賀です！ 本記事では、Go言語の はてな 概要や特徴 フレ ...
続きを見る
まとめ：詳細設計で配慮すべきこと！
ここまでの話をまとめます。
ポイント
＜開発してもらう順番を考慮する＞
「インプット系からアウトプット系の順番で開発する」
それにより、
- 「詳細設計書の後戻りが少なくなる」
- 「プログラマーのテスト精度が上がる」
というメリットがある。
＜部分的な引継ぎはしない＞
部分的な引継ぎをすることで、
- 「保留部分が多くなり、作りにくい（作業効率が悪い）」
- 「後から付け足していくことで、バグが出やすくなる」
ということが起きてしまう。
設計書を完成させてから引継ぎを行うこと。
＜出来立てホヤホヤの設計書ですぐ引継ぎしない＞
プログラマーに設計書を読む時間を作る。
そうすることで、
- 「引継ぎ時間が短縮される」
- 「プログラマーから設計書の指摘をしてもらえる」
- 「プログラマーから設計の改善案を言ってもらえる」
- 「プログラマーの開発内容の理解が深まり、プログラムの質が高まる」
というメリットがある。
本記事の内容を、簡単にまとめると、
「最初にしっかりと時間をかけて設計書書きなさい！」
ってことになりますね。。
掛けた時間は後で回収できます。
これも一流思考の考えです。
※一流思考を読んでいない方はこちらです。
-
-
エンジニアとして成長するための考え方！一流へ成長する方法とは？
エンジニアになったけど、いまいち成長を感じられないなぁ。。 作業スピードも品質も平凡。 この先成長していけるんだろうか。。 こんにちは、古賀です！ エンジニア ...
続きを見る
最初に時間をしっかりと掛けて、
プログラマーに気持ちよく動いてもらいましょう！
丁寧に仕事していれば、プログラマーに気持ちが伝わります。
気付いたらプログラマーから信頼されて、
質の良いプログラムが納品されてきますよ！
その先に、
「お客さんの満足」
「プロジェクトの成功」
が待ってます！
