WACATE 2017 冬

1. 設計品質とアーキテクチャ
WACATE ２０１７冬
小井土 亨
2017.11.05版

2. 自己紹介
 仕事
 プログラマー（１９８４年から）
 業務パッケージシステムを開発（１９８４年から）
 具体的な作業内容
 開発のガイドラインを作る
 開発プロセスを設計する
 開発プロセスを支える環境を構築し、運用する
 各種ツールの選択
 自動化や支援ツールの開発
 ビルド環境の整備、各種管理ツールの整備
 ソフトウェア・アーキテクチャを決定する
 基盤フレームワークの設計と実装
 基盤の共通ライブラリの設計と実装
 開発上のいろいろな相談を受ける
 コミュニティ
 ＸＰＪＵＧ、SQiP（日科技連）、過去ＭＳ－ＭＶＰ、ＭＳ－ＲＤ
2

3. 3
アジェンダ
 設計と品質
 設計品質とテスト容易性
 自動テストのアーキテクチャ
 システムテストの自動化とアーキテクチャ
 参考資料１：システムアーキテクチャと品質
 参考資料２：品質特性 ISO/IEC 25010：2011

4. 設計と品質
1.設計とは
2.品質を判断する
3.システムアーキテクチャ

5. 5
設計とは
 設計とは
 要求、分析の結果を実現する方法を決める作業
 設計は、問題を解く作業なので、唯一の正解はなく、あるの
は最適解（作業者が最も良いと思う答え）
人によって解が
異なることがある 品質重視効率重視
部屋の掃除をしてほしい
良し悪しの判定は？

6. 6
設計の良し悪しを判断する
 ルール
 判断するために具体的な規則を定義したもの
 指針（品質特性）
 複数のルール間で整合性を取るためには、指針が必要
指針
1.品質
2.効率
ルール１
確実にきれいにす
る
ために人が行う
判断できる判断できる
複数のメンバーでルールを共有する

7. 7
システムアーキテクチャ
 品質特性と対象
 システムとして統一された品質を達成するために、求めら
れる品質特性と対象（ｽﾃｰｸﾎﾙﾀﾞｰ）を明確にする
 ルール（仕組み）
 複数のメンバー間で統一された品質を達成するために、具
体的な規則を用意する
 品質特性を強制する仕組みを作る
システムアーキテクチャの目的
システムの品質特性を強制（支配）する
システムアーキテクチャとは
システムの構造や構造化の原則による仕組み
アーキテクチャで設計品質を支配

8. 8
システムアーキテクチャの定義
 複数の方式で定義する
 複数の角度からの表現を組み合わせて定義する
 開発の視点、実行時（配置）の視点、運用の視点など
 システムアーキテクチャの定義
 概念的な構造（モデリング）
 システムを実現するために必要なシステム構造
 複数の視点で、システム構造を定義する
 動作環境（OSやインフラなど）
 使用するミドルウェア
 構造化原則
 ガイドラインや規約（制約）
 パターン集とパターンの適応ガイド
システムによって、
定義項目は異なる

9.  アーキテクチャの目的を理解する
 全てのシステム（OS、ミドルウェア、DBシステムなど）は
必ずアーキテクチャ（目的や特長、制約や限界）がある
 アーキテクチャにより、品質特性（処理能力やセキュリティ
など）が決定する
 アーキテクチャを理解する理由
 最適なミドルウェアなどを選択
 アーキテクチャに合わないと問題が発生する
 アーキテクチャを理解し、無駄な努力をしない
 ソフトウェアに「どこでもドア」はない
 万能なアーキテクチャ＝役に立たない
もう一つのゴール
9
現実社会にも「どこでもドア」はないけど
間違った選択は
大惨事

10. 設計品質とテスト容易性
1.良い設計とは
2.設計品質特性とテストの関係
3.品質特性

11. 11
設計とは
 設計とは
 要求、分析の結果を実現する方法を決める作業
 設計は、問題を解く作業なので、唯一の正解はなく、あるのは最適解
 設計の基本
 分析の全ての機能を正しく実装する
 ソフトウェアの完全な姿を提供する
 設計結果を利用する人が読みやすく理解しやすい
要求
ブランコがほしい

12. 12
設計とは
 設計の難しさ
 利用者の視点から開発者の視点へ
 視点変換によってギャップの発生（間違える）
 複数のステークホルダ
 利用者、開発者、運用担当者など
 相反する要求項目
 パフォーマンスとセキュリティなど
 予測することが難しい要求の変更や機能強化
利用者：XX機能が必要 開発者：作りやすくしたい
運用担当：メモリ使用量は少なく

13. 13
悪い設計 もろさ
 もろさ
 １つの変更により、論理的には関連のな
い箇所まで正常動作しなくなる
 扱いにくさ
 正しいことをすることが難しいシステム
 硬さ
 変化しにくいシステム
 １つの変更が全体に影響し、多くの変更
が必要になる

14. 14
悪い設計 不透明さ
 不透明さ
 読みにくく、わかりにくい
 不必要な複雑さ
 本質的に意味を持たない構造が含まれているシステム
 不必要な繰り返し
 同じような構造が繰り返し現れ、共通化できる部分がされて
いない
 移植性のなさ
 再利用できる部分を
切り出すことができない

15. 15
良い設計とは（設計品質特性）
 正確性
 仕様を正しく満たしていること
 理解性
 設計結果が読みやすく理解しやすいこと
 一貫性（統一性）
 設計上の個々の概念が首尾一貫して、ぶれがない
 変更容易性
 機能強化などに伴う変更が容易であること
 頑健性（ロバストネス）
 誤った使い方に対して、システムが適切に対処できること
 システムの一部のバグが全体に波及しないこと
 移植性
 いろいろなハードウェア、ソフトウェア環境へ容易に移植できること
 効率性
 実行効率、資源効率ともに十分実用に適応していること

16. 良い設計を行うためには
16
正確に
わかり易く
効率
どうしたら！
移植

17. 17
テスト容易性を指針とした解決策
 テスト容易性に注目する
 テスト容易性を他の品質特性を達成するために利用する
 テスト容易性を羅針盤として、設計作業を進める
直進
テスト容易性

18. 18
設計品質特性 正確性
 正確性とは
 仕様を正しく満たしていること
 ポイント
 設計の論理的な領域で検証する
 仕様（論理的な領域）をマップした領域と実装領域を分離する
 レビューを受ける
 レビュー者に分かる設計にする
– 言葉が大切である
– ドメインの単語を利用する
 テストの役割
 テストによって仕様を満足していることを確認する
 論理的な視点で検証を行う
 テストの視点は、論理的な側面からの視点である

19. 19
設計品質特性 理解性
 理解性とは
 さまざまな関係者が設計の結果を十分理解しやすいこと
 ポイント
 論理的側面の設計によって理解しやすくなる
 既に理解している概念を利用する
 現在使用している単語を利用する
 知っていることをメタファ（比喩）として利用する
 統一された言葉を利用している
 同じ単語が同じ概念で利用されている
 テストの役割
 テストによって処理の流れを明示して、
理解を助ける
 テストは使い方なので、使うことで理解が進む
中だけ見ても？

20. 20
設計品質特性 一貫性（統一性）
 一貫性とは
 設計上の個々の概念が首尾一貫していること
 ポイント
 粒度を合わせる
 モジュールやAPIなどの粒度を合わせることで一貫性が生まれる
 階層化する場合、階層内では粒度を合わせる
 統一した概念や名前を使用する
 テストの役割
 利用者の視点から粒度の確認を行う
 統一性のチェックには、
利用者からの視点が有効である
並べて粒度を比較

21. 21
設計品質特性 変更容易性
 変更容易性とは
 機能強化などに伴う機能追加や変更が容易であること
 ポイント
 以下の２つの設計方法を状況に応じて実施する
 変更を予測した設計を行う
 変更に合わせて再設計（リファクタリング）を行う
–変更しやすいように設計を変更する
 テストの役割
 テストによって、変更の影響が波及していないことを確認す
る
 再設計（リファクタリング）の実施にはテストが必要
 再設計によって、既存の機能が正常に動作することをテストによっ
て確認する

22. 22
設計品質特性 頑健性（ロバストネス）
 頑健性とは
 誤った使い方に対して、システムが適切に対処できること
 システムの一部のバグが全体に波及しないこと
 ポイント
 システムの各サブシステム間を密結合としない
 サブシステムが独立して動作するようにする
 テストの役割
 テストによって、頑丈なシステムであることを確認する
エレベーターはワイヤーが
切れたら止まる設計

23. 23
設計品質特性 移植性
 移植性とは
 いろいろなハードウェア、ソフトウェア環境へ容易に移植で
きること
 ポイント
 再利用できる部分が切り出されている
 環境に依存する部分としない部分を分離する
 環境に依存しない部分が依存する部分に依存していないこと
 自動テストも移植する
 テストの役割
 テストによって、環境の影響を確認する
 テストによって、移植の検証を行なう

24. 24
良いテストの条件
 テスト目的が明確である
 何をテストするか明確である
 その目的も明確で、更にひとつであること
 テストの判定が正しい
 テストの成功、失敗が正しく判断されている
 テストを独立して実行することができる
 テストが他のテストに依存することなく、独立している
 繰り返し実行することができる
 何度でも繰り返して、テストを実行することができる
 テストを実行しても、状態が変化しない
 テストを実行し、成功した場合でも失敗した場合でも、テスト
を実行する前と後で何も変わらない

25. 25
良いテストの効果
 メソッドが一つの機能を実現している
 メソッドが明確な一つの機能だけを提供する
 メソッドの結果を提供する
 外部に対して、メソッドの処理結果を判断できるよ
うな何らかの方法を提供する
 クラスやメソッドの独立度が高いこと
 クラスやメソッドが、他のクラスやメソッドへの依存
が低い
 特定の環境への依存度が低い
 特定のファイルやデータベース構造などに対する
依存度が低い

26. 26
良い設計の特徴
 完全性と十分性
 システムが目的を達成するために必要な機能のみを含ん
でいる
 原子性
 １つのサービスを実現することに焦点があたっている
 高凝集度
 少数に絞られた責務を持ち、その責務を実装するためだけ
の機能を持つ
 低結合度
 他の部分との連携が必要最低限である

27. 27
まとめ 設計品質とテスト容易性
 良いテストの効果と良い設計の相関関係
完全性 良いテストは目的が明確で、必要な機能
を包含している
原子性 良いテストは特定の目的だけに絞られて
いる
高凝集度 良いテストはテスト対象を特定の責務に
限定している
低結合度 良いテストは独立して実行することがで
きる
テスト容易性が設計品質の指針

28. 28
まとめ 設計の原則
 プログラムをモジュールに分割する
 分割することで、プログラムが複雑になるのを避ける
 モジュール間の依存関係を明確にする
 モジュール間の結合度が低い
 モジュール間の結合度が低いほうが良い
 修正や問題が影響する範囲が少なくなる
 モジュールの凝集度が高い
 各モジュール内の凝集度を高くすることで、モジュール間の
結合度が低くなる
 再利用率
 モジュール分割し、モジュール間の結合度を低くして再利用
率を上げる

29. 自動テストのアーキテクチャ
（テストのピラミッド）
1.システムと自動テスト
2.３つの自動テスト
3.システムテストの自動テスト

30. 30
システムと自動テスト
 システムと自動テストは兄弟の関係（写像）
 システムと合わせて自動テスト設計する
 システムに合った自動テストを行う
 開発のプロセスごとに、異なった自動テストを行う
 各プロセスの目的に合った自動テスト
 各プロセスの粒度に合わせた自動テスト
30
システム 自動テスト

31. 31
要求定義
コーディング
システム
テスト
受け入れ
テスト
システム
仕様化
システム
設計
要求のテスト
仕様のテスト
システムの
構築
システムの
導入
単体テスト
３つの自動テスト
開発プロセス内のテストの位置づけ
統合
テスト
設計のテスト
ソフトウェアの
構築
③
②
①

32. 32
３つの自動テストピラミッド
 開発プロセスに合わせて、3つの自動テストを導入
 テストのピラミッド（構造化された自動テスト）
32
単体
結合
システム
フィードバッグ
ユーザー
視点
遅い
速い
近い
遠い

33. 33
３つの自動テスト
 システムテストとは
 システムが全体として正しく動作することを確認するテスト
 自動化のするためのツールが必要
 結合テストとは
 複数の部品（モジュール）がつながって正しく動作すること
を確認するテスト
 変更されやすいUIの影響を受けないテスト
 ユニットテストフレームワークなどで自動テスト化する
 単位テストとは
 コードレベルの動作を確認するテスト（ユニットテスト）
 コンパイラなどでは確認できない内容を限定的に動作させ
て確認するテスト
 ユニットテストフレームワークで自動テスト化する
33

34. システムテストの自動化とアーキテクチャ
1.システムテスト
2.エンドツーエンドテスト
3.システムテストの自動化について
4.システム自動テストのアーキテクチャ

35. 35
システムテストとは
 システムテストとは
 システムが全体として正しく動作することをテストする
 様々な視点でのテストが必要、特に利用ユーザー視点
 システムテストの例
 運用テスト
 実運用に近い環境で、実際に運用するテスト
 操作性テスト
 利用ユーザー視点で、操作を行うテスト
 構成テスト
 様々な構成パターンでのテスト
 マニュアルテスト
 マニュアル通りに操作して問題なく動作することを確認するテスト
35

36. 36
テストコスト増大への対応策
 自動化すべきシステムテスト
 リリースごとに繰り返されるテスト
 前回までのリリースで提供した機能について、同じように動作する
ことを確認するテスト
 回帰テスト（リグレッションテスト）
 今回のリリースと前回のリリースで同じことを確認する
 構成テスト
 さまざま構成で同じテストを実行し、同じ品質であることを
確認する
特定のシステム（UI）テストを
自動化する

37. 37
テスティングと自動テスト
 テスティング活動
識別
設計
実装
実行
比較
どのようなテストができて、何をテストするか決める
どうやってテストするか決める
テストケースを作る
（データ、スクリプトなど）
テストケースを実行する
テストケース成功失敗を判定する
（出力結果と期待結果を比較)
自動化作業
手動/自動
共通作業

38. 自動テストされたシステムテストとは
 自動テストはシステム
 自動テストは、検査を実行するシステム
 自動化されたシステムテストとは
 システムをテストするという目的を持ったシステム
38
検査対象のシステム システムを検査するためのシステム
検査という
明確な目的と機能

39. システムテスト自動化の問題
 テストするシステムやプロジェクトによって、自動化の
要求は異なる
 自動化はゴールではない
39
掃除を自動化する
自動化度は高い 結果品質は高い
自動化がゴールではない

40. ルールと指針を決めて、目的にあった自動化
 ルール
 判断するための具体的なルールを用意する
 指針（品質特性）
 複数のルール間で整合性を取るためには、指針が必要
40
指針
1.品質
2.効率
ルール１
確実にきれいにす
る
ために人が行う

41. システム自動テストのアーキテクチャとは
 品質特性
 自動化されたシステムテストとして統一された品質を達成
するために、自動化されたシステムテストに求められる品
質特性と対象（ｽﾃｰｸﾎﾙﾀﾞｰ）を決める
 ルール（仕組み）
 複数のメンバー間で統一された品質を達成するために、具
体的なルールを用意する
 品質特性を強制する仕組みを作る
41
目標

42. 自動テストのシステム構成
 自動テストのシステム構成
 二つのシステム
テスト対象システム
自動テストシステム
 自動テストシステムのサブシステム
テストスクリプトの作成
テストスクリプトの実行
自動テストの運用
42
自動テストの運用
自動テストシステム
テスト対象システム テストスクリプトの実行
テストスクリプトの作成

43. システムごとに異なった関心事
 自動テストの観点からの関心事
 テスト対象システム
テストしやすいシステムであること
 テストスクリプトの作成
効率よく作成できること
 テストスクリプトの実行
確実に実行できること
 自動テストの運用
上手にテストの運用を行うこと
 各システムと品質特性
 システムごとに異なった品質特性がある
43

44. テスト対象システムに要求される品質特性
 操作性（実行性）
 自動テストのプログラムから対象のプログラムを実行し、制
御できること
 確認性
 対象のプログラムを実行した結果が正確に確認できること
 再現性
 テストを行う特定の状況を再現できること
44
自動化されることを
最初から盛り込む

45. 「テストスクリプトの作成」に関する品質特性
 理解性
 テストスクリプトが読みやすく理解しやすいこと
 テストスクリプトを容易に作成することができること
 テストスクリプトができるだけ多くのメンバーが作成できること
 効率性
 多様で効果的なテストスクリプトを適切なコストで作成できること
 保守性
 テストスクリプトはテスト対象の変更に素早く対応する必要がある
 テストスクリプトの変更が容易であること
 拡張性
 テストスクリプトの機能を必要に応じて拡張できること
45

46. 自動テストシステムに要求される品質特性
 安定性
 テストスクリプトを安定して実行できること
 同じテストスクリプトを何度でも安定して実行できること
 信頼性
 テスト結果の判定が信頼できること
 移植性
 異なった環境でテストを実行できること
46
データ駆動型
キーワード駆動型など

47. 「自動テストの運用」に関する品質特性
 効率性
 必要な自動テストを効率的に運用することができること
 柔軟性
 状況に合わせて、柔軟な運用ができること
 障害許容性
 対象のプログラムで予測しないエラーが発生しても、他のテ
ストスクリプトが継続的に実行できること
 並列性
 複数の環境で効率的にテストを並列して実行できること
47

48. まとめ
 目的を明確にする
 テストしたいシステムやプロジェクトによって目的は
異なる
 ルールと指針（品質特性）を決める
 ルールと指針によって、的確な自動化が行える
 アーキテクチャを構築する
 対象システム、自動テストシステムは異なった指針
が必要
 品質特性を強制するものがアーキテクチャ
48

49. 参考資料１：
システムアーキテクチャと品質
1.システムアーキテクチャと品質特性
2.ビジネスアーキテクチャとシステムアーキテクチャ
3.アーキテクチャパターン

50. システムアーキテクチャ
 システムアーキテクチャとは
 システムの構造や構造化の原則
 システムアーキテクチャの目的
 システムの品質特性を強制（支配）する構造を構築する
 品質特性とは
 システムが実現するべき品質の特徴
 代表的なもの
 パフォーマンス（性能・速度）
 安全性
 信頼性
 可用性（Availability）
 堅牢性（セキュリティ）
 ユーザービリティ（使いやすさ）
 拡張性
50

51. 品質特性の具体化手順
 品質特性に対するステークホルダを明確化する
 例：拡張性
 プログラマの拡張性
 利用者の拡張性
 目的や達成すべきゴールを具体的に定義する
 ポイント
 成果物が目的に合っているか、判断できる内容で記述する
 例：拡張性
 利用者が機能を拡張できるように、外部ファイルに拡張機能を定義
できるようにする
 例：ユーザービリティ
 5秒以上掛かる処理は、処理の進行状況を通知する
 目的やゴールの理由を説明する
51

52. 品質特性の分析
 ４つの視点による分析
 センシティビティ分析
 品質特性に良い効果を表す仕組み
 論理的な根拠
 コンフリクト分析
 副作用として、他の品質特性に悪い影響を与える制約
 論理的な根拠
 トレードオフ分析
 複数の品質特性間で良い影響と悪い影響ものの優先順位
 正当性の根拠
 トレードオフ関係表
 リスク分析
 トレードオフによってサービスレベルが低下する要求品質に対する
リスクを識別し、影響の出る損失
 正当性の根拠
52

53. イベント駆動とバッチ処理
 ビジネスアーキテクチャ
 ビジネスの仕組み
 イベント駆動によるサービス
 要求があった場合にサービスを実行する
 イベント駆動の例
 銀行の窓口業務、タクシーのサービス
 利点
 要求された時だけサービスを行うことで運用コストを減らす
 バッチ処理によるサービス
 事前に決められた計画に沿ってサービスを実行する
 バッチ処理の例
 ダイヤを決めて運行する電車やバスのサービス
 利点
 まとめて行うことでコストを減らす
 サービスを行う回数を少なくして運用コストを減らす
53

54. ビジネスアーキテクチャとシステムアーキテクチャ
 ビジネスアーキテクチャとの関係
 システムアーキテクチャを決定する場合も多い
 ビジネスの仕組みに合わせてソフトウェアの仕組みを決め
る
 検討ポイント
 要求の処理方法が妥当である
 利点
 利用者が理解しやすい
 ビジネスの変化への対応がしやすい
 例：銀行窓口
 整理番号によりサービスを提供する
 システムアーキテクチャで、キューイング制御を行う
54

55. アーキテクチャの構造図
55
概念モデル
ビジネス
アーキテクチャ
設計モデル
アプリケーション
アーキテクチャ
データモデル
データ
アーキテクチャ
物理ノード
物理コンポーネント
テクノロジー
アーキテクチャ
シ
ス
テ
ム
ア
ー
キ
テ
ク
チ
ャ

56. 56
システムアーキテクチャの定義
 システムアーキテクチャの定義
 複数の定義が必要
 複数の角度からの表現を組み合わせて定義を行う
 システム開発のビジョンを実現するために必要なシステム
構造
 構造化原則
 抽象的な構造やガイドライン
 概念的な構造（モデリング）
 ANSI/IEEE Std 1471-2000
 構成要素を統合したシステムの基本的な構造，構成要素
の相互および構成要素と環境間の関係，そしてシステム設
計と発展を導く方針
 全体の分け方と、分けた部分をどのように関係づけるか

57. システムアーキテクチャの構築
 アーキテクチャへの要求
 達成すべき品質特性への要求
 各品質特性は、相反する項目がある
 トレードオフを考慮し、アーキテクチャを決定する
 要求の種類
 非機能要求
 長期的な機能要求
 アーキテクチャ構築時の考慮点
 可変性
 変わる要求と変わらない要求の分析
 リスクの方針
 さまざまな視点からリスクの洗い出しと方針を決定
57

58. 58
アーキテクチャの複数のビュー
 ビューポイントとは
 ステークホルダの関心事に応じた視点
 ビューとは
 複数の関連した視点（ビューポイント）によって、アーキテクチャを記述
するものがビューである
 ４つのビュー
 論理ビュー
 システムが必要とされている機能を実現する、論理的な構造
 実行ビュー
 実行時のプロセスやタスクやスレッドといった実行時の単位の構造
 開発ビュー
 システム開発時のファイル等を単位とした構造
 配置ビュー
 システムをどのようなマシン上で動作させ、各プロセスがどのマシン（CPU)
上に配置されるか等を表した構造

59. システムアーキテクチャの概念図
59
アーキテクチャ
要素
アーキテクチャ
アーキテクチャ
記述
ビュー
システム
ステークホルダ
ビューポイント 関心事
から成る
から成る
文書化される
持つ
のためにアーキテクチャを文書化
従う
持つ
対応する
ニーズに対応
ビューを構築するためのパターンなどを
集めたもの
要求や目的

60. 参考資料２：品質特性 ISO/IEC 25010：2011
利用時の品質
 有効性
 効率性
 満足性
 実用性
 信用性
 快感性
 快適性
 リスク回避性
 経済リスク緩和性
 健康・安全リスク緩和性
 環境リスク緩和性
 利用状況網羅性
 利用状況完全性
 柔軟性
60

61. 参考資料２：品質特性 ISO/IEC 25010：2011
システム／ソフトウェア製品品質
 機能適合性
 機能完全性
 機能正確性
 機能適切性
 性能効率性
 時間効率性
 資源効率性
 容量満足性
 互換性
 共存性
 相互運用性
 使用性
 適切度認識性
 習得性
 運用操作性
 ユーザエラー防止性
 ユーザインタフェース快美性
 アクセシビリティ
 信頼性
 成熟性
 可用性
 障害許容性（耐故障性）
 回復性
 セキュリティ
 機密性
 インテグリティ
 否認防止性
 責任追跡性
 真正性
 保守性
 モジュール性
 再利用性
 解析性
 修正性
 試験性
 移植性
 適応性
 設置性
 置換性
61

62. 62
参考文献
 実践ソフトウェアエンジニアリング ロジャー S・プレスマン
 森口 繁一編『ソフトウェア品質管理ガイドブック』日本規格協会(1990)
 アジャイルソフトウェア開発の奥義 ロバート・C・マーチン
 日経ソフトウェア「正しく学ぶソフトウェア設計」
 実践UML パターンによる統一プロセスガイド クレーグ・ラーマン
 UMLによる オブジェクト指向モデリング セルフレビューノート 荒井玲子
 UML モデリングの本質 児玉公信
 テスト駆動開発入門 ケント・ベッグ
 ソフトウェアアーキテクチャ 岸知二、野田夏子、深澤良彰
 Software Factories ソフトウェアファクトリー Jack Greenfield, Keith Short
 リファクタリング プログラムの体質改善テクニック Martin Fowler
 ＩＴ アーキテクチャ・メタモデル セマンティック解説 ITスキル標準 V2 2006
 アーキテクトの審美眼 萩原正義