SE・プログラマのお仕事の流れ　〜ヒアリングから納品まで〜

著者はエンジニア歴４年目のプログラマです。

社会人になってからプログラミングの勉強を始め、会社員としての勤務を経て現在フリーランスとして活動しています。

今回は経験をもとに、案件の具体的な流れと、大変だったことをまとめていきます。

案件の流れについて

プログラミングの案件は非常にざっくりいえば以下の流れで進みます。

大きな企業では分業されていることも多いようですが、規模の小さい企業では全てひとりで担当するケースも考えられます。

フリーランスの場合には基本的には、当然全て自分でやる必要があるわけです。

以降は①〜④での具体的な流れと、それぞれで大変なことについてまとめます。

ヒアリング・要件定義

「ヒアリング」とは？

ヒアリングとは、クライアントの作りたいものについて話を聞き、成果物の具体的なイメージを共有することです。

お客様によっては具体的なイメージが固まりきっていない方も多いです。

ここですり合わせをしておかないと、成果物とクライアントの求めるものがずれてしまうこともありますので、じっくり行いましょう。

あまりにも実現が難しいようだったり、作りたいものと予算に大きな乖離があったりした場合にはこの段階でお断りすることもあります。

ヒアリングで大変なこと

ウェブの知識が少ないクライアントには「何ができて何ができないのか」という判断はつきません。

なので、悪気なく「これくらいは簡単にできるよね」と言ってくることも多いです。

しかし、経験が少ないエンジニアには「何ができるのか？どれくらい時間がかかるのか？」の判断がつきません・・・。

新人エンジニアあるあるなのですが、「まあ調べりゃなんとかなるだろ」と安請け合いしてしまうと大変なことになります。

経験が少ないうちは「確認します」と一旦回答して、じっくり検討するようにしましょう。

「用件定義」とは？

用要件定義とは、クライアントの要望をまとめ、細分化し、どのように実現するかを考察する工程です。

クライアントにもよりますが、ヒアリングの段階では、基本的には「これをやりたい！」という要望だけを言ってくることがほとんどです。

それぞれの要望について、現状を確認した上で、問題を細分化し、具体的に解決方法・手段を考えるのはエンジニアの仕事です。

不明点があれば再度クライアントに確認しつつ、要件定義を進めます。

要件定義の事例

クライアントの要望

クライアント

HPに問い合わせフォームをつけたい！！

状況確認のためクライアントに質問

エンジニア

現状、HPは静的サイトか？WPか？
レンタルサーバはどこと契約しているか？

クライアントに確認しなきゃ！

クライアントの回答

・静的サイト

・レンタルサーバはさくらレンタルサーバ

要件定義①：要求を細分化

エンジニア

要求内容を細分化しよう！

問い合わせフォームに必要な機能は・・・

・フォームの表示

・メール送付

・問い合わせ内容を保存

要件定義②：具体的な解決方法を考える

エンジニア

各機能を実装する方法を考えよう

・フォームの表示：HTML・CSSで描画

・メール送付：PHPで実装

・問い合わせ内容を保存：MySQLで実装

要件定義で大変なこと

プログラマになりたての頃は、作業工程を細分化すること自体がかなり難しいです・・・

問題を小さく切り分けるという思考法に慣れていませんし、知識不足で切り分け方がわからないことも多いからです。

具体的な解決方法を考える工程については、調べればわりとなんとかなるのですが、それが効率的な方法かどうかを判断する必要もあります。

経験が浅いうちは、上司や詳しい人に一度確認をとったほうがいいでしょう。

料金見積もり

料金の検討

さあ、ヒアリング・要件定義を終えたら、いよいよ料金を考えることになります。

時間あたりの単価を決めて、何時間かかるかで掛け算して見積もり料金を決めます。

（例）時間当たりの単価：3000円、想定所要時間：4時間であれば・・・
　　　3000✖️4=12000円

クライアントに料金の提案・交渉

料金見積もりが完成したら、それをお客様に提案します。

もちろんお客様から「高い」という指摘をされることもあります。

というか、料金見積もりが一発で通るケースの方が珍しいです・・・。

しかし、安易に値引きをするのではなく、「作業を減らす」ことで料金を削減するようにします。

具体的には以下のような提案をするとよいでしょう。

このいずれかを提案すれば、作業量は減りますので、実質的には値下げをしなくても済みます。

提案事例

クライアント

う〜ん、ちょっと料金が高いかな・・・

提案例１：機能を減らす

エンジニア

DBに問い合わせデータを保存する機能を削れば、その分の料金をお安くできます。

提案例2：より簡単な方法の検討

エンジニア

問い合わせフォームではなく、クリック時にメールを起動するボタンを設置しますか？

それでよければ少々お安く作れます。

提案例3：一部の作業をクライアントに依頼

HTML・CSSで、表示を作成する部分について、お客様の方で作業をしていただければ、その分の料金を削減できます。

プログラミング

さて、ここまでの工程を終えて、ようやく実際にプログラミングをすることになります。

学習してある程度のスキルを身につけていたとしても、やはり勉強と仕事では違う点も多いです。

プログラミング学習と仕事との違い

締め切りのプレッシャーがある

「そんなの当たり前じゃん」と思われるかもしれません。著者も頭ではわかっていました。

でも、頭でわかっているのと実際にやってみて痛感するのでは大きな差があります。

仕事には締め切りが必ずあります。

しかもその締め切りは用件定義の際に自分で決めたものなわけです。（お客さんからの「なるべく急いで欲しい」というプレッシャーももちろんありますが・・・）

こちらで提示した期限を守れないとなるとお客さんからの信用に影響してしまうので、大きなプレッシャーでした。

避けて通れない課題がある

お勉強であれば、「これは今はわからないけどいったん後回しで」ということが簡単にできてしまうのですが、実際の案件ではそうはいきません。

「避けられない難しい課題」は必ず発生します。

対応すると見積もり予算の範囲を大きく超えてしまうような、難しい課題にこの段階で気づくこともあります。

必死に取り組んで解決することも大事ですが、お客さんに交渉することで回避することも可能です。

交渉する際には、「Aでは難しいのでBではいかがでしょう」のような代替案を提示することが大事でしょう。

プログラミング自体の能力はもちろん大事ですが、他の解決策を考えるという能力もとても重要なのです。

テスト

仕事では納品前のテストが必須

勉強だけであれば「わかる」「できる」ことが目的なので、細かい部分のチェックについてはどうしても手を抜きがちです。

しかし、実際の案件では、ミスに気づかないと取り返しのつかない事態が発生することも十分考えられます。

なので、テストを繰り返し行うことになるわけですが、これも大変です・・・。理想的には起こりうるパターンや異常系の動きも全て確認する必要があります。

一人でやろうとすると膨大な時間がかかることもあります。

会社員であればテストを周囲にお願いする。フリーランスであれば、お客様と共同でテストを行う等の対策が必要になると思います。

まとめ：とにかく周囲やお客さんに相談することが大事！

まだ仕事に慣れていないうちは、経験値が不足しているので想定外の事態がたくさん発生します。

会社員であれば周囲に、フリーランスであればお客さんに必ず相談するようにしましょう。

「なんとかしなければ」と一人で溜め込んでしまうと周囲もお客さんも対応ができません。

少なくとも「困っている」ことだけでも共有しないと、みんながスムーズに進んでいると思い込んでしまいます。

リスケジュールや仕様変更等、相談さえすれば打てる手がたくさんあるのです。

僕が経験した範囲では上司の方もお客さんも皆さんいい人で、いつも親身になって一緒に対策を考えてくれました。

とにかく困ったら相談することが大事です！