第1回PM97勉強会の司馬の資料

1. テーマ２３：
巧妙なコードはメンテナンス困難
～東証事例を考える～
司馬 紅太郎,PMP,CISA,IT,PMP,CISA,IT,PMP,CISA,IT,PMP,CISA,ITコーディネータ etcetcetcetc
2013.04.23 「プロマネが知るべき９７のこと」をネタに勉強会 第一回

2. 注意事項
このテーマは、あくまでも議論のネタとして
堤示するものです。苦情・くれーむは勘弁し
てやってください。
また、プレゼンテーションを見るには、画面
から３ｍ以上離れて、見やがってください
CopyRightは当然shiba_koutaroなのですが、
もしフリー素材でない場合には、m(..)mです。

3. 司馬の自己紹介（意味ないですが）
司馬 紅太郎（ペンネーム）
本業は大手ＩＴ勤務。
資格はＰＭＰ、ＩＴコーディネータ、ＣＩＳＡ、
OracleMaster 等
ＰＭが専門ですがソフト開発全工程（運用含）、監
査、他も経験。
主要著作
「空想ﾌﾟﾛｼﾞｪｸﾄﾏﾈｼﾞﾒﾝﾄ読本」技術評論社
「ニッポンエンジニア転職図鑑」幻冬舎
「SEのための金融の基礎知識」JMAS 等

4. 巧妙なコードは将来のメンテナンス問題を引き起こす
開発者が新しい言語・ツールを導入することは悪いことではない
But もちろん懸念もある。本当に解決策になるのか、効果的か？要員は確保できる
のか？ Etc
但し、
コードに変更がある場合は、必ずドキュメント化する必要がある。
コードとドキュメントが枝分かれ
→システムを理解するにはコードが一番という間違った考えを導く
∴ソフトウェアコンポーネントとシステムメタデータの「結合の喪失」
複雑すぎるほどの巧妙はＮＧ
→後に続くひとが コードを読めないと、どうやってメンテナンスする？
悪質プログラマは、巧妙に作り、リピートを狙う（自分以外のメンテ不可）
1.テーマ２３：巧妙なコードはメンテナンス困難
要旨

5. 巧妙なコードは将来のメンテナンス問題を引き起こす
開発者が新しい言語・ツールを導入することは悪いことではない
懸念
１．新しい言語やプラットフォームは解決策になるのか？
２．既存システムとの整合性は長期にわたって保証されるか？
３．チーム内に開発者はいるのか？
４．製品サポートは受けられるのか？
など
但し、
コードに変更がある場合は、必ずドキュメント化する必要がある。
コードとドキュメントが枝分かれ
→システムを理解するにはコードが一番という間違った考えを導く
∴ソフトウェアコンポーネントとシステムメタデータの「結合の喪失」を生み出す
悪質プログラマは、巧妙に作り、リピートを狙う（自分以外のメンテ不可）
→システム開発のベンダーロックと同じ。既存ベンダー有利
2.テーマ２３：巧妙なコードはメンテナンス困難
ちょっと解説
リスクは
あるが、
基本ＯＫ

6. 3.ちょっとテーマからはずれて
最近、ネットで話題になっている
「みずほ証券ｖｓ東京証券取引所」の裁判。
面白いことになっています

7. 4.誤発注裁判をめぐる経緯
http://itpro.nikkeibp.co.jp/article/COLUMN/20130325/465906/?ST
=system&P=2

8. 5.控訴審におけるみずほ証券と東京証券取引所の主張
http://itpro.nikkeibp.co.jp/article/COLUMN/20130325/465906/?ST
=system

9. 6.控訴審におけるみずほ証券（青字）と東証（赤字）の主張
http://itpro.nikkeibp.co.jp/article/COLUMN/20130325/465909/
みずほ証券がテストの件に加えてもう一つ、東証の重過失に当たるとしたのが「システ
ムの開発手法が適切ではなかった」点だ。開発ベンダーに適切な開発手法を求めな
かったため、発注者である東証も責任を免れないとする。
開発手法が適切ではないことを説明するために、みずほ証券は具体的な事例を示し
た。東証がソースコードを修正する際に、「モジュール詳細定義」などのドキュメントを
修正していなかった点だ。
東証はこの事実を認めた上で、「一旦コーディングが済めば、その後の修正は、全て
ソースコードを中心に行うことが最も効率的であるから、モジュール詳細定義を改訂し
ていなかったことに問題はない」と反論した。「コーディングが済めば、ソースコード自
体が、最も詳細なドキュメントである」というわけだ。
これに対してみずほ証券は、ソフトウエア工学の専門家による意見書を引用し、こう
した東証の主張を真っ向から否定した。「システムを保守する者はドキュメントを見な
いというのだろうか。コードだけが頼りというのでは、ソフトウエア工学が長年にわたっ
て培ってきた知見をすべて無視することになる」として、東証の主張を「暴論」と切って
捨てた。

10. 7.（いろんな意見）詳細設計書が滅亡しない理由
http://d.hatena.ne.jp/kagamihoge/20100220/1266624446
プログラミングに必要だと誰かが言うけれど、邪魔にしかならない詳細設計書
詳細設計書の話に入るがこれに何が書かれているかというと、暴論承知で言うと、プログラムのコードと一対一
で対応する自然言語の記述である。ただし実態は、一対一で対応する「ことになっている」というだけの代物で
ある。プログラミングするにあたっては役に立つことはあまりないどころか邪魔になる。詳細設計書の問題点に
ついては、比較的最近のエントリでは 詳しすぎる詳細設計書 - SiroKuro Page が参考になる。
Excel 方眼紙と詳細設計書の極悪な蜜月関係は少なくとも 2001 年頃には認識されている*1。想像ではある
が、90 年代には既に Excel 方眼紙と詳細設計書でソフトウェア開発回すのはムリがあるんじゃないの、とはみ
んな薄々感づいていたのではないかと思う。問題点ありまくりのこれらはそろそろ退場していてもいいはずなの
だが、今でも方々から悲鳴の声が聞こえてくる。というか、俺もつい数ヶ月前まで悲鳴を上げていた。
詳細設計書は現代版コーディングシート
俺が詳細設計書に出会ったことがあるのは、三つの異なるプロジェクトで三回。それぞれ取引関係なんかは全
くことなる三つの元請の下でのとである。<<略>>。10 年前も詳細設計書にイライラしていたのを良く覚えていて、
以来、詳細設計書とは何なのか？ なぜ書かなければならないのか？ という疑問はずっと無くならなかった。
それで、三つの異なるプロジェクトで「なぜ詳細設計書が必要なのですか？」と先輩や上司に聞いたことある。
返ってきた答えは「詳細設計の工程では詳細設計書を作ることになっているから」「元請が詳細設計書を要求し
ているから」だった。新人のころは「それがソフトウェア開発というものだ。新人のお前にはわからないだろうが
10 年泥のように働けばそのうちわかる」というのはちょっと脚色入ってますがそんなような有難い説教を賜った
記憶すらあります。それで、詳細設計書は何なのかという問いに対する俺の仮説なのだけど。詳細設計書は
コーディングシートなのではないか？ と考えるようになった。この前提を置くといろいろなことに辻褄があうよう
な気がするのです。<<略>> 詳細設計書は百害あって一利なし……作る内容によっては一利ぐらいはあるか
もだけど。コンピュータの性能が上がり利用コストが劇的に下がった現代においては、詳細なロジックを実行不
可能な自然言語で記述して人間が逐一検証するより、とっととコンピュータ上で動作してコンピュータで検証で
きることはガンガンコンピュータにやらせたほうが合理的だ、との意見に異を唱える人はまずいないでしょう。

11. 8.（いろんな意見）ドキュメントの重要性 BY ソフテック
http://www.softech.co.jp/mm_090916_voice.htm
そもそもなぜドキュメントを作成する必要があるのでしょうか？ドキュメントの利点や有効な点にはどんなものが
あるでしょうか？私は以下の点があると考えます。
（1111） 情報の整理ができる
ひとつの開発の中では、たくさんの情報を取り扱うことになります。たくさんの情報は分類して整理しないと頭の
中だけでは処理し切れません。また、情報を整理しているうちに頭の中も整理することができ、情報の過不足、
矛盾等の発見をすることができます。
（2222） スムーズに作業ができる
（1）で情報が整理されるので、その後の作業がスムーズにできます。事前に情報の過不足、矛盾等を発見・修
正できているので後戻りも少なくなります。
（3333） 情報を共有できる
作成したドキュメントを公開（ソフテック社内であればLotus Notes※で公開）すれば、複数人で作業する場合に
同一の情報を共有できます。（1）（2）の利点も同時に共有されることになります。
お客様に提出するドキュメントの場合でも、広く考えれば「お客様と情報の共有をしている」ということになります。
（4444） 振り返ることができる
開発時のみだけではなく開発後にも内容を振り返ることができます。例えば同じような開発を行う場合、内容や
方法の流用ができたり、反省点・改善点を組み入れたりすることができます。
（5555） 担当者の変更が可能
なるべく1つの開発に関わる担当者は変わらないのが理想ですが、種々の理由で担当者が変更になることが
あります。そんな時でもドキュメントを作ってあると、それを基に他の担当者に開発の引継ぎを行うことができま
す。
これらの利点を生かすには、必要な情報が適切な形で記載されているドキュメント、つまり『質の良いドキュメン
ト』が必要になってきます

12. 9.素直な意見
Hello Worldと表示
Main()
{
printf(“Hello,World”);
}
・設計書とコードは対では？
・なぜ片方だけ修正するの？
・成果物の整合性が取れなくなるのです

13. 10.ひねた意見
Hello Worldと表示
Main()
{
printf(“Hello,World”);
}
この情弱爺（JJG）は設計書しか見
ないのですよ、コードだけ正だと
読んでくれないので意味がない
横文字は
わからん
和文はわかるじょ
あとパワポも

14. 11.もういっこ。品質管理の観点から
ＩＦ設計 運用設計機能１設計
機能２設計
プログラム間・サブシステム間・システム間
の整合性をどうやって確認するのか？
コードを全部読むの？

15. Let's
discuss it