ブログ

エンジニアHubで記述したこちらの記事「 チーム開発改善ガイド - プロダクト品質管理の課題と解決を実例から学ぼう」で、プログラムを図に書いて説明すると記述しましたが、よくどうやって図を書いたらよいのでしょうか？という質問や悩みを受けます。
本来は、自分でどう把握しているのか？という事を客観的に知る為の方法なので、好きなように記述すればよいです。
しかし、それでも書き始めがわからないという話も聞くのでプログラムを図にする際のトピックスについて記述したいと思います。

フローチャートを知る

今、プログラムを書いていてもフローチャートはすっかり記述しなくなりました。 自分で記述しているコードはフローチャートで書けるほど単純じゃないや手続き型ではない。などの理由があるかと思います。

それでも、1つの関数やメソッド内であれば小さいので、フローチャートだけで十分記述できると思います。
筆者もこちらの記事「LEGOで赤外線を使った自動走行プログラムを作ってみよう」を記述するにあたり、久々にフローチャートを記述しました。
このようなLEGOのツールは、それ自体でプログラムを作ること自体が、フローチャートを書くことに近いので、わざわざ勉強したくないと思っている方にはおすすめです。

境界線を書く

フローチャートとして図に書けるようになったけど、でも、今のコードはイベントだったり、スレットやプロセスが分かれているのでそんなに簡単ではないけど・・・という場合には、どこに境界線を引くかという事を意識するとよいです。

例えば、以下の2つの図を見てみてください。
これはある処理がデータを出力する事を示したものです。 しかし、処理とデータが別々の枠内に記述されているものと、同じ枠に記述してあり、この2つの図があれば、この枠は何なのか？という疑問に思うことでしょう。

つまり、自分はシステム内で何を境界として捉えているのか？という事が客観的にわかります。
別に、この枠が「スレッド」なのか、「プロセス」といったシステム上の境界なのか、「関数」や「クラス」のようなコード上の境界でもどちらでもよいのです。
自分も含めて、まず、理解するにあたって、何を前提として捉えればよいかが伝えられるわけです。

慣れて言えば、さらにもう一つの境界線を増やす、そして慣れればもう一つ増やすとしていけば、詳しく書けるようになっていけるはずです。
そして、図がごちゃごちゃとしてきたら、重要な線のみを残して、重要でないと思う線を消していけばいいはずです。

SVOの何を重要と考えているかを理解する

「SVO」って何？と思うかもしれません。あまり、プログラムを記述する際には、SVOなんていう表現はしないと思います。
ここで言う、SVOは英語の文法である「S（主語） + V（動詞） + O（目的語）」ですが、プログラムで言えば、以下のようになります。
人に説明する際には、このSVOが決まっていないと説明することは非常に難しくなります。したがって、コードを説明する場合にはこのようにSVOを意識する必要があるはずです。

• S・・・オブジェクト・モジュール等
• V・・・処理（メソッド・関数など）
• O・・・データ等

図でプログラムを記述するときに、このように「SVO」がどのような関係になっているかが表現するようにすればよいでしょう。
例えば、先ほどの図にSVOをつけてみると、以下のようになったとします。

これを説明しようとすると、あれ？なぜ「S」が2つあるんだ？となるはずです。または、左の枠だけに「S」と記述すれば、では右側って何とか、説明を受けた人が余計混乱するはずです。
そうすると、説明ができなくなるので、以下のように書き換えたりします。
このように、最初の枠はデバイス等などの物理的な境界線として補助線にすればわかりやすくなります。

図を書くためのツール

補足的に、よく質問される中に、どんなツールを使えば、図が書けるようになりますか？という質問も受けます。
今なら、タブレットでペンを使って図を書くのでよいと思います。
ちなみに、筆者は、「OmniGraffle」というツールを使っています。
Mac版しかないので、Windowsの場合でも使えるツールを探していますが、まだ、OmniGraffle以上のものは見つけられないでいます。