ITエンジニアの仕事の勘所について⑥

全工程共通

ゴリゴリとコードを『書く』のがエンジニア!?エンジニアが一生懸命文書を『読む』ことについて

みなさま。
さてさて、WordPressによるブログ投稿第二十五弾を書いている加賀美(カガミ)です。
どうも、おはようございます。

さて、勘所シリーズ第6弾は『エンジニアが文書やコードをちゃんと落ち着いて読むこと』、
そのことの重要性について書きたいと考えております。

みなさまはエンジニアって、安野モヨコさんの『働きマン』の主人公が記事をひたすら書いてるみたいに、コードをひたすらバリバリ書いてるイメージがございませんでしたか?

実はそれはそれで半分当たっているのですが、違う側面もあるのです。
本日はそんなお話になります✨

ドキュメント地獄!?ごく普通のシステム開発について

さてさて、カガミのこれまでのエンジニア人生の大半は、古いしきたりに縛られた昭和風のお仕事スタイル(とある仲の良いツィッター仲間はこういった人たちを『平成ジャンプ』と呼んでいるwww)のSI業界ど真ん中なんですが、そのSI業界では、ほとんどの案件が『ウォーターフォール開発』となっております。

これ、『自分が理解できないものは投資しない』というウォーレンバフェットさんではございませんが、つまるところそれがシステム開発をする上で最も無難な道だからなのかなぁとカガミは考えております。。。

と、話が脇にそれてしまいましたが、そのような古い体質のシステム開発のエンジニアの場合、要件定義書や基本設計書、詳細設計書やテスト仕様書など、大量のドキュメントを読み込む必要が出てまいります。

ふ~ん、そうなんだ。。。。と、軽くご納得して済むお話しではございません。

システム開発で使われるドキュメントの大半は、お仕事の手順が書かれたマニュアル含め大量の『修正』が入っており、非常に読みにくい書類となっているのです。

ですので、あえて『勘所シリーズ』で申し上げるまでも無いことなのかもしれませんが、この『落ち着いて読む』スキルがエンジニアとして、とてもとても大切になってくるのです。。。

かくいうカガミ自身は実はこの『落ち着いて読む』ことが大の苦手で、勘違いを産みやすい、まるでワナが張り巡らされたようなシステム開発のドキュメントでしょっちゅう勘違いをしてきております💧

まぁ、そもそもそんなドキュメントなのだからミスや誤読をしてしまっても大丈夫だよ、ドンマイだよという文化というか雰囲気があると現場のエンジニアも安心してお仕事にまい進できるかと思いますが、現場の上司にあたる人たちからは『あれ、そのこと書いてあるじゃん』と一蹴されてしまうことが大半です。。。はい、マジで『ググれカス』の世界ですね。。。

けれど、人間関係やコミュニケーションって大半は非対称な世界というか、カガミ自身も逆の立場のとき『ちゃんと仕様書に書いたのに!』って思ってしまうときがございます。

つまり、『書いた人』は、『ちゃんと書いたから大丈夫だろう』と考えがちで、
反対に『読む人』は『読みづらい』あるいは『読んだけれどよくわからない』となりがちなんですよね。。。

これで大丈夫!?エンジニアが読むことのスキルを上げる方法について

はい、今回もとりとめもなく駄文をダラダラと書いてしまいましたが、『読むこと』についてのカガミなりの対処法をお伝えしたいと思います✨

あまり参考にならないかもしれませんが、よろしくお願い致します✨

同じ文書を2回以上読む

はい、『そんな時間ねぇよ!』ってツッコミが来てしまいそうですね💧
けどカガミがこれまで経験した現場では、お仕事の始めの時にそれなりに導入教育の時間が用意してあったりして、その期間にカガミは基本設計書など少なくとも2回は読みます。

もちろん、読んで終わり、ではなく現場のエキスパートに『訊くこと』もしなくてはなりませんが、よく読んでも無いのに変な質問をすると、『あ、コイツ使えないな』と思われてしまいます。

けれども、少なくともカガミの場合は『それ、仕様書に書いてあるじゃん!』とツッコまれないくらいに理解するには、2回くらい読み込む必要がございます。。。

読んだ後、確実な「EOF」と思えるところを探す

はい、ちょこっとエンジニアっぽい3文字言葉が出てきましたねwww
「EOF」とは「End Of File(エンド・オブ・ファイル」)と読みまして、ファイルなどの終端を表す言葉です。

で、何をお伝えしたいのかと言うと、前章で「勘違いを産みやすい、まるでワナが張り巡らされたようなシステム開発のドキュメント」などと書きましたが、たとえば、Excelで書かれた作業のマニュアルなどなら『[Ctrl]+[End]キー』でシートの中のデータが入った終端に飛ぶことができます。

つまり、慌てて読んで後から『あれ?この手順書ここまで書いてあったんだ!』とならないように、なにか確実な方法で『書いてあることを終わりまでちゃんと読む』クセをつけることです。

まぁ、そもそもそんなドキュメント、本来ならば誰かがちゃんとメンテナンスすべきなんでしょうけど。。。

よく読んで、100%わかったつもりであってもちゃんと『訊く』

はい、最後になりましたがつまるところこれが一番重要!?

自分の読解力を信じないで、内容についてちゃんと有識者に訊いてしまうことです。
読むことの対処法ちゃうやんとまたまたツッコまれてしまいそうですが。。。

まぁ、つまるところ、『僕は優秀なエンジニアです!』みたいなアピールやプライドは捨てて、ちゃんと確実に理解しているつもりでも文書を読んで理解した(つもりの)内容の認識合わせをしましょうね、ということです。

ことわざにも『聞くは一時の恥聞かぬは一生の恥』とありますもんね。
はい、ことわざなんかを引用するカガミは典型的なお説教好きの中年エンジニアです。。。。

結びに

今回はエンジニアとしてやってく上で、『ドキュメントやコードを落ち着いてちゃんと読む』ことの大切さについて投稿させて戴きました。

どうでしょう?
みなさま、面白かったでしょうか。

さて、今回の投稿内容はドキュメントについてばかりで、コードについてあまり書きませんでしたが、保守開発など他人が書いたコードを読まざるを得ない機会もエンジニアにはたくさんございますので、ちゃんとコードをよく読む、落ち着いて読むスキルも当然エンジニアとしては必要になってまいります。

以前書いた『差異に気づく』とも連動しますが、コードに書かれた微妙な違い、のようなモノが、実はプログラムのバグの原因であったりするので、実にエンジニアは『書くスキル』よりも『読むスキル』の方が重要なのかもしれません。

『書くこと』についてはけっこうググればサンプルコードがたくさん見つかったりするので。

なお、余談ですがエンジニアがエディタやIDEなどを『背景真っ暗』にするのは、大量のソースコードを読むので読んでて目が痛くならないようにするためなのだとか聴いたことがございます。

ホントかどうかわかりませんが💧

ちなみにカガミはエディタもIDEも必要以上にはいじらないタイプです。
つまり画面真っ暗とかやりません。

シンプルイズベストな考え方です。

ちなみにカガミとはちょっとタイプが違いますが「Seasar2」の開発者・比嘉康雄さんも愛用のテキストエディタとかそういった事にまったく興味が無いらしいですね。

まぁ比嘉康雄さんを引き合いに出すなんて恐れ多いですけど💧

最後の最後に、ぜひ本ブログも、『最後の最後』までお読みくださいね✨

次回は、『身体を動かす』をテーマに投稿をする予定です。

それでは、今回は以上となります。
最後までお読み戴きありがとうございました。














私たちみんなに、今日も良いことありますように✨✨✨

タイトルとURLをコピーしました