人の脳を無駄にしないために、ソフトウェア開発は可視化が必要 (ShanonAdventCalendar2016 - 14日目)

このエントリーをはてなブックマークに追加
こんにちは、輝です。
今日は、下記をお題として投稿させていただきます。

人の脳を無駄にしないために、ソフトウェア開発は可視化が必要だ!

人間の脳はただのコンピュータじゃない、人間の脳は論理的思考以外に、直感力、図形力、全体を見渡す力、空間認知力などの能力もあります。ソフトウェア開発で開発プロセスやソフトウェア自体を可視化することによって、これらの能力をより一層生かすことができ、ソフトウェアの品質や開発効率に貢献できるはずに間違いがない。

WIKI(※)によると、可視化とは、人間が直接「見る」ことのできない現象・事象・関係性を「見る」ことのできるもの(画像・グラフ・図・表など)にすることをいう。視覚化・可視化情報化・視覚情報化ということもある。英語の "visualization", "visualize" に相当し、そのままビジュアリゼーション・ビジュアライゼーションと称されることもある。流れの可視化のように分野や領域に結びついて生まれた呼称も多い。

上記の可視化に関する定義には2つのポイントがあります:
①人間:可視化は人間の立場で言うものであり、人間のための可視化である。
②「見る」というのはある視点や目的の「見る」、単純な物理的な「見る」ものに限らない。分かるや理解と認識すれば無難でしょう。

可視化という概念は場面によって違う意味がします。地図は皆よく分かるその一例です。地図は人間が分かりやすくするために、一定の地域の状態を縮尺して平面に描いた図です。
※下記は日本の地図です。

誰も分かると思いますが、町が大きければ大きいほど地図が必要になるのです。数十人が暮らしている小さな村であれば、数分~数十分かからなくても一周回ることができ、地図が無くても大丈夫だけど、東京のような大都市であれば、地図が無いと初めて訪れた旅人は困るでしょう。

ソフトウェアも同じです。町は建物や道路で組み合わせて作ったものに対して、ソフトウェアはソースコードや配置ファイルなどで組み合わせて作ったものです。

地図が無い場合どうなるでしょう、考えてみよう。
初めてニューヨークに尋ねる場合どうなるでしょう。飛行機でニューヨークの空港についたら、次は泊まりのホテルに行きますね。ホテルのアドレスが知っているけど、地図が無いのでどうやって行けるかは分からない。ほかの人に聞くか、試行錯誤で行ってみようかと思われますね(ここは案内人がいるか、タクシーに乗ることは地図があると同等)。ニューヨークは大きな町ですから、結構苦労になるはず!

地図があれば、簡単に地図で示した通りに到着することができるでしょう。ガイドやタクシー乗ればも簡単に行けると思いますが、実際には地図と同じ役割ですね。
※下記は、地図(ゴーグルマップ)におけるニューアーク・リバティー国際空港からシェラトンニューヨークタイムズスクエアホテルまでのルートです。湾もあるので、地図が無ければ無事に到着できるのでしょうか。

なぜ地図があればより簡単に行けるのか、地図は町を人間に対して分かりやすく可視化したものです。

ソフトウェアは、最初に何人ぐらいのチーム規模で検討しながら作られ、その時にソースコードが数千行から数万行の規模で、システム構成図やコントロールフォロー・データフローなどを表す設計文書がなくても分かるものかもしれないです。なぜならば、その時のソフトウェアは小さな村に相当するものなんです。この村(ソフトウェア)に暮らしているのはそもそもこの村(ソフト)の創造者(開発者)がほとんどです。また、外から訪問者が誰かの家を探す時に、ちょっと歩いて探したらすぐに見つかるのも困難ではありません。もちろん、この時に地図があれば助かるのですが、無くても特に支障がないでしょう。

話はちょっとずれますが、約1千年前に、中国の上海市はただの小さな村でした。ただし、時が経って、今の上海は2千万人以上の人口を持つ世界中でも有名な大都市に発展してきました。
※下記は上海は小さな漁村から大都市へ変わった様子を示す図です。

ソフトウェアも、時が経って機能がどんどん実装され、規模も膨大になりつつ、複雑度も高める一方です。それだけではなく、開発者は離職したり、新人が入ったりすることによって、ソフトウェアの作りに詳しい人が逆にどんどん減っていくでしょう。人が安定としても、時間が経って自分が作ったものであっても、どういう作りだったか忘れることも珍しくありません。こんな中、新人にとって、数万行から数十万行のソースコードは、一体どういう構成になっているのか、各モジュール間、モジュール内部のコントロールフォロー・データフローなどはどうなっているかは、上記に書いたニューヨークに訪れた地図の無い旅人と比べて、同じ苦境に陥るとは違いないはず。地図があれば、30分でホテルに到着できるのに、地図が無いせいで数時間でも道に迷う可能性もあるでしょう。

具体的に、可視化しないと困り事は何なのかを幾つかリストアップします。可視化にすることで下記の問題やリスクを解消できるか軽減できます。
  • モデリングなどの手法により複雑な課題を可視化しないと、対象問題の本質を認識しにくい
  • システム全体図や構成が見えない、ソースコードだけで情報交換が難しい
  • 設計変更がある場合影響範囲が把握できず、障害が発生する確率が高くなる
  • 既存のソフトウェアをベースで機能を追加時に、既存の仕組みが見えないため開発効率が悪い
  • 保守が難しく、障害が発生時に問題を特定しにくい
  • 新人を導入するのが難しい
  • 人に依存しがちであり、人員流動によりソフトウェアの品質が不安定になりやすい

いろいろ言いましたが、可視化の例として、下記は可視化なしと可視化ありの場合、開発効率の変化と障害発生率の変化の図を作りました。パッと見れば言いたいことが分かるでしょう。
※可視化の手法や程度などによって具体的な数字も変わるため、下記の図は傾向という意味を表すだけのものです。
1.障害発生率の変化
可視化ありの場合には障害発生率の比較的に緩やかに増えることに対して、可視化なしの場合には機能が増えれば増えるほど障害発生率は随分上昇する一方です。

2.開発効率の変化
可視化なしで、最初は可視化による工数が発生しないため、効率が可視化ありの開発よりある程度高いことに対して、僅か数年も経たずに、障害の発生やシステムの不透明のせいで、可視化ありの開発より開発効率が低下してしまう。


じゃ、ソースコードが見えるものであり、それを見ればいいじゃないという見方の方もいらっしゃると思いますが、それは本当に大丈夫でしょうか。
絶対だめとは言えませんが、一般論として普通の人間にとってそういうやり方は不適切です。見えるものは可視化したものとは同等なものではありません。
chengxuyuan.jpg

ソフトウェアのソースコードを作成するプログラミング言語の歴史によると、最初の機械語からアセンブリ言語へ、その後fortran言語やc言語のような手続き型の言語へ、さらにjava言語やc#のようなオブジェクト指向の言語に進化しつつあるが、ソースコードはあくまでもコンピュータ向けなので、コンピュータのことを考慮しなければなりません。一番読みやすいプログラミング言語でも人間の言語より分かりにくいでしょう。人間の言語で作った雑誌やチラシの場合でも、図や表などを飾って、読みやすくするのが一般的です。一番読みやすいプログラミング言語であっても、人間の言葉より読みにくいものなんで、むしろもっと可視化すべきに違いがないです。極端の話、最終的にはプログラミング言語が人間の言語と同じようになっても、更なる可視化の工夫も不可欠です。

なぜならば、開発者は人間だからです。人間の思考は処理できる分類はだいたい3つが限度であるという言い方もあります。3つという数字は本当に正しいかどうか私も判断できませんが、一般的に、人間の脳はコンピュータのメモリとCPUと同じように同時に格納・処理できる情報は上限があり、ものの数や種別が少なければ少ないほど分かりやすくなるでしょう。数や種別が多くなると、更に分類するか抽象することによって数を減らして分かりやすくさせるべきです。例えば、地球に1人しかいない場合、何も分類する必要がありません。今は地球の人口は60億人以上もいるため、ある人は誰であるか特定するために、まず国籍で分類するでしょう。同じ国の人だと、更に(日本人の場合)県や市や町などで分類するでしょう。

※下記はアンドロイドのシステム構成図です。この図があればアンドロイドのシステム構成が分かりやすくなるでしょう。これらの情報を得るのにソースコードを読めばどれぐらい時間がかかるのでしょうか

ソフトウェアも同じく、ソースコードが数千行まではまだ読めますが、1万行以上であると、開発者本人以外だとわかりづらくなるでしょう。その場合何らかの手段によって更に分類、抽象して可視化にする必要があります。普通OO(オブジェクト指向)のプログラミング言語だと、パッケージ名やクラス名やメソッド名によってソースコードをある程度も分類していますが、それぞれが独立したもので、お互いにどのような繋がりであるか見えません。手段にこどわる必要がないと思いますが、一般的にはUMLが世界中で通用のモデリング言語でしょう。UMLを使う場合、クラス図などで静的な構成、シーケンス図など動的な構成をモデル化することで、一見して分かるように可視化できます。可視化により、システムの構成がはっきりされており、どの機能はどういうふうに実現されているか、どのモジュールで実現しているか、各モジュールはどういうふうに繋がっているか、変更がある場合影響範囲はどうなるのかは地図と同じように指差しで特定できるのです。そのほかに、可視化した情報によって情報交換や、新人教育も容易になるでしょう。

※下記のUML図(クラス図)は、1つの図面に数多くのクラス間の関係をはっきりと表せることで、1分ほどでも分かる情報は、ソースコード読むだけでは恐らく数時間もかかるでしょう。また検討が必要な場合、どこかはどういう風に修正するか指差しで行うことができ、きっと効率よくなるはず。

更に、人間は物事に対する認知特徴として、まず概要や直感的なものから物事を理解し、その後少しずつ深めていくことです。それに、対象問題について深い理解を得るために、その対象をある目的または観点から眺め、細かくて余計な部分を取り除くことで初めて本質が浮かび上がることになるのです。可視化によって物事は目に見えてくるだけではなく、見えるようによってさらに情報の整理やノイズを除いて本質が把握できるようになることです。

ソースコードを作成・読む時には、人間の論理的思考能力を生かすことになりますが、人間の脳は論理的思考以外に、直感力、図形力、全体を見渡す力、空間認知力などの能力もあります。これらの能力を生かさないと無駄になるので、生かすためにぜひ可視化を試してみてください。

可視化はいろんなメリットがありますが、コストもあります。可視化した情報は普通文書かドキュメントという形になります。これらの文書かドキュメントの作成や、レビュー、後の変更がある場合の更新作業が必要になり、工数が必要です。ただし、その後の障害対応のことを考えると、可視化は保険を買うと相当するものと認識すればいいでしょう。障害削減や効率アップなどを考えると、早期の開発フェズの可視化は投資となります。
※下記は費用対効果の変化の対比図(推測)です。可視化しないと、後期はソフトウェアの維持は困難になり、リソースを投入しても効果を得るのも困難になる可能性があります。

最後に可視化について注意すべきこともあります。
①過ぎたるは及ばざるが如し
可視化のためにあまりにも多くの工数をかけて、ソースコードと同じレベルまでの詳細化したものを作るのはやりすぎたものです。費用対効果のバランスを考えれば良いでしょう。
②可視化のために作った資料へのメンテナンスと活用は不可欠です。
可視化のために作った資料もソースコードと同じように重要な成果物と見なすべきです。ソースコードと常に一致するようにメンテナンスしなければなりません。また、運用上でこれらの資料をソースコードの付き物として一元管理をして活用すべきです。


次の記事
« Prev Post
前の記事
Next Post »
Related Posts Plugin for WordPress, Blogger...