こんにちは、株式会社ZeroDivideの倉橋です。
今回はソースと設計書の関係から見えてくるものについて話していきたいと思います。
ソースと設計書の関係
プログラムの仕組みを解析する場合、設計書とソースは切っても切れない関係だと個人的には思っています。設計書は全体像や関連性を俯瞰するにはよいのですが、具体的な内容を詰めようとすると、それだけでは情報不足な感が否めません。逆にソースは仕様について具体性の塊ですが、内容を把握しようとすると読み解かなくてはいけないうえに理解が局所的になりやすいため、全体像を把握するまでに時間や手間がかかります。
これは私自身の経験から得られた知見ですが、設計書を使って解析作業を進めていくと、必ず何処かの時点で「設計書のこの記述って実際のソースではどうなってんだ？」と気になって、ソースに立ち返って確認を行うことが多くあります。かといって資料も何もない状態でいきなりソースを調べようとすると、一から読み解かなくてはいけないので、それはそれで非常にきつい作業なわけです。
そのため私自身は、設計書でプログラムの大まかな仕様を理解し、ソースを使って記述の詳細を理解する、というやり方が仕組みを理解するにはベストなやり方ではないかと思ったわけです。
こうした「設計書を見ている時にソースも閲覧できる」みたいな機能は実装予定もあって、TrinityにはZDFと呼ばれる弊社独自の設計書フォーマットがあるのですが、これのビューアーにソースの表示機能をつけたら便利じゃないかと考えていたのです。
いつ実装するかは未定だったのですが、最近お客さんからこの機能について要望をいただきました。そこで次のリリース向けに、ZDFではなくExcel設計書ではありますが、ソースとのリンク機能を実装しました。Excel設計書の一番最後のシートには「関連資料」というプログラムで使用されているファイルや画面などの設計書へのリンクのリストがあるのですが、ここにプログラムソースへのリンクを加えることができるように機能追加を行いました。今後、Excel設計書を使っているお客さんは、設計書からプログラムソースを簡単に呼び出せるようになりますので、解析の手間も軽減されるのではないでしょうか。
解析に設計書は不要か？
Trinityで自動作成された設計書って、見方によってはソースの解析結果をわざわざ文章化したモノと捉えることもできます。
以前、ある販社さんで製品のデモを行った際に「解析はツールがあれば十分で、設計書は不要」と言われたことがあります。これはツールで解析を行うわけですから、わざわざ結果を設計書のような形式で残さなくてもよい、という意味なわけです。解析結果については必要な情報を必要な範囲で確認するだけなので、むしろ設計書の形式になると見づらい、というわけです。
実際、Trinityでも分析や調査を行うために目的に応じたさまざまなツールを用意しています。私自身も調査などが中心であれば、設計書を見るよりもツールを使用したほうが手軽であると考えています。ツールで調査した結果をエクスポートして資料化することもできますので、そちらを使った方が専用性が高いようにも感じます。
そう考えると、できあがっているシステムについて設計書は不要なのでしょうか？
私自身はそうは思っていません。なぜかと言えば「ツール」と「設計書」には大きな違いがあるからです。
ツールと設計書の違い
個人的に「ツールと設計書」の関係は「カーナビと地図」の関係に似ていると思います。
カーナビは目的地までの最適な道順を示してくれますが、あくまで必要な情報をフィルタリングして表示します。一方、地図は自分で道順を見つける必要がありますが、全体を俯瞰することもできますし、付近の状況や施設の配置などの関連情報を知ることもできます。
たとえば私はよくYouTubeを見るのですが、私と子供とではリストアップされるコンテンツがまったく異なります。なぜかと言えば私の好むコンテンツと子供の好むコンテンツが異なるからです。
ご存じの通り、YouTubeでは視聴者が興味を抱くコンテンツを次から次へと薦めてきます。結果としてリストアップされるコンテンツは確かに私が興味を持つものなのですが、残念ながらそこに広がりはありません。そんな時に子供向けにリストアップされたコンテンツリストを目にすると、まったく傾向の異なるコンテンツが見つかるため「へぇ～、こんな面白そうなコンテンツもあるのかぁ～」といった感じで興味の範囲を広げることができます。
人間って今の自分が楽しむためのコンテンツを求めるとともに、新しい刺激も求めていると思うんですね。そういった意味で、その人が将来興味を持つ可能性のあるコンテンツも提案してくれればいいのですが、現在のYouTubeのAIはさすがにそこまで進化はしていないみたいですね。
話が少しそれましたが、要は「ツール」というのは目的をもって調べるには向いているけど、そこから新しい発想を紡ぎ出すのは難しい、ということです。たとえばある会社のシステムには実は面白い情報をため込んでいるけど、そのため込んでいることを開発者自身が忘れていれば「ツール」では調べようがないということです。
逆に設計書で全体を俯瞰すると、自分が忘れていたシステムの姿が見えてくることがあります。私自身も長年Trinityという同じ仕組みを触っていますが、機能追加などで仕様を調べている時に開発資料などを読み返していて、「そういえばこんな仕組みも実装してたなぁ～」と再発見することがありますし、「あれ？この仕組み応用すればこんな機能が実装できんじゃね？」といったひらめきにつながることもあります。
そういった意味でも、ソースとは別に整理された資料の存在というものは非常に大切だと思っています。ふだんはソースの中に埋もれてしまっている自分たちの作ったお宝を発掘するための、まさに「宝の地図」になることだってあるわけです。
「Trinityで設計書を作ろう」と考える人たちと会話すると、「資料の大切さ」というものを具体的な言葉にしなくても本能的に理解しているんだなぁ～と、少なからず感じることがあります。そういった人たちに、今後も便利に使っていただけるような製品を提供していきたいと思っています。
気づきをもらい、コツコツ実装
