CSMM.101x: Week 3: Heuristic Search

edX ColumbiaXのAI (CSMM.101x) Week3のまとめです。

今回取り上げられているヒューリスティック検索や前回の講義で取り上げられている、幅優先探索等を日本語で理解するためには、下記サイトを参照致しました。

ヒューリスティック探索
幅優先探索と反復深化
欲張り法 (greedy strategy)

3.1 Heuristic and Greedy Search Algorithm
前回説明されたUninformed Searchに対し、解に近づいているかどうかがわかるInformed Searchが今回の講義のテーマです。

最良優先探索(Greedy best-first search)、Aスター探索、反復深化Aスター探索がInformed Searchの例としてあげられています。

3.2 A* Search and Optimality
Aスター探索となぜ、それが最適な解を提示し得るかの説明がされています。

3.3 Search Algorithms Recap
ここでは、今まで説明された、BFS, DFS, IDS, UCS, A*, IDA*, Greedy best first search, A* Searchの各種アルゴリズムの特徴が説明されています。
ここまでの講義の最重要点ですので、別途まとめてポスト予定です。

3.4 Local Search (局所探索法)
局所探索法としてHill Climbing 山登り法の説明がされています。

Week 3 Quiz: Heuristic Search
ヒューリスティック関数の性質に関する質問で1問間違えたものの、他はすべて正解ができました。ヒューリスティック関数が許容的(admissible)かどうか、特定条件下で各アルゴリズムのcompletnessはどうか、といった設問が多かったです。

Week 3 Discussion Questions
ダイクストラ法と均一コスト法の比較を行っている下記論文が紹介されています。こちらも別途ポスト予定の探索アルゴリズムまとめで言及する予定です。

Position Paper: Dijkstra’s Algorithm versus Uniform Cost Search or a Case Against Dijkstra’s Algorithm
http://www.aaai.org/ocs/index.php/SOCS/SOCS11/paper/viewFile/4017/4357

技術とソフトウェア開発手法

FinTechとアジャイル開発をポストした後、ソフトウェア開発の手法に関する記事をいくつか読んでいたのですが、ITと哲学や概念と言葉と課題と答え述べてきた私の考えとマッチするというか、よりわかりやすい説明が行われている記事を見つけました。

「現状のソフトウェア開発は間違っていないか？」（プロセス編） (1/3)
http://www.atmarkit.co.jp/ait/articles/0901/28/news151.html

上記の記事では（記事の執筆者が考える）ウォーターフォール開発の歴史が紹介されており、そこで「メインフレーム開発」という特定の技術と状況において使用され、かつマッチしていたと紹介しています。また、当時のシステムに対する要求というものが、そもそもシンプルであったことも指摘されています。

しかしながら、業務が変わったことにより今日の要求は複雑化するし、かつ技術もオープン系になっているため、必ずしもウォーターフォール開発の手法はマッチするわけではないというのは筆者の主張です。

さらには、要求(とくべき課題、what)とソリューション（how）の関係についても、必ずしもwhatからのみhowを考えるのではなく、howからwhatを考えるという双方向の視点も筆者は取り入れており、これが私がITと哲学や概念と言葉と課題と答えで述べてきたことと相通ずるものがあると考える点です。

ある手法を歴史的背景、その手法が使用され始めた状況や技術を踏まえて批判的に分析し、強み弱みを捉えるのは、開発手法のみならず、他の様々なフレームワークを分析する上でも有用かと思います。

そんな中ふと、以前に読んだ三谷宏治『経営戦略　全史』を思い出しました。

「SWOT分析」、「プロダクトポートフォリオマトリクス」、「Fice Forces分析」等の分析ツールやフレームワークがどのように生み出され、使用されかつ批判継承されていったのかが理解できる良書です。ソフトウェア開発でも同様の本があれば読んでみたいです。

FinTechとアジャイル開発

大手金融機関がFinTechに取り組むにあたって、既存のビジネスラインの利害や意思決定のプロセスに左右されないように新規部署を設置して取り組むことが多いかと思います。

新しいサービスには新しい組織で臨もうということですが、であればツールとしての開発手法も従来のWater Fall型だけでなく、アジャイル開発の手法が適用されることも多いのではないかと。下記記事ははみずほ銀行が、アジャイル開発に取り組んでいるのを紹介しています。

「スマホで手軽に資産運用」の時代は訪れるか――みずほ銀行がアジャイル開発で取り組む「ロボアドバイザー」の今後 (1/2)
http://www.atmarkit.co.jp/ait/articles/1602/08/news020.html

私自身は、アジャイル開発のトレーニングも受けたこともありますし、開発チームをリードする上でスクラムの手法を適応したこともありますので、そのメリットも理解しているつもりです。金融機関であれば、システム開発のプロジェクトにおいては、アジャイル開発／スクラムの手法に関して知識を得ることは、必要不可欠と思いますし、該当のプロジェクトの特性やメリット、デメリットを考慮した上で、導入を試み試行錯誤を繰り返すというのも必須かと思います。

が、あらゆるシステム開発のプロジェクトにおいてアジャイル開発が適しているとは限らないですし、Water Fall型 vs アジャイル開発と、互いを対立させる視点から双方を理解するのもよろしくないかと思います。

といったことと考える中で従来のプロジェクトマネジメントについて色々検索していたところ、下記のブログをみつけました。

タイム・コンサルタントの日誌から
http://brevis.exblog.jp/

下記のような面白い記事が多いです。
プロジェクト・コミュニケーションのベーシック(2) ～ ドキュメント・インデックスを作る
http://brevis.exblog.jp/24715817/

スクラムといえば、以前に読んだ下記の本も非常に面白かったです。本書で紹介されている、FBIにおけるシステム開発の例が示唆に富んでいます。