2019/05/19

第16回東京Redmine勉強会の感想 #redmineT

昨日の第16回東京Redmine勉強会の感想をラフなメモ書き。
疲れているのでラフなメモ。

【参考】
第16回勉強会 - redmine.tokyo

第16回東京Redmine勉強会『Ver4に上げよう Redmineのさらなる進化と多用性!』 #redmineT (18ページ目) - Togetter

第16回redmine.tokyo勉強会 まとめ

【1】昨日のRedmine勉強会でちょっと嬉しかったことは、@rechiba3 さんに初めてお会いできたことと@ohnukiさんに5年ぶりにお会いできたこと。

akipiiさんのツイート: "#redmineT 東京Redmine 勉強会から離脱しました。講演者、スタッフ、参加者の皆様ありがとうございました?? 懇親会の参加率が約7割で50人で盛り上がりが凄いと思います。今回は7年越しに @rechiba3 さんとお会いできたのが収穫でした。ユーザー層も老若男女、開発者からPMOまで幅広くて来る度に面白い"

@rechiba3 さんの下記の資料を以前読んでBlogに感想を書いたことがあったので気になっていた。

TiDDでウルトラハッピーな開発フロー実践しちゃおう!

WebディレクターによるRedmine運用事例: プログラマの思索

また、@ohnukiさんは、5年前の勉強会が大雪だった時にLTで講演して頂いたことを覚えていたから。

第6回勉強会 - redmine.tokyo

他にも@MzRyuKaさんから、懇親会でこんな話もあって盛り上がった。

みずりゅさんのツイート: "#redmineT https://t.co/XfSENoynLn 初参加、どれも凄く楽しかったけど、あえて一番を選ぶとしたら懇親会でakipiiさんとお話しできたこと。 数年前に会社のブログで書いた記事を取り上げてもらったことに、やっとお礼を言うことができました。"

チケット駆動開発の運用例part4: プログラマの思索

BlogやSNSのおかげで、実際に会ったことがなくても、すぐに仲良くなれる。
そういう場をコミュニティが提供してくれて本当にありがたい。

【2】10個以上の講演があったので、記憶に残った所だけ書き残す。

【2-1】@netazoneさん「ある工場の Redmine バージョンアップ」では、プラグイン作者にVer4.0対応を自らお願いしまくった結果、そうなったからには自分のRedmineをバージョンアップしなくては、という行動に至った気概に強く共感した。
数多くの日本人プラグイン開発者が対応してくれたからこそ、Ver4.0に安心してバージョンアップできるからだ。

つまり、Redmine本体だけでなく、主要なプラグインがVerUpに追随することは、Redmineユーザにとって非常に重要な要素である、という事実を明示していると思う。
よって、RedmineコミュニティがRedmineプラグイン開発者を巻き込んでRedmineを盛り上げていくことは、非常に重要な活動なのだ、と改めて感じた。

【2-2】@agilekawabataさん「LycheeカンバンとRedmine運用の事例紹介」では、Lycheeプラグインの機能紹介が多くなってしまったけれど、メーカーのRedmine利用事例の話に興味を惹かれた。

akipiiさんのツイート: "#redmineT 複数案件を複数チームで進捗管理するにはどうする?メーカーなら、エンジンチーム、ボディチームなどの複数チームがあるが、トラックプロジェクトと乗用車プロジェクトの親チケットから派生した子チケットは、それぞれのプロジェクトで管理したい。"

例えば、自動車メーカーでは、トラックプロジェクト、乗用車プロジェクトの2つのプロジェクトが別々にある一方、エンジンチーム、ボディチームの2チームも別々にある。
トラックプロジェクトの機能(親チケット)には、エンジンチーム、ボディチームの開発タスク(子チケット)でぶら下がるが、チームごとのプロジェクトで扱いたい。
理由は、チーム単位のタスク管理がしたいこと、各プロジェクト単位で他者には情報を見せたくないことがあるから。
現状の標準Redmineでは、Redmineプロジェクトを跨ぐ親子チケットや関連チケットは作ることができるので、ある程度は運用できるだろうが、もっと細かなニーズを実現して運用する場合は、色々問題が噴出するだろう。
おそらく、それら問題となる利用シーンでは、Redmineのカスタマイズやプラグインによる機能拡張が必要になるだろうと想像する。

つまり、複数プロジェクトと複数チームのタスク管理を横串でプロジェクト管理する手法を、Redmineが支援できる可能性がある。
そうすれば、組織をまたいだ複数案件のPJ管理のように、より大規模なPJ管理もRedmineがカバーできるようになるだろう。
本来、Redmineという一つの箱にWF型開発案件もAgile案件もデータが格納されているので、横串のデータ集計はRedmineのようなチケット管理ツールが得意な所。
その機能をさらに大規模なPJ管理にも適用していくには、Redmineにどんな機能が標準で必要になってくるのか、という問題を提起してくれた点が面白かった。

【2-3】@yassan168さんのLTでは、クラウド上でDockerを使って、Redmineを含めたサーバー構築を行った、という点が興味を惹いた。
Redmineサーバーだけでなく、リバースプロキシやDNS設定などは、オンプレサーバー上のインフラ構築作業と全く同じなのに、クラウドの方がものすごく簡単に構築できるわけだ。
オンプレミスのインフラ構築は、本当に面倒な作業だった。
たとえば、iptableをいじったり、hostsをいじったりしていたから。

しかし、@akabekobekoさんと話しながら、簡単に構築できる理由は、DockerでOSに依存しないミドルウェアの構築ができるので、後はそれらをつなぐ構成をすればいいだけ、ということで理解した。
よって、今後はAnsibleよりもDockerの方が有用だろうという気がした。

【2-4】hin-tさんのLTでは、定期的にチケット登録するプラグインを紹介していた。
営業事務の定形業務で、物忘れせずに役立つんですよ、という発言があった。
どのプラグインか忘れたので後で探しておく。

定期的なタスクをチケット登録するRedmineプラグイン: プログラマの思索

【2-5】石川さんのLTでは、message_customizeプラグインが興味を引いた。
このプラグインは、ymlに書かれた文言を修正して表示できること。
メリットは、ymlを書き換えなくても、管理画面で修正できるので、viewCustomizeプラグインに似た感覚で管理者が操作できることだろう。
すると、@netazoneさんが発した問題「海外ユーザと1個のRedmineインスタンスを共有する時、ステータスやトラッカーを日本語・英語で併記しない方法はあるか?」に対応できないか、考えてみたくなる。
一方、@g_maedaさんの話では、Redmineの画面をリロードしたらhtmlからlang=ja,enは取得できるので、その情報を元に、ログインユーザ毎に修正文言を表示できるはず、と言っていた。
たぶん、message_customizeプラグインとviewCustomizeプラグインを駆使すれば、その問題は解決可能だろうと思う。

GitHub - ishikawa999/redmine_message_customize: This is a plugin for Redmine.

GitHub - onozaty/redmine-view-customize: View customize plugin for Redmine

【2-6】堂端さんのLTでは、Redmine大阪で話したGitHub連携プラグインの続きだった。
興味を引いたのは、RedmineチケットとGitHubブランチを紐づけた後、Github上でプルリク受付、プルリク承認、masterマージという一連の作業ごとに、Redmineチケット一覧画面でチケットのアイコンが更新される機能があったこと。

つまり、GitHubからRedmineへフックさせているわけだ。
裏では、GitHubのクローンがRedmineサーバー上にあるので理解できるが、Redmineチケット一覧でプルリクのステータスをアイコンで判別できる機能は良いな、と思った。

但し、RedmineチケットとGitHubブランチを紐づける時に、「xx@#チケット番号」のようにブランチ名にプレフィックスを付ける手順がいる点は注意。

GitHub - agileware-jp/redmine_github

【2-7】@miokakusuさんのLTでは、MSのVisualStudioからTFSへチェックインする時に、Redmineチケットと同期させる仕組みを作った事例。
TFSの通知メールからRedmineとREST APIで連携する処理が面倒ですね、という話が興味を引いた。
仕掛けについては、@ryouma_nagareさんからアドバイスをもらったので理解できた。

akipiiさんのツイート: "#redmineT TFSの通知メールをRedmine がキャッチして、RESE APIで、チェックインとチケットを紐づけた。ごめん、この辺りがよく分からない。"

りょうま@redmine.tokyo終了でRedmineロスさんのツイート: "ですね。 メールサーバで受信したメールを標準出力でスクリプトが受け取る 本文解析して、チケット番号、内容、ステータスを生成 REST APIでRedmineサーバにアクセス です。メールサーバかRedmineに同居している必要もないです… "

【2-8】@naitohさんのアンケート集計では、Git利用率が下がっている点が気になった。
たぶん、Git中心で開発する場合、GitHubやGitlabだけの運用に流れているのかもしれない。
つまり、RedmineとGit連携の機能が弱い点は、今後、Redmineの弱点になってくるかもしれない。

【3】@ohnukiさんから、コミュニティ運営を褒められたことは一スタッフとして嬉しかった。

Hiroshi Ohnukiさんのツイート: "久しぶりの参加、第一印象ですが運営が素晴らしい #redmineT"

【4】Redmineコミュニティに関わって8年経つが、なぜRedmineコミュニティを継続できたのか、とふと疑問に思う。
僕はコミュニティ経験がまだ浅いけれども、過去を振り返ると、コミュニティの浮き沈みはとても激しいと感じる。
長期に渡って熱気を維持できるコミュニティは正直多くない。

その理由は、Redmineというツールが、日本における市場の潜在ニーズをうまく汲み取ってきたから、ではないかと考えた。
つまり、日本の官公庁や大企業における非効率な業務にRedmineが当てはまるケースが多いのだろう、と考える。

たとえば「プラットフォーム革命」にはこんな一節がある。
プラットフォームビジネスの機会を見つけるには、「取引コストが高い所」「複雑で見過ごされているネットワーク」「大規模で分断された未活用な資源がある所」に注目せよ、と。

この言葉を念頭に置いて、以前、CoderDojoの関係者と話していたら、まさに日本の教育業界はとても非効率な業界なので、ベンチャー企業が参入しやすいという印象を受けた。
実際、日本の学校ではIT化が進んでおらず、プログラミング教育や英語教育などの外部環境の大きな変化に揺さぶられていて、教育者だけで自力解決できず、袋小路になっている印象だ。
そんな非効率な業界だからこそ、CoderDojoなどのITコミュニティやITベンチャー企業はちょっとした改善ツールを導入するだけでも、すごく通用する。
そういう話を聞きながら、CoderDojoは本当に良いマーケットを持っているなあ、今後しばらくはその業界でビジネスをやっていけるだろう、という印象を持った。

同様に、日本の官公庁や大企業は、メールやExcel帳票の文化で凝り固まっている現場が多いので、昨今の最先端のIT企業から見れば、非効率極まりない利用シーンが非常に多く見受けられるだろう。
だからこそ、そういう業務にRedmineを単純に導入するだけでも、それなりの改善効果を得やすい状況があるのだろう、と思う。
よって、そういう非効率な市場が残っている限り、まだ今後しばらくは、Redmineは日本で根付いていくだろうと思っている。

| | コメント (0)

2019/05/16

GSNの利用事例のリンク

 

astahブログにGSNの利用事例が紹介されていたのでリンクしておく。

GSN広めよう活動奮闘記?三菱電機エンジニアリング株式会社様? | astah in 5 min

GSNは組込みシステムの機能安全の設計で使うツールと思っていたので、タスク管理に使う発想がなかった。
なるほど、変更要求からタスクまでのトレーサビリティを明示できる特徴を生かして、こういう使い方もできるのは面白いと思った。

 

 

 

 

| | コメント (0)

2019/05/07

第16回東京Redmine勉強会の見所 #redmineT

来週末に行われる第16回東京Redmine勉強会の見所を書いておく。

【参考】
第16回勉強会 - redmine.tokyo

第16回redmine.tokyo勉強会 みどころ

「エンジニアの知的生産術」読後メモ(自分用) - Qiita

【1】今回のテーマは『Ver4に上げよう Redmineのさらなる進化と多用性!』。
テーマに関しては、スタッフ内で議論が色々あった。
ViewCustomizeプラグインをもっと使った事例が欲しいね、という話から、多様な講演内容がそろったと思う。
Redmineの利用事例がかなり増えたおかげで、色んな人達が自分なりの改善ノウハウを持っているみたいだ。
そんな話が聞けるのが面白い。

【2】いくつか興味深い講演はある。

一つは、アジャイルウェアの川端さんの講演「LycheeかんばんプラグインによるScrum開発事例の紹介(仮)」。
最近、Lycheeかんばんプラグインの評判がいいので詳細を知りたい、という話から講演が決まった。

チケットボード | Lychee Redmine(ライチレッドマイン)でプロジェクトの見える化を。そして管理ももっと楽にしよう。

標準Redmineでは、チケットという元ネタはあるが、それを多種多様な利用目的に応じて集計表示できるビューの機能は少ない。
そこで、チケット集計に関する数多くのプラグインが生まれてきた。
その中で、かんばんというビューは、色んな使い方ができる可能性がある。

本来、かんばんはアジャイル開発に最も適した進捗管理用のビューだ。
たとえば、タイムボックス形式で、タスクをフローで管理する。

しかし、WF型開発でもかんばんは有効な場面が多い。
特に、結合テストや総合テストなどのテスト工程では、障害管理とかんばんは非常に相性が良い。
日々溢れ出てくる障害を一つずつ潰していくには、かんばんのように、日々の作業ステータスがリアルタイムに見れる方が管理しやすいからだ。

一方、かんばんは担当者の手持ちの作業が明確に判別しやすい。
日々の作業がスムーズに流れているならば、特に朝会とセットで運用すればいい。
WIPを導入すれば、チームの能力に合わせたリソース管理がしやすくなるはずだ。

「Lycheeプラグインは500社以上の導入事例がある」とWebページで記載されているので、個人的には、日本の企業はRedmineにどんな事を期待しているのか、そして、Redmineの標準機能のどこに不満を持っていて、Lycheeプラグインがどうやって上手く適合してきたのか、という点が知りたい。
つまり、日本企業とRedmineがなぜ相性が良いのか、という本質を聞いてみたいわけだ。

【3】もう一つは、多様で盛り沢山なLT。

@forenoonMさんの「ViewCustomizeのHTML埋め込みによるRedmineの機能拡張」は、一時期ツイートで有名になった「Redmine上で動くティラノサウルス」のことかな、と思う笑。

akipiiさんのツイート: "面白すぎる!RT @netazone: Redmine に例の「暴れ回るティラノサウルス」降臨。 ありがとう @forenoonM 。 そして view customize plugin をこんなことに使ってごめんなさい https://t.co/5L3jSWuPV5"

akipiiさんのツイート: "元ネタはこれでしたか!RT @forenoonM: Redmineに例の「Wordで暴れ回るティラノサウルス」をそのままリアルタイムレンダリングしてみた。さすがはView Customize Pluginとthree.jsだぜ! https://t.co/xZZG0efuji"

他にも、Git連携や構成管理ツールTFSに関するLTが3本もあるので、やはり構成管理ツール連携の機能はニーズが多いのだろうと思う。

【3】@MadoWindaheadさん「カスタムクエリーを使って状況を見やすく斬る」、@yuki476さんの「チケット文化定着までに気をつけたこと」、hin-tさんの「(仮)毎月のTodoを自動チケット作成プラグインでもっと簡単に」のLTは、Redmineの運用方法に関する講演で興味がある。

@MadoWindaheadさんと話しながら、「エンジニアの知的生産術」本にある一節「タスクの優先順位付け」を思い出していた。
その本では、タスクの優先度付けの話があり、優先度をつける観点1の最優先、または、観点2の最優先が本当の全体最適ではなく、観点1と観点2の中くらいが利益最大になる場合もある、という話があった。
つまり、制約条件が複数の場合、全体最適な解は線形計画法で計算するパターンになる。
よって、人間の頭ではすぐに全体最適の解を見つけるのは難しいので、あえて1次元に落としているのかな、と思った。
1次元に落とせば、ソート順に並べるだけで優先度が即座に決定されるからだ。

実際、タスクの優先順位付けこそがプロジェクトリーダーの最大の仕事だ。
しかし、タスクの優先順位付けの解空間は、そのパラメータの個数分であるN次元空間になるが、変数の個数が多かったり、説明変数が相互依存していたりするなど、人間の頭では処理しきれない。
よって、あえてN次元→1次元へ射影して単純化することで、スピーディに優先順位付けできるようにする手法が、特にScrumのProductBacklogなどのアジャイル開発で発達してきた、と考えている。

一方、解空間の次元を落とすことは、必要な情報も削ぎ落としているリスクがあり、それにより優先順位付けを間違えている可能性も大きい。
その辺りのトレードオフをどのように解決するのか、@MadoWindaheadさんが自身の経験談を元に、どのように解決してきたのか、を聞いてみたいと思う。

【追記】
着々と準備は進んでいるみたい。


neta@ 5/11(土) Redmine 4.0 化(まもなくしぬ)さんのツイート: "Today I upgraded my main #redmine to 4.0 ! I am grateful to all Redminers (developers and plugin authors, users)! :) … https://t.co/fxwhF8o7HI"


第16回redmine.tokyo開催前夜に、仲間と愉しきやり取りをメモした。
ときめくバグチケットとは? 第16回redmine.tokyo開催前夜の眠れぬ夜の会話- Togetter

| | コメント (0)

2019/04/22

IT企業が経済学者を雇い始めた理由が面白い

最近、IT企業が経済学者を雇い始めた理由を解説する記事をちらほら見かける。
記事が面白いのでリンクしておく。
以下は、自分の理解のラフなメモ書き。
間違っていたら後で直す。

【参考】
IT企業はなぜ経済学者を積極的に雇い始めたのか | HBR.ORG翻訳マネジメント記事|DIAMOND ハーバード・ビジネス・レビュー

米アマゾンらが経済学者を雇う理由~デジタル経済学者のシェアエコ化(石角 友愛) | マネー現代 | 講談社(1/3)

IT企業による経済学の活用 : 遠い呼び声の彼方へ!

(引用開始)
第一に、最先端の経済学の理論は、IT企業が必要とするサービスの要素技術になり得るからです。
例えば、日経ビジネスに掲載されたハル・ヴァリアン教授のインタビューによれば、ヴァリアン教授が主導し、広告オークションの設計にオークション理論を取り入れ、AdWordsの設計を行ったそうです。
(中略)
第二に、最先端の経済学者はIT業界が必要とする統計のエキスパートであるという点です。
最先端の研究では、経済学者は統計理論を活用し、事象をモデル化することが要求されます。
結果、経済学者は統計によるデータ処理のエキスパートとなっています。
一方でIT業界も、データを活用するためのは統計処理が不可欠です。そしてビッグデータの時代になるほど、高度な統計処理が要求されます。
結果、ITサービスの開発やグロースに必要なデータ処理やそのモデル化に、統計学者の知見が活かされているのです。
(引用終了)

【1】昨今のAIや機械学習の隆盛を見ると、心理学や経済学のような文系の学問とIT技術の組合せが非常に相性がいいのだろう、と感じる。
その理由は2つある。

【2】一つは、心理学や経済学が過去数百年に渡って蓄積してきた理論や知見は、「市場や社会集団に対し、どのような社会制度や経済政策を整備すれば、人にインセンティブで動機づけさせて、あるべき正しい方向に人の行動を律することができるか」という問題をずっと考えてきたからだ。

その手法は、政治、経済の分野だけでなく、ショッピングサイトやオークションサイト、Uberやエアーアンドビーなどのマッチングサイト、などの多数のWebシステムに簡単に適用できる。
特に、マッチングサイトでは、情報やサービスを提供する生産者とそれを購入する消費者の間で、お互いに最大の利益を得るようなマッチングを計算する必要があるが、まさにそのアルゴリズムは、どのような仕組みをWebサイトに導入すれば取引が全体最適化されるか、という問題に置き換えられるからだ。

あるいは、SNSや広告エンジンのマーケティングでは、どのようなターゲット層にどんな広告内容を表示すればマーケティング効果が得られるか、という問題に対し、心理学の知見を活かすことで、ターゲット層に具体的なペルソナを作り出して、ABテストでマーケティング手法を実験する、ということも簡単に実行できるからだ。

つまり、既存のIT技術を使った結果に、心理学や経済学の過去の知見を適用すれば、そのデータに価値観を与えることができる。

まあ、振り返ってみれば、経済学はマンキューによれば「インセンティブの学問」でもあるし、一方、心理学も人間の性格に関する理論を数多く生み出してきたので、その内容を昨今のWebシステムに適用できるのは当たり前ではある。

【3】もう一つは、心理学者や経済学者は統計のスペシャリストであること。
実際、心理学や経済学の学部の卒論、修士論文は、アンケートから統計的有意性を評価したり、膨大な行動・経済データから因果関係を導いて理論化するなどの内容ばかりだ。
つまり、彼らは、統計学を自分達の学問で理論化するときの手段として普通に使っている。
その作業はまさに、最近もてはやされるデータ・サイエンティストの作業と全く同じだ。

昨今のコンピューティングパワーのおかげで、統計処理という煩雑な計算は全てプログラムで代用できる。
それにより、心理学や経済学が本来やりたかった「人にどんなインセンティブを与えると、あるべき方向へ行動を誘導できるか」という問題を簡単に実験できるようになった。

実際、Uberでは、ミクロ経済学の授業の最初に出てくる需要曲線や消費者行動曲線をリアルに導き出すことに成功した事例があった。
需要曲線が分かれば、供給曲線は生産者自身が制御できるので、均衡する価格を生産者自身が誘導する事ができる。

他に、たとえば、税金をどのように表示すれば、消費者の需要を損なわずに購買意欲を引き立てることができるか、という行動経済学の実験もあった。
この実験で得られた内容は、まさに政府の経済政策に取り入れれば、消費税率が上がったとしても景気の腰折れをさせないような効果を生み出す可能性があるだろう。

【4】他方、個人的には、機械学習やニューラルネットワークなどのAI分野において、昨今のIT技術で、過学習の問題をどう解決しているのか、に興味がある。

いくらコンピューティングパワーが上がったとしても、間違った方向で計算して過学習の状態、つまり鞍点に陥れば、本来の全体最適された結果が得られない。
この問題は古くから知られていて、解決方法も色々あげられているが、まだしっくりと来るものは感じない。

【5】「心理学や行済学のような文系の学問とIT技術の組合せが非常に相性が良い」事が分かれば、今後、IT技術者には、心理学や経済学の学習も必要にされてくるかもしれない。

IT技術者はプログラミングという道具には詳しいが、ビジネス上の問題を解決する手法は知らない。
たとえば、「eショッピングやマッチングサイトでどんな設計にすれば売上が増大するのか」「生産者や消費者にどんなインセンティブを与えれば、売上向上につながるような行動を誘発できるか」という問題を解決するには、心理学や経済学の知見を使って、ユーザを誘導するシステム設計を実現することが求められるからだ。

一方、心理学や経済学は膨大な理論を蓄積してきたので、彼らの手法をIT技術で実現するだけで、簡単にその有効性を評価できるはず。
手当たり次第、彼らの手法をIT技術で試してみてもいいわけだ。

そんな事を考えると、面白い時代だな、と思う。
文系の学問は役に立たないと昨今言われるけれど、実は、こういう場面で非常に有効と分かるからだ。

【6】でも、心理学や経済学の理論によって「人のインセンティブで行動を誘発させる」手法を悪用すれば、甚大な影響も起きるだろう。

たとえば、アメリカのトランプ現象、英国のEU離脱などの政治現象を見ると、FacebookのようなSNSを使って民衆の政治行動を悪い方向へ誘導させることも実現可能になったのかな、とも思う。
また、炎上マーケティングのように、過激な発言に数多くの人が「いいね」「リツイート」させられることで、莫大な広告収入が得られるなら、そういう方向へどんどん過激化させていく方向に進んでしまう。
つまり、売上向上の最適化を図るアルゴリズムが暴走すれば、「人のインセンティブに故意にエネルギーを注ぎ込むことで、過激な行動へ走らせる」方向へ進んでしまうわけだ。

実際、一人の人間として知性があったとしても、集団心理学の観点では、リスキーシフトのように、より過激な意思決定に進んでしまう事例は、過去の日本の敗戦や米国のベトナム戦争のように、既にある。

今は、ビジネスに限らず、政治経済の分野で、心理学や経済学とIT技術の組み合わせによる壮大な実験が平行で行われている時代のように思える。

| | コメント (0)

2019/04/07

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

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

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

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

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

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

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

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

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

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

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

| | コメント (0)

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