まだまだバグも多いし、作業スピードも、周りからの信頼もいまいち。。
なんか効率が良くなる裏技みたいなやり方はないかな。。
こんにちは、古賀です！
本記事では、
はてな
「発注者から信頼されない」
「バグが多い。。」
「コーディングスピードが出ない。。」
という悩みを解決します。
周りからも信頼され、
効率良く作業をして、
品質の良いプログラムを開発するためには、
「コーディング前の準備が全て」
です！
コーディング前の準備に力を入れれば、
効率良く、質の高いプログラムが開発できます。
準備の意識を高めて、
「信頼されるプログラマー」
になりましょう！
自己紹介が遅れましたが、
わたしは大学卒業後、上場IT企業に就職し、プログラマー、システムエンジニアとして
約１０年間働いておりました。
プロフィールの詳細はこちらです。
-
-
プロフィール
こんにちは、古賀正雄です。現在３６歳です。 簡単ではありますが、こちらのページで自己紹介とこのブログについてお話します。 高校時代 学生時代は主に野球をしていました。 進学先の高校も野球で選びました。 ...
続きを見る
準備で大切なことは、以下の４つです。
- 打合せ前の予習
- 打合せの進め方
- ベースプログラムの選定
- 設計とベースプログラムの完全理解
１つずつ解説していきます！
※YouTubeに同内容を公開しております。
常に一流思考を忘れない！
本題に入る前に、「一流思考」を忘れないでください！
まだ「一流思考」の記事を読んでいない方は、こちらからどうぞ！
-
-
エンジニアとして成長するための考え方！一流へ成長する方法とは？
エンジニアになったけど、いまいち成長を感じられないなぁ。。 作業スピードも品質も平凡。 この先成長していけるんだろうか。。 こんにちは、古賀です！ エンジニア ...
続きを見る
一流思考は、
「めんどくさいことを先にやる」
でしたね？
今回お話する内容は、図で示すと以下の部分になります。
図の「準備するための時間」で、
「考えること」
「調べること」
「めんどくさいこと」
を先に行うため、進捗は最初悪いのですが、
その後は爆発的に作業効率が上がっていくという考えです。
プログラマーが、この期間にやるべきことが、
- 打合せ前の予習
- 打合せの進め方
- ベースプログラムの選定
- 設計とベースプログラムの完全理解
なのです！
優秀なプログラマーの「打合せ前の予習」
大切な準備の１つ目が「打合せ前の予習」です。
何をすればいいかと言うと、
「打合せ資料を事前に読んで、質問内容や作業の検討をつけておく」
です。
発注者やシステムエンジニア、または開発チームの誰かから、
今回開発するプログラムについての打合せがあると思います。
その内容を事前に把握しておきましょう！
なぜなら、
注意ポイント
「当日いきなり内容を聞かされても、内容の理解ができない！」
ためです。
事前に資料を貰っておき、打合せ内容を充実させましょう！
優秀なプログラマーの「打合せの進め方」
大切な準備の２つ目が「打合せ前の進め方」です。
打合せをする上で意識すべきことは、
「予習内容を確認する」
「設計上で好ましくない箇所は代替案を提示する」
「設計書が出来上がっていない段階での打合せは行わない」
です。
予習内容を確認する
打合せ前にした予習の成果を存分に発揮させましょう！
ポイントは、
ポイント
「自分主導で打合せを進める」
です。
相手に一から説明をしてもらうのではなく、自分から攻めましょう！
「ここはこういうことですね？」という理解している部分の確認
「これはどういうことですか？」という不明点の確認
「他に何か注意することはありますか？」と最後にボールを相手に持たせる
上記のような感じで進めると、
- 相手から信頼される
- 打合せ時間の大幅短縮
というメリットが得られます。
時間の大幅短縮は、
自分にとっても、相手にとっても嬉しいことです！
内容を理解してもらっているだけでなく、
時間の気遣いもできれば、信頼してくれること間違いなしです！
実際にコーディング作業を始めると、疑問や質問したいことが出てくる場合もありますが、
その疑問質問が出てこないように、完璧に打合せを進めましょう！
「疑問や質問が後から出てこないようにする」
この意識が重要です！
設計上で好ましくない箇所は代替案を提示する
プログラムを開発する上で、
「この設計だと難しいなぁ。。」
という部分があるかもしれません。
そのような箇所があれば、積極的に別案を提案してみましょう！
予習に力を入れていれば、事前に別案を考えておくこともできるはずです！
ただし、１点注意です！
注意ポイント
「相手が不利益になるような提案はしない」
自分だけが楽になる提案はしてはいけません。
お互いにメリットのある提案であれば、相手も快く受け入れてくれますし、
さらに信頼感も高まりますよ！
設計書が出来上がっていない段階での打合せは行わない
相手の都合上、打合せ日までに設計書が出来上がらずに、
「出来たところまで一旦引継ぎするから、そこから作り始めておいて！」
と言われることがあるかもしれません。
前述した２つと比べて、少し自分勝手に思えるかもしれませんが、
注意ポイント
「段階的な打合せは行わってはいけない」
です。
なぜかと言いますと、
目先のことだけ考えた「とにかく手を動かす」スタイル
のやり方だからです。
「とにかく手を動かす」スタイルが分からない方はこちらをまず読んでください（２回目）
-
-
エンジニアとして成長するための考え方！一流へ成長する方法とは？
エンジニアになったけど、いまいち成長を感じられないなぁ。。 作業スピードも品質も平凡。 この先成長していけるんだろうか。。 こんにちは、古賀です！ エンジニア ...
続きを見る
段階的に引継ぎをすることで、
「後から付け足していくことで、バグが出やすくなる」
「全体を把握してから作る」という手法が取れない
ということになります。
納期がギリギリでない限りは、段階的な打合せは行わないようにしましょう！
両者にとって良いことがありません。
優秀なプログラマーの「ベースプログラムの選定」
大切な準備の３つ目が「ベースプログラムの選定」です。
プログラムを作り始める時に、
今まで作ってきたもの（他人が作成したプログラムを含む）の中から、
「ベースプログラム」を選んで、そのプログラムを変更する形で開発を進めると思います。
※１から作る場合もあるかと思いますが、ベースプログラムを選ぶ場合の話をします。
ベースプログラム選びがなぜ重要なのかと言うと、
「作業量を最小限にできて、バグも少なくできる！」
からです。
バグの少ないプログラムを作成するコツは、
「なるべく自分でコードを書かないこと」
です。
完成されたプログラムをそのまま使えるのであれば、
わざわざデバッグをする必要もありません。
デバッグが必要な部分は自分で書いた部分だけです。
コードを書く量を減らすためにも「ベースプログラム」が重要になってきます。
選ぶ上でのポイントは、
ポイント
「見た目ではなく、構造が似ているプログラムを選ぶ」
です。
見た目も構造も、今から作りたいプログラムと似通っていれば問題ないですが、
どちらかしか似ていない場合は、構造を取りましょう。
デザインのバグよりも、プログラムの動作バグの方が起きやすいためです。
後は、
「相手から指定されたベースプログラム」
「他の人が作ったものでなく、自分で作ったプログラム」
という視点から選ぶのも良いですよ！
優秀なプログラマーの「設計とベースプログラムの完全理解」
大切な準備の最後が「設計とベースプログラムの完全理解」です。
一流思考の記事を読まれた方は分かるかと思いますが、
「考えてから行動する！」
「考える。そして後は走るだけの状態にする！」
この意識です。
今までの３つの準備をしっかりしておけば、
そこまで苦ではないはずです。
「設計書の不明点をゼロにする」
⇒不明点や難しい箇所の実装方法は事前に解消しておく
「ベースプログラムから変更する箇所を把握しておく」
⇒設計書と同じく理解していない場所がないように！
頭の中でプログラムが完成するまで、動き出してはいけません！
処理の理解だけでなく、設計の意図、設計者の気持ちも理解しましょう！
１日以上掛けてもいいです！
とにかく、
「理解するまで動き出さない！」
ことが重要です。
ここまでくれば後はもう手を動かすだけ。
バグの数も、作業スピードも格段に上がっているはずです！
まとめ：優秀なプログラマーの準備とは？
ここまでの話をまとめます。
まとめ
＜打合せ前の予習＞
「打合せ資料を事前に読んで、質問内容や作業の検討をつけておく」
⇒予習して打合せを効率化させよう！
＜打合せの進め方＞
「予習内容を確認する」
「設計上で好ましくない箇所は代替案を提示する」
「設計書が出来上がっていない段階での打合せは行わない」
⇒自分主導で打合せを進め、相手の信頼を得よう！
＜ベースプログラムの選定＞
「見た目ではなく、構造が似ているプログラムを選ぶ」
⇒なるべく自分でコードを書かないようにしよう！
＜設計とベースプログラムの完全理解＞
「設計とベースプログラムの両方を理解して、後は走るだけ」
⇒理解するまでは動き出さないように！
ここまで読んで頂くと分かるかと思いますが、
「相手のことを考えて行動する」
「不安を事前に取り除く」
この２つの意識が重要です。
上記２つのために「時間」を徹底的に使うのです。
そのために使った時間は絶対に無駄にはなりません。
相手の信頼が高まれば、仕事のしやすさが段違いになります。
自分の提案が通りやすくなりますし、
困った時は助けてくれるようになります。
不安のない作業は、作業スピードを高め、ミスも少なくします。
ミスをなくすために、「デバッグを多めにする」だとか、
作業効率を上げるために、「ツールを使う」だとか、
小手先の技術ではないんです。
大事なのは「準備」です。
力を入れるべきところはコーディング前です。
これが「一流思考」です。
「時間を使うべきは常に前」
これを忘れなければ、
「相手の信頼」も、
「作業スピード」も、
「品質の良いプログラム」も手に入ります！
