プログラマーSEの『図解』がうまくなるコツ

2016年10月12日に投稿 → 2018年7月5日に更新仕事術アフィリエイトリンクを含みます

表現力や説明能力みたいなものは長年の経験を積まなければ身につかないという話を聞きますが、私はそうは思いません。

仕事の能力の多くは経験の長さがなくても訓練によって伸ばせます。経験を積んで業界の知識が増えたからって図解がうまくなるわけでありません。

「経験が大事」って話は、ベテラン社員が威張りたいがために、

「仕事は経験が大事だ → おれは長年この業界でやってきた = おれは偉い」

って暗に言ってるだけだったりします。

または勉強不足なだけの人が「おれは経験年数が少ないから仕事できなくてもしょうがないんだ」って思うために「経験が大事なんだよな → 俺まだ経験少ないし → しょうがないよね」と自己正当化をしてるだけだったりもします。

こういうものの見方をすると、世の中には、

がさも正論のように言われていることが多いことに気が付きます。

このような偽物に惑わされず、自分を成長させることに集中していきたいものです。

それでは本題「図解がうまくなる方法」を紹介します。

Contents

たくさん書けばうまくなる？

図解がうまくなるコツはたくさん図解することです。

「え？経験積めってこと？さっきと言ってることが矛盾してるぞ」って？

冒頭で述べた経験はどっちかという「経歴」というニュアンスのものです。今言ってるのは、行動した回数っていう意味です。

スポーツとかでも練習した回数が多い程うまくなりますよね。仕事も同じです。

ソフトウェア開発で使われている図のなかでメジャーなものとしてUMLがあります。

2000年代には、

とまるで夢の道具のように喧伝されていたこともありましたが、「UMLを学ばなきゃ図解できない」ってこともありません。

図解するフォーマットを学ぶという意図でUMLを学ぶのが正しいスタンスです。

といっても、フォーマットを覚えただけで図解がうまくなるわけではありません。

それにUMLで書くものは用途が決まっています。

決まった用途に対して決まった通りに書く方法を学べますが、そこから外れたものだとうまく図解できないため、万能ではありません。

図解がうまくなるには、図解する機会を増やさなければなりません。

そのためには何にでも使えるシンプルな図の書き方が必要です。

文字と矢印と線と吹き出しがあれば、大抵のものは図解できます。

四角を書いて、その中に文字(名前)を書いて、矢印で他の四角と結んで関連性を示す、吹き出しで説明を書けば、立派な図です。

図解例1 これらの図はExcelやWordに元々備わっている表記なので、すぐにドキュメントとして残せます。

手書きで書く際にもかんたんなので、たくさん図解する「経験」を積めます。長い経歴がなくても意図的に機会を増やせば経験を積めるんです。

プログラムのバグを誰かに相談する時なんかにも「このプログラムがこのモジュールを読んだときにこういうエラーがあります」と図解できます。

図解例2

誰かに相談する時にはできるだけ短く済ませてその人の時間を奪わないことが重要です。相談する際には事前に図解したものを用意しておくと時間の短縮に役立ちます。

こんな風に、図解する機会を増やすことはいくらでもできます。

基本的に誰かに何かを話す時は全て図解するチャンスです。

相談する時だけでなく、誰かに相談されるときも、相手の疑問点を紙にささっと図解して、自分の意見も図解する、そうすることで話す時間の短縮にもつながるし、相手も理解しやすくなります。

ですから、ドキュメントを作るとか、プレゼン資料を作るといったことがなくても、図解しながら会話する習慣を作れば、グングンうまくなると思います。