2019/04/07

「プログラミングのできる羊とできない山羊を区別する方法」の記事のリンク

 

「プログラミングのできる羊とできない山羊を区別する方法」の記事をリンクしておく。
プログラミングの向き不向きに関する興味深い記事。

 

【参考】
プログラミングできる人とできない人との間の深い溝 - masatoi’s blog

 

(引用開始)
実に多くの人がリンクしているこの論文(PDF)では、プログラムやプログラミング言語に触ったことがない学生達を対象に、「プログラミングのできる羊とできない山羊を区別する方法」を提案している。
おしなべてプログラミングの教師はプログラミングができる学生とできない学生の二つの山ができることに気付いている。それぞれの山は独立な正規分布を成している。プログラミング教育に関する研究のほとんどすべてが教授法についてのものである。すなわち、言語を変え、応用分野を変え、IDEの利用法や仕事へのモチベーションの維持について教えるわけだ。しかしそれらの試みはなかなか上手くいかず、二つの山は依然として残り続けている。
(中略)

 

この論文の著者は計算機科学における最初のハードルは以下のようなものになると仮定している。
代入と系列
再帰 / 繰り返し
同時並列性

 

上から順にハードルは高くなっていく。従ってテストは新米プログラマに対する最初のハードルである代入から始めていく。このテストの結果は3つのグループに綺麗に分かれる。
学生の44%は代入がどのように働くかについて一貫したモデルを持つに至る(たとえ正しくなくとも)
39%の学生は代入のモデルとして一貫したものを形成できない。
8%の学生はふてくされて回答を空白のままにする。

 

このテストは2回実施された。最初の一回目を何の説明もなしに行い、3週間後にもう一度行った。印象的なことは、一回目と二回目では実質的にグループの変化がほとんど無かったことである。つまり、一回目のテストであなたが心の中に一貫したモデルを得られるかどうかが最初のハードルになっている。
著者はプログラミングができることと一貫したモデルを心に持てるかどうかの間には極めて高い相関があることに気付いた。
(引用終了)

 

つまり、プログラミング教育の講座では、プログラミングにすぐに慣れる人と、プログラミングがずっと分からない人から成る正規分布の2つの山に分かれる現象らしい。
確かにそうかもしれない。

 

個人的に興味があるのは、小学生からプログラミング教育が義務化された状況において、プログラミングを知らない子供がどうやってプログラミングのスキルを習得していくのか、を観察してみることだ。
子供が母国語を自然に覚えるように、プログラミング言語を自然に習得できるのか?

 

それとも、40代を過ぎたおじさんがTOIEC対策のために英語習得に非常に苦労している風景と同じく、プログラミング初心者も、通常の論理体系とは異なるプログラミング言語を習得することに、非常に苦労するものなのか?

 

上記の記事を理解した後で振り返ると、数学の公理体系と同じく、それ自体は無意味な論理規則の集合体であるプログラミング言語をどうやって操れるようになるのか、その習得過程に興味がある。
それが分かれば、ソフトウェア開発の難しさという本質に触れられるような気がするから。

 

 

 

| | コメント (0)

2019/03/31

システムエンジニアリングとしての SysMLの記事のリンク

 

青木淳さんが書かれたSysMLの記事が分かりやすかったのでリンクしておく。
ラフなメモ。

 

【参考】
「システムエンジニアリングで SysML を使いこなす」第1章 概要編-システムエンジニアリングとしての SysML | オブジェクトの広場

 

「システムエンジニアリングで SysML を使いこなす」第2章 実践編-電光掲示板を設計する(1) | オブジェクトの広場

 

「システムエンジニアリングで SysML を使いこなす」第2章 実践編-電光掲示板を設計する(2) | オブジェクトの広場

 

上記の記事を読んで面白いと思った点は2つある。
一つは、SysMLという共通言語が複数の専門家集団の意思疎通に重要な役割を果たすこと。

 

ソフトウェア組込製品でも、システムの大規模化・複雑化によって、開発作業はハードウェア技術者やソフトウェア技術者に細分化され専門化した。
結局、開発プロセスや開発組織そのものも局所最適化されてしまっている。

 

一方、市場要求や技術革新によって、どんどん製品や技術が陳腐化していくので、製品自体をその次代の技術に合わせて全体最適化する必要が出てくる。

 

しかし、今までの日本人が得意とする、すり合わせ技術だけでは、システムの複雑化や市場変化の速度に付いていけない。
そこで、モデルベースエンジニアリングのように、システムアーキテクチャを全体最適の観点で構築し直し、ハード・ソフトの専門家も一緒に開発していくスタイルへ変化せざるを得ない。
そういう場面で、ハード・ソフトの専門家同士で会話するための共通言語となるSysMLが必要となり、役立つのだ、というストーリーと理解した。

 

確かに、例えば、製品ドメインの専門家、熱力学や電気・ロボットなどの自然科学の専門家、そして、機械学習やクラウド等のソフトウェアの専門家のように、多数の専門家から成る集団で開発する場合、共通言語がなければ、価値ある製品を作ることは難しいだろう。
共通言語だけで解決できるわけではないが、必要条件の一つにはなりうる。

 

もう一つは、あらかじめ全ての顧客要求や製品の部品やアーキテクチャを決める必要はなく、未決定の要素をリスク管理の対象とみなして開発を進めて、必要な時に随時決定すれば良いこと。

 

製造業の製品開発ではどうしてもWF型開発になりやすいが、各工程の内部は実際はアジャイル開発っぽい雰囲気が出てくる。
原材料や部品の発注があるので納期厳守でWF型開発が王道だが、中身の開発は試行錯誤が普通。

 

昨今の開発では、要件を全て決めてから開発する、という流れの方が少ないだろう。
その時に、製品のアーキテクチャをSysMLで表現した時、どの部分の要件が未決定であるか、を明確に区別して管理することは重要になってくる。
その未決定の要件はリスク管理の対象として扱い、リスクが顕在化してきた時に、アーキテクチャを明確に固めていく。

 

そのプロセスでは、SysMLにあるユースケース図、ブロック図、シーケンス図、アクティビティ図などを使えば、複数の観点でアーキテクチャを分析することで整合性が取られることになる。
つまり、SysMLというモデリング言語によって、リスク管理を支援していることになるわけだ。

 

そんな事を考えると、設計と開発プロセス、モデリングは表裏一体のように思える。
それらを操れることで、開発をコントロールできるわけだ。

 

 

 

| | コメント (0)

2019/03/10

第19回Redmine大阪の感想 #redmineosaka

昨日の第19回Redmine大阪が無事に終了した。
スタッフの皆さん、参加者、そしてJiraやBacklogのパネラーの方、ありがとうございました。
感想をラフなメモ書き。
Mroongaはまだ分かっていないので、間違っていたら後で直す。

【参考】
第19回 Redmine大阪 - connpass

第19回 Redmine大阪(2019/3/9) #redmineosaka - Togetter

第19回Redmine大阪の見所 #redmineosaka: プログラマの思索

redmineエバンジェリストの会 メンバー4人がRedmine大阪へ

続・姫路IT系勉強会で

Node.js meets Redmine (第19回 Redmine大阪 LT発表内容)|足羽川永都(あすわがわえいと)|note

【1】今回の勉強会では、参加者層が多様だったので、大変盛り上がったように思う。
大阪圏の参加者だけでなく、東京・名古屋・福井・京都・神戸・姫路・松江・福岡などの遠方から多数の参加者があった。
また、Jiraのエバンジェリストの方も来て頂いて、チケット管理ツールに関する有用な議論もできた。

直前のキャンセルがあったにも関わらず、補欠の参加者が全員参加されて、参加率100%超になったのはすごいな、と思う。
それだけRedmineのニーズが広がっているのかな?

【2】@akahane92さんの講演では、特に全文検索プラグインの仕様と性能評価が興味を惹いた。

Redmineチューニングの実際と限界 - Redmine performance tuning - Speaker Deck

clear-code/redmine_full_text_search: Full text search for Redmine

@akahane92さんの会社では、クリアコードさんと共同開発して、GitHubに公開されている全文検索プラグインに対し、RedmineのチケットやWikiなどの全文検索を更に強化した機能も含めて公開されている。
今後は、添付ファイルやSVNなどのリポジトリ情報も全文検索の対象としてプラグインの機能に含めていく、という。

【2-1】この講演内容を聞いて重要と考えた事は2つある。
一つは、メーカーという知的財産に非常にセンシティブな企業であっても、オープンソースの方が価値がある、という考え方に同意してくれていること。

もう一つは、Redmineに蓄積されたチケットやWikiだけでなく、添付ファイルや構成管理ツールのリポジトリ情報もテキスト情報として全文検索の対象に含めること。

Redmine本家では、添付ファイルの全文検索も機能追加するチケット(Planio提供 #306)があるが、@g_maedaさんや@akahane92さんに聞いた所、Redmineの検索機能が更に劣化する可能性があること、パッチの規模が大きすぎることから入らないのではないか、とのことだった。
しかし、全文検索プラグインでその機能が実現されるならば、問題はない。

Redmineチューニングの実際と限界 - Redmine performance tuning - Speaker Deck

つまり、全文検索プラグインによって、Redmineに蓄積されたチケット・Wiki・添付ファイル・リポジトリは全て検索対象となり、Redmineを真のナレッジ基盤として実現できるわけだ。

(引用開始)
Redmineのファイル内容 全文検索
添付ファイルの内容検索がパッチとして提供されている(Planio提供 #306)が、 大量の添付ファイルを検索対象とした場合、全文検索の性能は低いと予想される。
想定される課題は3点:

1)検索処理時間
実運用環境の35万ファイルを使用して、全文検索(非索引型)の応答性能を計測すると、10億文字分の検索処理が長時間かかってしまい、日常的に使うには性能が不足するだろう。将来のデータ増加を最大200億文字と想定すると、このままでは厳しい。
→ Full Text Searchプラグインによる、検索機能の拡張開発「添付ファイルの索引型高速全文検索」により改善できる(もうすぐ)
2)検索結果の精度
SQL検索では探している情報が大量のデータに埋もれてしまうため、見つけるまでに時間がかかってしまう。
→ Full Text Searchプラグインによる、 検索機能の拡張開発「高精度検索」により改善できる(予定)
3)リポジトリ内容の検索機能が無いため、ソースコード検索、ドキュメント検索ができず、効率が悪い。
→ Full Text Searchプラグインによる、検索機能の拡張開発「リポジトリ内容の索引型高速全文検索」により改善できる(予定)
(引用終了)

【2-2】@akahane92さんに聞いた所、Redmineの全文検索プラグインでは、プロジェクト単位に全文検索できる仕様が重要である、という点が興味を惹いた。

なぜなら、プロジェクトは新製品開発など、情報アクセスに厳しい制約があるため、Redmineユーザは所属しないプロジェクトにアクセスできない仕様が必要だからだ。
おそらく、ISOやISMSの制約上、重要な機密情報は限定されたユーザだけがアクセスできるような仕組みが必要なのだろう。
Redmine本体の検索機能には、既に検索時の絞り込み条件が設定されているので、問題ないわけだ。

【2-3】全文検索プラグインの実装仕様、特に機械学習によるAI検索について、@akahane92さん、@ryouma_nagareさんの説明を聞いて、ようやく概要を理解できた。

チケット登録時に、チケットの情報とともに、Mroongaが検索用インデックスを保持する。
Redmineで全文検索を行う時、その検索用インデックスを使うので検索時間はかからない。

また、Mroongaが保持する検索アルゴリズムは、定期的にメンテナンスする。
例えば、Redmineの外で、GPUを使った特別のサーバーを用意して、AIエンジンで別途、機械学習させて、その学習結果をMroongaに週1回または月1回のように定期的に取り込む。
したがって、Mroongaの検索アルゴリズムは定期的にアップデートして、Redmineの検索精度を高めるように運用すればよい。

僕はMroongaを機械学習エンジンと勘違いしていたが、そうではなく、全文検索用の語彙表テーブルとインデックスカラムを自動生成してくれるミドルウェアだと理解した。

他に、お話を聞くと、MroongaはRedmineのver3.4, 4.0にも対応済みらしい。
そしてOSS化されている事から、MroongaはRedmineの最新版に追随してくれることが期待できる。

【3】アジャイルウェアの堂端さんのGitHub連携プラグインのデモも興味深かった。

仕掛けとしては、RedmineでGitHubの接続情報を設定しておくと、Redmineサーバー上にGitHubのBareリポジトリが作られて、そのリポジトリをRedmineが参照すること。

agileware-jp/redmine_github

【4】JiraとBacklogパネラーを含めたパネルディスカッションも面白かった。

BacklogやJiraが向いていない利用シーンは、大規模なWF型開発の案件です、という発言を聞いて、Redmineのチケットやプロジェクトの階層無制限の機能がそこに有効に作用している、という点を改めて認識した。
つまり、日本の企業でRedmineが好まれているのは、従来のWF型開発にとてもフィットしているツールとして使われているからだろう。

【5】今回の勉強会を一スタッフかつ一参加者の立場で楽しんだ後、Redmineコミュニティは今後どのように進んでいくのだろうか、と思った。
懇親会でも、最近の東京Redmine勉強会は盛り上がっているが、Redmine大阪はどうなんですか、という質問もあった。

僕は、JiraとBacklogのパネルディスカッションを聞きながら、2011年当時のチケット管理ツール大決戦のイベントを思い出していた。
2011年のRedmine勉強会発足当時、大阪や東京のRedmineコミュニティではアジャイル開発者が率先して試行錯誤していた。
たとえば、以前は、@daipresentsさん、岡本さん、小久保さんなど数多くのアジャイル実践者は、Redmineでいかにアジャイル開発を運用するか、を試されていた。
その過程で、Scrumのプラグインを作られたり、Gitと連携するプラグインを作られていた。

しかし、その後、Redmineのユーザ層が変化したように思う。
実際、最近のRedmine勉強会のユーザは、PMOやSEPG、情報システム部門のユーザが多い。
また、Redmineを全社で展開しているので、Ruby開発者よりもインフラ関係のエンジニアが多いように思う。

つまり、Redmineのユーザ層は、アジャイル開発者ではなく、日本のソフトウェア開発や現場の業務に合うように実運用する立場の人達に変化した。
そんな流れを振り返ると、日本のユーザはRedmineが自分たちのニーズに向いていることに気づき、多種多様な現場に片っ端から適用してみることで、Redmineをより深く理解しようとしているのではないか、と思った。
今回の勉強会では、そんな気づきがあった。

| | コメント (0)

2019/02/24

RedmineとAIエンジンを連携する事例のリンク

RedmineとAIエンジンを連携する事例があったのでリンクしておく。
以下は自分が理解した内容のラフなメモ書き。
間違っていたら後で直す。

【参考1】
その問い合わせ、AIが解決します!~Redmineチケットレコメンドシステムのご紹介~ | Future Tech Blog - フューチャーアーキテクト

社内ヘルプデスクをAIで! | Future Tech Blog - フューチャーアーキテクト

【1】後者の事例は、チケットの内容をAIエンジンが自動判断して、カテゴリ振り分けを自動設定する。
前者の事例は、チケット登録時の情報を元に、AIエンジンが類似チケットを自動で関連付ける。

上記の例で興味深い内容は、下記の点だ。

(引用開始)
検索アルゴリズムは、「類似文書検索」と「キーワード検索」のハイブリッド手法を用いることにより、より精度を向上させる試みを行いました。
類似文書検索は、機械学習のトップカンファレンス1 で発表されたSCDV(sparse Composite Document Vector)と呼ばれるEmbedding手法を用い、キーワード検索は現在有力とされているBM25を用いました。
本システムのもっとも肝な部分は、SCDV(文書検索)×BM25(キーワード検索)のハイブリッドアルゴリズムを実装した点にあります。
(引用終了)

なるほど、類似文書検索とキーワード検索を元に、チケット内容の類似度の度合いを相関関数で測定して、精度を高めているわけだ。
類似文書検索だけ、キーワード検索だけ、ではなく、2つを組み合わせた多重度分析にして重みを教師あり学習で精度をさらに高めている点は、面白いな、と思った。

【2】アーキテクチャとしては、AWS上にRedmineとJenkinsとAIエンジンがあって、Jenkinsが定期的にRedmineをポーリングしてAIエンジンに連携し、カテゴリ振り分けや類似チケットを推定して、Redmineへ情報を返却する流れみたい。
Redmineのチケットにカテゴリ振り分けや類似チケットを関連チケットとしてリンクさせる処理は、RedmineプラグインまたはREST APIで実装しているみたい。

確かに、Redmineの外側にAIサーバーを置いて、Redmineのデータを定期的に渡すようにするサーバー設計ならば、既存の仕組みを組み合わせるだけで作れそうな気がする。
Redmineのデータをやり取りするI/Fの部分だけは、REST APIやRedmineプラグインで実装すればいい。

この発想は、Redmineの外部にBIサーバー(例えば、Tableauとか)を置いて、Redmineのデータを定期的に集計表示させる仕組みにも似ている。
つまり、Redmine単体はチケットというデータ収集基盤とみなし、AIサーバーやBIサーバーがRedmineのチケットを定期的に取得して、類似データを分析したり、いろんな観点のメトリクスを集計する仕組みが作れるわけだ。

【3】上記の事例は非常に面白い。
なぜなら、「少人数・短期間で、簡単に構築することができた」からだ。
つまり、RedmineとAIエンジンを組み合わせる手法は、昨今のOSSライブラリを上手く流用できれば、そう難しくないのだろう。

現在、Redmineを長年運用してチケット枚数が数万~数十万件まで蓄積された開発現場はたぶん、割と多いのではないか、と思う。
AIサーバーで類似チケットを自動設定したり、カテゴリ振り分けを自動設定したりする事例があるならば、他に、別のチケット振り分けの観点でチケットの属性にデータを設定する機能も実現可能だろう。
つまり、@ktohさんが以前話していたように、Redmineにスマートナビまたはコンシェルジュのようなエンジンを実現することで、チケット入力者に事前に情報を提供したり、チケット入力を支援することも可能だろう。

この辺りのアイデアは色々考えてみたいと思う。

| | コメント (0)

2019/02/11

法律のケース問題をモデル化するアイデア

法律のケース問題を図解する事例を、ネットサーフィンしながら見つけたのでメモ。
アイデアをラフなメモ書き。

【参考】
中小企業診断士試験 一発合格道場 ≫ Blog Archive ≫ 【法務】ケース問題を打破する図解術

UMLの概念モデルで法律を理解するアイデア: プログラマの思索

法務脳の作り方part1: プログラマの思索

【1】上記の記事によると、法務のケース問題を図解するパターンは2つある。

【1-1】一つは、民法のように「誰がどんな権利を主張できるか」のケース。
重要ポイントは、利害関係者とその権利・義務の関係を明確にすること。
つまり、利害関係者の関係を明確にできるようにモデル化すること。

なぜなら、民法では、被害者・加害者、あるいは背信的悪意者のようなステークホルダーのうち、誰が権利を持っているのか、権利を主張できるのか(対抗要件)をケースごとに見抜くのが重要だからだ。

(引用開始)
1. 図解術その1~登場人物を整理してみる
冒頭にトラブルについての長い状況説明があり、「どのような権利を主張できるか」等の設問があるタイプの問題です。
主に民法関連の問題に多い形式です。

例として、H18年度の第9問-設問1を見てみましょう良い
不法行為と債務不履行の問題です。
(中略)
「X社が主張できるもの」を問われているので、X社をとりまく登場人物とその関係を図で整理してみます
(中略)
作図する際に意識した点は、大きく以下3点です。

・登場人物を明確にする (X社/Y/Z社/B社)
・登場人物の属性を示す (X社はライセンス利用者/Yは保持者/等)
・登場人物の関係性を示す (ライセンス契約/等)

このように登場人物が多く事象が複雑な場合には、一目で全体を俯瞰できることが重要なポイントになると思いますキー
(引用終了)

【1-2】もう一つは、知的財産法のように「ある時点で権利の出願を行うが、他社より「権利侵害である」と言われる」ケース。
重要ポイントは、時系列で権利の出願・公開・侵害の申請などのイベントを整理すること。
なぜなら、「多くの知的財産権は、基本的に”先願主義”を取っているため、誰の行動が一番先なのかを意識することが重要である」ためだ。

(引用開始)
2. 図解術その2~時点を意識する
知的財産権関連の問題に多い形式、過去のある時点で権利の出願を行うが、他社より「権利侵害である」と言われるようなタイプの問題です。

例として、H21年度の第9問を見てみましょう
商標権の問題です。

商標権登録を行うためにライバルであるD社への対処を問われているので、C社とD社の現在までの行動を時間の流れと共に整理してみます。
例えば、こんな感じです。

作図する際に意識した点は、大きく以下3点です。

・誰が (C社またはD社)
・いつの時点で
・何を始めたのか

多くの知的財産権は、基本的に”先願主義”を取っているため、誰の行動が一番先なのかを意識することが重要であると思っています
(引用終了)

【2】上記の事例より、下記でまとめられるだろう。

・民法は「利害関係者の図」が有効。
 なぜなら、権利・義務・対抗要件を明確にしたい為。
 →パッケージ図、クラス図、ユースケース図、コラボレーション図が有効か?

・知財は「イベントの時系列」が有効。
 なぜなら、先願主義なので、誰の行動が一番先なのかを明確にしたい為。
 →アクティビティ図、タイミング図?

過去にも、UMLの概念モデルで法律を理解するアイデア: プログラマの思索で、刑法の概念をクラス図でドメインモデルで描いてみる、という事例もあった。

この辺りを整理してみたいと思う。

| | コメント (0)

«「サピエンス全史」「ホモ・デウス」の図解のリンク