【プログラム開発業界用語】エンジニアになる前に知りたかった6つのこと解説

この「ドロイドブログ」を運営しているゆーちゃまさんです＾＾

webアプリ開発３年ほど、その後Androidアプリ開発を10年以上、今も現役です。

プログラミングは勉強しているけど…

と思っている方、たくさんいらっしゃると思います。

僕も勉強しているときは「レビュー」ってなんだ？？とか、実際に仕事するうえで知っているべき用語を知りたいなぁー…

と思っていました。

現役でAndroidアプリを開発しているエンジニアの僕が

エンジニアとして仕事するうえで絶対知っておいた方が良い用語などをわかりやすく解説します。

ゆーちゃま

これを知っていると、初面談や初現場に出たときに周りの人の話について行けたりと、イメージつきやすく助かると思います！

参考になればうれしいです＾＾

結論：まずはこの6つを知っておこう

以下の6つを、エンジニアになる前に知っておいた方が絶対良いです。

これをはじめから知っているのと、知らないとでは仕事に慣れるまでの期間が短いです。

順番に解説していきます＾＾

リスケ

僕はエンジニアになる前は知りませんでした。。

今は、知っている方が殆どですかね？

例：「このXX画面開発、リスケしたんで来週一杯は開発期間として作業できます」

このような感じで使われます。

リスケジュールの略ですね。

決まっていたスケジュールを決めなおすという意味になります。

システム開発では、開発する前にスケジュールを組みます。

開発期間として2週間とスケジュールが組まれていたら、その期間内に開発を完了しないといけないんですね。

ただ、何らかの理由で終わりそうにない場合は、早めにアラート（報告）をして、可能であれば期限を延ばしてもらったりします。

ただ、リスケできない場合も多々あります。

リリース日が既に決まっていてスケジュールを延ばせないなどの場合ですね。

見積もり

例：「次に開発するXX機能開発、来週の開発ミーティングまでに各自見積もっておいてください。」

このような感じで使われます。

その見積りを元にスケジュールを組んでいくという流れになります。

因みに、エンジニアなりたての頃は見積りって言われても、どのくらいで出来るか正確にわかりませんでしたね。。

見積りを元にスケジュール組まれるので、ついつい長めにしちゃったり。。

初めは分からなくて当たり前なので、大体この機能を作るには5日くらいかなぁという感じで見積もっておけば大丈夫です。

長すぎたら「もう少し短い期間でつくれるんじゃない？」と修正されたりして適正な期間を提示されます。

工数

例：「XX機能開発の工数は5人日です。」

こんな感じです。

人日や人月という単位を使って、1人月というと、1か月20営業日と考えて20人日と表現します。

上の例だと、開発にかかるのは一人で5日かかるので、5人日と表現します。はじめは5人日とか言われたら、単純に5日開発期間があるんだなーという理解でOKだと思います！

チケット管理

例：「そのバグ、一旦チケットにしておいてください」

こんな感じですね＾＾

開発現場ではプロジェクト管理ツールと呼ばれるものを使用して、進捗などを管理します。

僕が今まで行った現場で使ったことのあるものは以下になります。

この辺は有名どころなので、使っているところが多いと思います。

チケット管理ってなんぞや？って感じだと思うので簡単に説明しますね。

僕はいまアンドロイドアプリの開発をしていて、大体1か月に1回のペースでアップデートをしています。

なので、設計・開発・テストを1か月で完了させる形になります。

で、それぞれの作業をまずチケット化して見える化します。

必要な作業を全部チケットにしてそのチケットに担当者を設定ます。

チケットは開発者だけでなく、デザイナー、プロジェクト管理者など作業がある人みんなチケットを作成します。

そのチケットは状態を設定することが出来るので、パッと見てそれぞれの作業が着手前なのか、作業中なのか、すでに完了しているのかが分かります。

大体そのチケット管理ツールでチケット一覧を画面に映して、チームミーティング。

残作業がこれだけあって、「今現在このチケットを作業中です」みたいな感じでメンバーそれぞれで報告する感じ。

これをもって、全体の進捗がいま遅れているのか、オンスケなのかが分かります。

最終的に、すべてのチケットの状態が完了になります。

レビュー

例：「開発一旦完了したので、レビューお願いします」

複数人で開発している場合、コードレビューをするのが一般的になってきてます。

簡単に説明すると、開発で書いたコードをほかの人に見てもらって、問題点などあれば修正して再度レビューをしてもらうって流れだと思います。

今はGitでソース管理するのが一般的だと思うので、Git上でソースコードをレビューするところが多いですね。

KPT

例：「振り返りやるので、KPT書いといてください」

リリース後などの振り返りの方法で、KPT法というものになります。

事前にこのKPTを考えておいて、ミーティングで話し合うという形で実施したりします。

これは現場によっていろいろやり方があります。

事前に書かずに、ミーティング室に集まってホワイトボードにそれぞれ書き出したりするところもありましたね。

この振り返りで、次の開発をもっと良いものにするのが趣旨になります。

まとめ

今回、メジャーな用語を簡単に説明させてもらいました^^

実際にエンジニアで現場に出る前にこのあたりの知識があるだけで、気持ち的にも全然楽になるとおもいます。

気になるものがあれば、調べてみても良いですね^^

↑押してもらえると励みになります＾＾

こちらの記事もどうぞ＾＾