【文系ＳＥの読書ノート】SE・プログラマの思考に必要なこと - 新卒から文系エンジニア→人材業界に転職した人のブログ

本日、以下の本を読んだ。

たまたま書店でおもしろそうだなーと思って手にとったわけだけど、

これを機会に、プログラマやSEに必要な思考ってなんだろうなーと考えてみたい。

PGに対して、Javascript・php・javaをほんのかじる程度の経験と

現場のSEの方々と一年ほど接した経験、

それに本を読んだ感想から。

具体的には、

作業が与えられたら、とりあえず全力で行うのではなく、まず作業全体をみる

作業全体をみるというのは、作業のボリューム感・作業の洗い出し。ステップ化を

行うということ。

　これが行える人は、全体が見えているから

　・ソース全体をみても処理の共通化や分岐などが整理されているイメージ。

　・進捗を聞いても、全体の何割というのが根拠を持って返ってくる。

　
　逆にとりあえず全力で取り組むという人は、

　　・全体がみえていないため、ソースも処理の共通化・分岐などがいきあたりばったりなイメージ
　
　
※これはＰＧに限った事ではないかもしれないが、人月で管理されながら期待された品質の成果を
　あげる職業では特に必要なのかも。

　若干、ステップ化という意味で①かぶるところがありますが、、、
　
　自分もＰＧしてて思うし、現場でがりがり書いてるプログラマの方からも
　
　なるべく行いたい処理を部品化・細分化した方がよい
　
　ということを言われました。
　
　

　ある処理を行いたいというときにそれを

　　・なるべく小さくする
　
　　・小さい部品から一つ一つ作る
　
　というイメージ
　
　
　
　やはり、現場で進捗を報告するときにステップ化を行っていれば、
　

　全体から見て自分がどの位置まで処理を作成できているか明確になります。

　
　最悪なのは、処理のステップが見えていないために、
　
　
「あとすこし、あとすこしでできる」ということをいいながら、

　
　大幅に完成が遅れる事例かなと思います。
　
　
　

モレの具体例としては

・条件分岐の考慮漏れ

　　・データパターンの考慮漏れ

　　・テストパターンの考慮漏れ

　　・仕様調整モレ

　　などなど

　　無駄の具体例としては

　　・重複しているドキュメント（二重管理）

　　・重複しているテストパターン

　　・目的のない・惰性で行っている作業

　　などなど

　　こんな漏れや無駄ってほんとに現場であるのかなーと思う方もいるかもしれませんが、

　　あります、たくさん。ほんとに。

　　
　　原因としてはさまざまなものがありますが、

　　・複数人での作業（コミュニケーション齟齬）

　　・開発中やテスト中も仕様の変更（微調整から大規模な変更まで）

　　などが大きいのかなという印象です。
　　

　　
　　その中でも、各工程で漏れや無駄があることによってpj全体の

　　効率が著しく悪くなる（手戻りなど）

　　ということを強く危惧し、漏れや無駄が起こることを

　　かなり神経を使いながら仕事を行う必要があると思います。
　　