■

内部仕様書はロジックを書くものではない
これを読んで、なんとなく思った事をつらつらと。

同期の別チームが、内部設計なのかどうか知らないがフローチャートを使って設計書らしきものを作ってたんだ。
Wordで、一生懸命、図形の形を整えてフローチャートを作ってたわけなんだけど……なんだかなぁ。

もうね、経験の足りない私が言うのもなんだけどさ。
仕様書とか内部設計書とかは捨てて、説明書だけ書けばいいような気がするんですよ。
ソフトウェアそのものの説明書、関数の説明書、クラスの説明書……要は何がしたいかをドキュメントに記述すればいいわけでしょ？
ソフトの説明書はお客さんが必要なものだし、関数・クラスの説明書はプログラマの意思疎通の為に使えばいい。
ただ、関数・クラスの説明書はあくまで概要だけ。関数・クラスの使い方のみを記述すればそれでいいと思うんですよ。
使い方さえ分かれば、あとは仕事を割り振られたプログラマさんが説明書にない関数・クラスの内部のロジックを決定していけばいい。
設計書に書かれたフローチャートや自然言語をソースコードに書き直す作業しかできないプログラマなんて要らない。それこそ自然言語をソースコードに落とすソフトを開発すりゃいいんだから。

……でもなぁ。プログラムの経験が少ない人だと、説明書から何かを生産する事ができないんだよなぁ。
同期がC++に不慣れだから、練習にstd::vectorを簡略化した動的配列を実装させてみたんだけど。
てんで出来ないんだよね。JavaのArrayListやLinkedListのような実装方法を初めに教えておいたんだけど、30分たってもstd::vector::push_backと同じ機能を持つメンバ関数の中身は真っ白。
まだソースが汚くても実装が出来る人ならマシ(なのかな？)なんだけど、実装方法がなーんにも思いつかない人にはどう対応すればいいか未だに分からない。
学生時代にもそういう友達がいて、チームで開発してる時によくその事を責めたもんだけど。
別の友達から「相手が知らない事に対して怒ってもどうしようもないでしょ？」って言われてしまった。指摘が的確すぎて何も言えんわ。
しかし、怒る以外にどう対応すりゃいいのやら……当人のやる気の問題だから、何も出来ないんだよなぁ。