コミュニティ

2023/12/10

『世界一流エンジニアの思考法』が学べる環境を手に入れてかつ継続する方法の感想 #devboost

デブキャリで牛尾さんの講演を聞いた。
世界一流エンジニアの思考法」を出版されている。

Developers CAREER Boost 2023 (2023.12.09)

デブキャリでこっそりシェアする三流エンジニアが『世界一流エンジニアの思考法』が学べる環境を手に入れてかつ継続する方法

話が上手いし面白い。
牛尾さんには15年以上前にXP祭り関西2006でXP寸劇にも参加して頂いたこともあり、あの頃の雰囲気を思い出した。

Subject: [ruby:1293] XP祭り関西2 006 in ワッハ上方

XP祭り関西2006 in ワッハ上方 (プログラミング C# - 翔ソフトウェア (Sho's))

【告知】XP祭り関西2006 in ワッハ上方: プログラマの思索

牛尾さんの講演の気づきは3つ。

1つ目は、常日頃から職歴を更新して、アピールできるレベルに随時ブラッシュアップすること。
牛尾さんはアジャイルのエバンジェリストでは超一流だったが、自身曰く、プログラマのスキルは低かった。
だから、マイクロソフトでプログラマになるべく、Githubに書いてアップしたり、エンジニアが来日したらAttendeしたり、色々アピールした、と。
そのためにも、職歴に、第三のスキルを常に磨いて記載するようにした、とのこと。
職歴は、LinkedInのプロフィールみたいなもの。
私はこういう人です、こういうスキルがあります、こういう職歴を積んできました、とアピールできるもの。
自分がより良い職業や職場に行きたいなら、そういうアピールできるものが必要。

一方、会社は「こういう人が欲しい」というジョブディスクリプションを出す。
それを見て、そのジョブディスクリプションに応募する。
その時に、会社が提示したジョブディスクリプションに対し、2つ上のレベルを目指すようにする。
そうすれば他人の目を引くことができるから。

牛尾さんほどの優れたエバンジェリストのレベルであっても、地道に努力されているんだなと思った。

2つ目は、何をやらないか、が大事なこと。
Be Lazyと言っていた。

Xユーザーのakipiiさん: 「Be Lazy。何をやらないか。物量よりもインパクトが大事。日本人は勤勉重視、努力重視なので価値観が正反対だよね。染み付いた価値観を捨てるのは難しい。 #devboost」 / X

どうしても日本人は「努力」が好きなので、全部をやろうとしてしまう。
捨てるのが難しい。

物量よりもインパクト重視。
たくさんできるよりも、何か一つ目立つものが成果として出れば十分。
そういう発想が大事。

3つ目は、「チャンスの時に受けないと次に進まない。受けましょう。」

Xユーザーのakipiiさん: 「牛尾さんが最後に伝えたこと。チャンスの時に受けないと次に進まない。受けましょう。つまり、挑戦しましょう。実力がなくても英語力がなくても関係ないと。 #devboost」 / X

今、牛尾さんはマイクロソフトでAzureファンクションのプログラマをされていると聞いた。
そのきっかけは、米国チームから、新卒に教えるのが得意なエンジニアで採用されたのがきっかけ。
そこからチャンスを掴み、今プログラマとしてバリバリ働かれている。
気後れせずに、チャンスをつかめ、というメッセージとして受け取った。

牛尾さんがすごいなと思うのは、40代を過ぎてから、英語を習得し、エバンジェリストからプログラマへキャリアを転換されたこと。
今までの実績や経験をすべてアンラーニングして一からやり直されたのはすごいと思う。
普通は、今までのキャリアやスキルをベースに深めていくのが普通であって、最初からやり直すのは大変。

本当に自分がやりたいことは何なのか、を深く考えて実行されたのだろうと思う。

| | コメント (0)

2023/11/05

第25回東京Redmine勉強会の感想 #redminet

第25回東京Redmine勉強会についてラフなメモ書き。

【参考】
第25回東京Redmine勉強会 - redmine.tokyo

2023/11/5 第25回勉強会 - redmine.tokyo #redmineT - Togetter

【1】前田剛さんによるRedmine5.1の機能紹介。
おそらく目玉機能は、クエリ検索にOR機能が入ったこと、プロジェクト画面やユーザ画面にクエリ検索機能が追加されたことだろう。
チケット一覧のクエリ検索では、SQLライクにかなり複雑な検索が可能になった。

また、全文検索後に、さらにクエリ検索で絞り込む機能も追加された。
利用シーンとしては、たとえば、Issueで検索して全文検索結果が出た後、さらに担当者や期間、ステータスで絞り検索することで必要な情報にたどりつきやすくなる。

つまり、Redmineを長く使い込んでチケット枚数が多い環境ほど、全文検索やクエリ検索の機能強化のメリットが出てくる。
RedmineはナレッジDBであるからこそ、過去の作業履歴から意味ある内容をいつでも検索できる点は重要なポイントの一つだろう。

【2】前橋市役所のRedmine利用事例はRedmineJapanの再演講演。
講演後に4人の質問があった事実からも、この事例に興味を持つ人が少なからずいたことが分かった。

ポイントはいくつかある。
一つ目は、Redmineを運用するためにかなり準備されていたこと。
たとえば、他部署からの問い合わせを受けて、情報システム部門が1次対応し、ベンダーにエスカレーションすべきかどうか判断していること。
ITILの運用を意識しているように見られた。

他には、事業年度ごとにプロジェクトを新規作成していること。
デメリットは、事業年度のプロジェクトに連なる子プロジェクト、チケットがいったんすべてリセットされること。
一方、メリットは、公務員は3年おきに配置転換されて担当がコロコロ変わるし、年度ごとのオペレーションの意義が重要なので、年度末にすべてのチケットを棚卸しするタイミングが発生することもあるようだ。

2つ目は、アジャイル開発のプラクティス、たとえば、KPTによるふりかえりを効果的に利用してプロセス改善活動につなげていること。
3つ目は、他の自治体とも連携してRedmine運用の幅を広げていること。

プライベートクラウドに載せているのでベンダにサーバ運用はお任せしているみたいだが、実運用に注力している点が興味深かった・

【3】RedmineのチケットDBをNoSQLのグラフDBで関連度合いをグラフ化し、関連チケットや類似チケットを表示する機能追加の事例もあった。
特徴は、RDBではチケットの関連度合いをSQL検索するのは時間がかかりすぎるが、グラフDBであれば検索機能もSQLライクに書けて、性能応答もかなり高速であること。
この特徴を活かして、関連チケットや類似チケットをチケット画面に表示する機能を追加したらしい。

レコメンドエンジンをRedmineのようなチケットDBに適用することで、お勧めチケットを表示する機能改善のアイデアは以前からあった。
その場合、機械学習で学習させる事前処理が必要だったが、今回の機能追加では、グラフDBへ格納する事前処理に置き換わった点があると思う。
この辺りのメリット、デメリットを聞いてみたいと思う。

【4】チケット管理システム有識者の集いのパネルディスカッションでは、Redmine・Jira・Asana・Backlogのユーザがパネラーとして意見を述べ合う話があった。

僕が興味深く聞いた点は、3つある。
1つは、プロジェクトとタスクの違いは何か?
プロジェクトは期間や独自性がある点、プロジェクトは引き継ぎの大きな単位、などのツイートもあり、興味を引いた。
やはりプロジェクトの基本は、達成したい目的があり、期間が限定されていることだろう。
実際、市役所での事業年度ごとのプロジェクト、農作業を毎年行う年度のごとのプロジェクトのように、繰返し性や定常業務の意味合いが強くても、何らかの期限を切っている。
そして、そのプロジェクトの作業履歴は過去資産として次年度にも流用する。
そういう観点があると思う。

2つ目は、Asanaのコンサルの方が話されていたが、プロジェクト型の仕事とプロダクト型や定期タスクのようなオペレーションでは、仕事のやり方が異なること。
プロジェクトの仕事はQCD管理が基本。
やはり納期が決まっているので、納期厳守が必須で、それが一番の評価になる。
一方、プロダクト型や定期タスクでは、明示的な納期がないので、日々の改善がタスクになり、プロジェクトという概念があまりない。
評価基準も変わってくる。

3つ目は、Asanaのコンサルの方が話されていたが、プロジェクトに入っているSIメンバーの立場と、既に事業やオペレーションを回しているユーザ企業の立場は異なること。
ユーザ企業であれば、既に事業は回っているし、その事業を強化する課題を一つのプロジェクトに切り出しているだけであって、プロジェクトは一つの部品に過ぎない。
しかし、プロジェクトに入っているメンバーや契約したコンサルは、その中で成果を出そうとするが、その観点が現場寄りであり、ユーザ企業の目線と異なるので、目的や評価が変わってくる時がある。

【5】コロナが終わってオフライン勉強会は3回目だが、盛り上がって楽しかった
Backlog、Jira、Asanaユーザの方から、11月3連休のど真ん中の休日に懇親会までこんなに人が集まるのはすごい、すごい熱気ですね、と言われた。

確かに、北海道、福岡、松江、山梨からも来られている人もいて、本当にありがたい。
また、いつものコアメンバーが盛り上げてくれたし、懇親会で聞くと、土木建築業界のユーザが問題意識を持って初参加されたり、友人紹介で初参加されたり、多様な人が入ってきたのはよかったし、刺激にもなった。

僕も今までたくさんのコミュニティ活動をしてきたけれど、ここまで皆が熱気を持つコミュニティは少ないと思う。
年2回、5月と11月に間を開けて定期的に開催するリズムも心地良い。
また来年も開催したいなと思う。

| | コメント (0)

2023/06/24

パターンカタログよりもモンスターカタログの方が面白いね #jasstkansai

Jasst関西がオフライン開催だったので10年ぶりに参加してきた。
感想をラフなメモ。

【参考】
JaSSTソフトウェアテストシンポジウム-JaSST'23 Kansai

知識は経験よりも大切か、経験は知識よりも勝るのか、SECIモデルは相互作用を語る: プログラマの思索

「大人の学びパターン・ランゲージ」の感想~知識と経験を行ったり来たりするタイミングを大切にする: プログラマの思索

現場の経験知をパターン言語にするコツが分かった #agileto2014: プログラマの思索

パターン言語の構造と事例集: プログラマの思索

SECIモデルは知識の再利用モデル、または、実践知を生み出すモデルだ: プログラマの思索

【1】今回のテーマは「思考停止」。
正直難しいテーマだったかなと個人的印象を持った。
基調講演の山口鉄平さんの話を聞くと、説明に苦労されている印象があって、本来は「ソフトウェアテストをカイゼンする50のアイデア」本から色んな改善事例を出してもらえるともっと聞きたかったのにと思った。

今の日本の社会情勢であれば、「思考停止」というテーマはたくさんの事象が出てくるだろう。
たとえば、円安やインフレ、少子高齢化による社会保障制度の不安、コロナ補助金不正、マイナンバーカードの名寄せ問題、EV車やAIに対応できていない製造業やIT企業、を見れば「思考停止」の事例はいくらでもあるだろう。
つまり、そういう問題に対し、本来の課題(イシュー)は何なのか、その課題を解決する時に一番効果のある対策は何か、予防策は何か、まで突き止めて考えなければならないのに、前提条件や制約条件を無視した議論がすごく多い。

一般に、日本の組織論で有名な「失敗の本質」本を読めば、日本人の「思考停止」の例はすぐに2つは思いつく。
1つは、個人では意見を持っていても、同調圧力に流されて集団浅慮やリスキーシフトに陥ること。
もう一つは、一般兵士のような下級レベルの労働者や兵士は真面目で優秀だが、戦略の目的に合致しない行動を取っているために、いくら真面目に働いても生産性や投資効果が低いこと。
野中先生が指摘した日本人の弱点は、1945年当時から80年たった今でも変わらない。

akipiiさんはTwitterを使っています: 「日本人が思考停止に陥りやすい例が自分のイメージと違っている気がした。日本人は集団浅慮に流されて自分の意見を言わないとか、一生懸命働くけど生産性を意識せず働く場合が多いんじゃないかな? #jasstkansai」 / Twitter

こういう思考停止の事例を分析するには、なぜなぜ分析が結局使われると思う。
なぜなぜ分析で自分の言動を問い詰めて、最終的にはその人の油断、プレッシャー、焦りなどの心理背景まで突き止められるのではないか、と思う。

OL参加者の意見として、フレームワーク思考を習慣的な思考と考えて、思考停止になっているのではというツイートもあって面白かった。

akipiiさんはTwitterを使っています: 「#jasstkansai なるほど、フレームワーク思考は習慣的な思考と捉えるのか。SECIモデルならどれに相当するのか?形式知を組み合わせる連結化?形式知を暗黙知にする内面化?」 / Twitter

【2】今日のJasst関西で最も印象に残ったのが、「思考停止からの脱出 ~ あなたの"問い”が自律へと導く ~」ワークセッション。
テーマは「思考停止を題材にして、問題事象をモンスターで書いてみよう」。

「思考停止」というテーマを各人の体験から問題事象を洗い出し、それらの問題事象にモンスターとして名前付けする。
そのモンスターには、名前とモンスターの絵があり、モンスターのプロフィールとして得意技・どんな時・他の特徴という説明文が付与される。
そのモンスターに対し、必殺技でやっつける、という流れ。

僕は「打合せ大好きマン」というモンスターを書いてみた。
伝わるかな?

20230624_jasst_kansai

これはアンチパターンと言えるだろう。
つまり、モンスターの名前はアンチパターン名。
得意技は問題事象。
どんな時は、問題事象が発生するタイミング。
他の特徴は、問題事象の影響事例。
必殺技は、解決策に相当するだろう。
フォースに相当する項目があればなおいいね。

僕もパターンは好きだし、パターンを自分で作れないか、パターンカタログのようなものを作れないか色々考えていた時期があった。
しかし、深く考えるほど難しいなと思う。
モンスターにアンチパターンを当てはめると、ロールプレイングゲームのように気楽な気持ちでパターンカタログを作り出すことができる。

この発想は他のワークショップでも使ってみたいなと思う。
プレインステーションなどのゲーム経験が深い人ほど馴染みやすいかもしれないから。
もっと気楽にパターンを考えてもいい。

【3】久しぶりにオフラインでコミュニティに参加して気づいたことはいくつかある。

1つ目は、参加者に若い人もいるけれど、年齢層が割りと高そうなこと。
アンケートでは、SE経験が10年以上の人が参加者の半分を占めていた。
本来は20~30代の人たちが半分以上を占めていて、経験が少なくてもノリが良くて活気があるのが普通だが、ちょっと落ち着いていた感じ。
久しぶりに会った方と話していたら、最近は若い人が少ないですよ、とのこと。
昨今の日本社会の情勢である少子高齢化が出ているのだろうか?

2つ目は、オンライン開催のチャネルが勉強会コミュニティで必要になってきたこと。
コロナ禍を経て、開催側もオンライン開催の手段がすごく簡単と分かったし、参加者も簡単に集めやすいと分かった。
参加者もオンライン開催であれば、スマホさえあれば作業しながらでも聞ける。
わざわざ交通費を払って時間を拘束させる必要もない。

今後の勉強会の運営は、Jasst関西のようにハイブリッド開催が当たり前になってくるだろうと思った。

| | コメント (0)

2023/02/11

デブサミ2023の感想

デブサミ2023の感想をラフなメモ。
自分用のメモ。

【参考】
Developers Summit 2023(2023.02.09-10)

DX、アジャイル、プロセス、テストなどを色々聞いた。
その中で僕が興味を惹いたのは、Rustとテスト自動化の2つの講演。

【1】RustはFirefox、Linux、Androidなどで使われ始めていると聞いたが詳細は知らなかった。

Rustは所有権の概念を持つ。
所有権とは束縛した変数みたいなもの。

Rustは一生コンパイルが通らないと言われる。
理由は、コンパイラが強いから。
そもそもプログラミングが難しい。
代入可能な変数かどうか所有権で決まる
所有権で解決する。
コンパイラが教えてくれる。

Resultはエラーハンドリング。Scalaにもある。
インターフェイスからエラーを返すか判断できる。

OptionはJavaのOptionalと同じ。
ScalaのOptionalみたいなものか。

enumはパターンマッチ。

traitはジェネリクス関数をシュッとしてくれる。
ScalaのTraitと同じ。

「なんでもかんでもclone()をつけたくなってしまいます、どうしたらいいですか?」という質問に対して、Cloneで妥協していい。
Cloneせずにコーディングすればメモリを小さくできるが、コーディングが難しい、と回答があった。

僕はRustはC言語の代わりとなる低級プログラミング言語と誤解していた。
しかし、こういうRustの話を聞くと、C言語のように扱える関数型プログラミング言語と見なした方が良いと思った。

【2】テスト自動化では、今はE2EテストがAIによって更に加速している。
画像の物体認識、画像処理のディープラーニングを使って、画面UIをテストする方向に進化しているらしい。
しかし、OCRのような、画面の文字認識の精度が低いらしい。
むしろ、テスト後に画面変更をAIが検知して、テストプログラムを自動修正する方向に進化しているらしい。

AIをテストに利用する発想がよく分かっていなかったが、AIが物体認識や画像処理に特化している強みを生かすことで、UIテストを強化しているのは面白い。

| | コメント (0)

2022/11/29

UMTPモデリングフォーラムのパネル討論の感想

先週11/24に行われたUMTPモデリングフォーラムのパネル討論だけを聞いた。
ラフな感想をメモ。

【参考】
MF2022プログラム - UMTP 特定非営利活動法人UMLモデリング推進協議会

30、50、100人の壁の正体|山本 正喜 / Chatwork CEO|note

データモデリングの立場の中山さん、渡辺さんに対し、ドメイン駆動設計の増田さん、スクラムの原田さんという割りと立場や意見も異なる人達の討論だった。
話は色々あったが、その中で気になった点は2つある。

1つは、少人数のベンチャー企業から大人数の大企業へ進化する時にどんな壁があるのか?

スパン・オブ・コントロールの原則通り、1人の社長が統率できる人数はせいぜい5~7人まで。
そこから20名、50名、100名、300名と増えるごとに、ピラミッドのような階層構造を持つ組織になっていく。
すると、必ずその会社特有の業務システムが必要になってくる。

興味深かったのは、30名未満の少人数ベンチャー企業が、従業員数よりも多い個数のSaaSを運用している会社があるよ、という話。
おそらく、10名未満の少人数ベンチャー企業であれば、自社だけに作り込んだ業務システムは不要であり、SaaSを導入するだけで十分やっていけるだろう。
しかし、事業や業務がどんどん拡大していき、従業員も増えるが、それ以上に業務が複雑化して、その業務を支えるSaaSを次々に導入して運用してしまった。
しかし、SaaSにインポートするデータは、各事務員がExcelで作りこんで準備して取り込んで修正する作業を行っている、と。
これは、いわゆる「人間バッチ」と同じですね、と。

「人間バッチ」と揶揄する理由は、本来は事業や業務を回すための業務システムを独自に作って自動化する必要があるのに、それをさぼって、事務員が労力をかけて業務データをExcelで作り込んでSaaSに流し込むという手作業をこなっているからだろう。
結局、今はどんな企業であれ、税務会計だけでなく、事業や業務を回すためのシステムも必要になっているわけだ。

そんな状況ではデータモデリングがとても威力を発揮すると思う。
なぜならば、業務を回すための仕組みを分析するには、業務フローだけでなく、事務員が作り込んでいるExcelデータを抽象化したデータモデルが必要になってくるからだ。
そのデータモデルさえきちんと分析できれば、業務フローも画面もバッチも帳票もほぼ決まってしまう。
業務分析とデータモデリングは表裏一体と思う。

もう一つは、データモデリングが業務分析、ビジネスモデルの分析でとても有用なのに、なぜその技術が普及せず、軽んじられているのか?

パネラーの方も色々話されていたが、僕は本当の原因が他にあるような気がした。
単にIT技術者や事務員にデータモデリングの知識が足りないから、だけではないだろう。
データモデリングを習得するモチベーションがそもそもないことに真因があるだろう。

特に昨今のアジャイル開発に興味を持つ人であれば、古臭いデータモデリングよりもドメイン駆動設計の方に惹かれるだろう。
実際、増田さんが主催されるドメイン駆動設計の勉強会にはたくさんの開発者が集まるのに、データモデリングの勉強会はあまり開催されていないし、開催されたとしても正直あまり人は集まらない。

それはなぜなのか?
その理由は僕もわからない。
このテーマは今後も考えてみたい。

【追記】
@sakabaさんからこんなコメントを頂いた。

さかばさんはTwitterを使っています: 「@akipii 開発者がソフトの寿命を短く考えがちなことや、利益が出てから作り直した成功例のあることが根底にあると思います。このため目先の利益を得ることに走りがちで、モデルが後回しになっていると思います。」 / Twitter

ベンチャー企業では売上重視のビジネスモデルなのでSoEのようなWebサービスのシステム開発が中心になる。
一方、大企業になって安定してくると、社内の業務を安定して回す基幹系システム(SoR)が重要な役割を占めてくる。
つまり、ベンチャー企業では、社内の業務システムが必要になる状況になるまでは、基幹系システムは作らないし、作る必要がないと認識しているのだと理解した。


| | コメント (0)

2022/11/16

XPエクストリームプログラミングは偉大だ~時代がその設計思想に追いついた

XPエクストリームプログラミング入門をオンラインで聞いた。
改めて、XPエクストリームプログラミングは偉大だ、時代がその設計思想に追いついた、と思った。
ディスカッションの内容から感じたことをラフなメモ。

【参考】
XPエクストリームプログラミング入門 - connpass

ITの地殻変動はどこで起きているのか?~チケット駆動開発はなぜ生まれたのか: プログラマの思索

僕は、「XPエクストリーム・プログラミング入門―ソフトウェア開発の究極の手法 」の第1版の方が好きだ。
理由は、荒削りだが内容はとてもシンプルで、当初考えていた直感的な思いが直接的に表現されているからだ。

- eXtreme Programmingの魅力を探るにある「Embrace Change - 変化ヲ抱擁セヨ」のグラフが一番好きだ。

勉強会の内容は放談会みたいで面白かった。

XPはプラクティスありきではない。
プラクティスは具体的な実践方法。
プラクティスは価値を実現したものの一つ。
しかし、価値は抽象的すぎるので、プラクティスと価値の間に原則を置いて、プラクティスと価値を橋でつなぐ。
そういう絵がXPではよく出るが、その意味がようやく分かった。

XPのプラクティスは、そのテーマ単体だけで一冊の本になる。
たとえば、リファクタリングなら、リファクタリング(第2版)
テスト駆動開発なら、テスト駆動開発実践テスト駆動開発
継続的インテグレーションなら、継続的インテグレーション入門継続的デリバリー 信頼できるソフトウェアリリースのためのビルド・テスト・デプロイメントの自動化
見積もり手法や計画ゲームなら、アジャイルな見積りと計画づくり ~価値あるソフトウェアを育てる概念と技法~
ふりかえりなら、アジャイルレトロスペクティブズ 強いチームを育てる「ふりかえり」の手引き
シンプルな設計なら、エリック・エヴァンスのドメイン駆動設計
つまり、それぞれのテーマはとても奥深いのだ。

たぶん、それらのテーマは重要である、とケント・ベックは直感的に感じていたのだろう。
それを言語化して形式知としてプラクティスで取り上げたのはすごいと改めて思う。

福井さんいわく。
最初はスクラムは好きではなかった。
XPは具体的なのに、スクラムではプロセスはしっかりしているが、実際に実践しようとすると中身が分からない。
でも、今はスクラムは好きですよ、と。
スクラムはスクラムマスターの存在が凄く大きい、と。

アジャイル開発は自動車の運転のようなもの。
到着先は分かっていて、その道順が分かっていても、不確定要素があり、ハンドル操作で変化を受け入れながら進める。
つまり、運転は変化が全くない動作ではないし、変化を受け入れる動作範囲に落ち着くようにする。

時代がアジャイルにやっと追いついた。
アジャイラーは当初は周囲と戦っていた。
いかに導入するか、いかに普及させるか、に注力していた。
しかし、今はお客様からも、アジャイル開発を導入したいと言われる。

WF型開発の権化だったPMBOKがアジャイル開発の考え方を取り入れて、PMBOKの最新版でごっそり変わったのも大きいね、と。
実際、PMBOKは従来の分厚い数多くのマネジメント技法の知識体系だったのに、アジャイル開発の考え方を具現化して、価値や原則が主体のマネジメント体系に変わろうとしている。

アジャイル開発を支える技術が揃ってきたのも重要だろう。
特にクラウドが普及したおかげで、すぐにサーバーを立ち上げて、実際に動かしてみて、動かしながら作っていくのができるようになった。
それもコストをあまり掛けずに、個人ですら開発できるようになった。
つまり、継続的インテグレーション、継続的デプロイ、リファクタリング、テスト駆動、短期リリースなどを支える技術が揃ってきたおかげで、アジャイル開発を実践しやすくなった、と。

一方で、SIがアジャイル開発に追いついていないように思える、と。
発注者は自社で内製開発がしたいので、アジャイル開発を自然に受け入れやすい。
しかし、SIは受託なので、既に自分たちの標準プロセスを持っているし、人月単価のビジネスモデルもあるから、いきなりアジャイル開発に変換するのは難しい。

僕がXPやアジャイル開発に惹かれる最大の理由は、IT業界のきつい仕事から脱出できるための救いとして捉えていた面があったからだと思う。
多重請負の人月単価のビジネスモデルの中で、大量のプログラマや技術者をまるで仕掛在庫みたいに扱って、変動するバッファみたいに扱う手法がどうしても慣れなかった。
アジャイル開発は人重視であり、技術者の専門性を活かしながらチームでアウトプットを出していく、という思想に引かれていたのだと思う。
IT技術者として専門性を高めていくと自然にアジャイル開発に収れんされていくはずだ、と思っていた。
今もその思いは変わらない。


| | コメント (0)

2022/11/06

第23回東京Redmine勉強会の感想~コミュニティは仲間から生まれて続く #redmineT

第23回r東京Redmine勉強会の感想をラフなメモ。
3年ぶりのリアル会場でハイブリッド開催だった。

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

2022/11/5 第23回redmine.tokyo勉強会 #redmineT - Togetter

Redmine Advent Calendar 2022 - Adventar

【1】リアル勉強会で嬉しかったのは、@yukiaさんと@shinyaさんに対面で会えたこと。

yukiaさんとRedmineのトラッカーをヘーゲル弁証法とフッサール現象学の観点で議論したことがあった。

Redmineのトラッカーをヘーゲル弁証法とフッサール現象学の観点で議論してみた - Togetter

Redmineのトラッカーは一般向けに説明が難しいよね、その原因は何か?
yukiaさんはヘーゲル弁証法の観点で、トラッカーは各人ごとの切り口でバラバラに使っているが、弁証法でより一層抽象化ないしもう一段上の抽象化レベルで議論すれば同じ概念だ、と話。
僕の観点では、フッサール現象学やプラトンのイデア論みたいに、トラッカーという概念は客観的に存在すると思われているが、各人の目線では、帳票設計だったり、チケットの種類だったり、ワークフローだったり、いろんな解釈で存在が認識される、という話。

yukiaさんは「強制エポケー」というフッサール現象学の言葉も知っているので、僕が言いたい内容ももちろん理解した上で発言されている。
懇親会ではあまり話せなかったけれど、この辺りももう一度話しみたい所。

shinyaさんの、塩漬けチケットを一気に却下したツイートを以前コメントしていたら、反応が多かった。
他にも退職者ツイートなど、面白いツイートがあったのですごく記憶にあった。

他にもリアル対面の人を認識できて良かった。

【2】前田剛さんの話では、RedMicaのお話と国民年金基金連合会がRedmineで作られていた話。
これには笑った。

Redmineで構築されている国民年金基金連合会の「他年金調査 事業所回答システム」を調べてみた - ファーエンドテクノロジー株式会社

他年金調査 事業所回答システム

実際にログイン画面を見れば分かるが、どう見てもRedmineだ。
日本企業の事業所は約300万と言われているらしいので、その事業所にいる社員数をRedmineで管理していると考えると、相当な数のレコードがRedmineに蓄積されていて、個人情報の観点でも非常にセンシティブな内容があるだろう。
Redmineなら安全に運用できるという判断があったのではないか。
このあたりの話も勉強会で聞けると嬉しいね。

【3】僕の話はチケット駆動開発の昔話。
あの頃は若かった。
なお、2020年頃からRedmineの勢いに陰りが出て、JiraやBacklogの勢いを感じている。
実際Googleトレンドではそんな感じ。

齋藤さんはTwitterを使っています: 「@akipii google トレンドの話に、興味を持ちました。JIRA / backlog 勢がほぼ同じような動きですね。 実際の日本でのシェアは、どんなもんですかね? #redmineT」 / Twitter

akipiiさんはTwitterを使っています: 「@saito0119 #redmineT 詳細は知らないですが、ネットやコミュニティの話を見聞すると、JiraやBacklogの勢いは感じますよね。」 / Twitter

中村さんの話は、Redmineを5.0にVerUpしたお話。
プラグインの互換性確認のために手間がかかったそうだが、@g_maedaさんやプラグイン開発者、パッチ提供者のおかげで無事に乗り切れた、とのこと。
Redmineコミュニティが活発であるからこそ、安心して運用できるわけだ。

@geosanak さんの話は、Redmineプラグインのテスト自動化を頑張っている話。
ビルド管理ツールはJenkinsからCircleCIまで色々あるが、GithubActionを使ったよという話。
詳細をもう少し聞きたかったが時間切れ。

@bowkoba さんのオフショア開発にRedmineを運用した時に、コミュニケーションの問題が発生した話は同感だった。
チーム運営、プロジェクト運営で発生する問題は、結局のところ、プロマネが伝える内容が伝わっていない、指示を仰ぐメンバーが理解できていないことに尽きる。
その問題はコミュニケーション不足の症状として現れるが、その根本原因と再発防止策は、それぞれの現場で異なる。
現在、アジャイル界隈では、DXを実現するための組織論の話が多いが、その観点も、このコミュニケーション不足の問題と同じ構造を持つと思う。
結局のところ、組織文化の問題として出てくるが、本当の真因は、プロセスや組織構造に根っこがあるわけだ。

@t_tsuru さんのRedmineUIの問題点は、従来から問題提起されてきた。
この問題の改善は、今後どんどん重要視されてくるだろうと思う。
他のPJ管理ツールやSaaSでは、チケットのコメントがリアルタイムに表示されたり、UIが今風で使いやすかったりするので、どうしてもその観点から比較されて敬遠されてしまうから。

チケット茶番劇も面白かった。
実際にチケットのやり取りを見るのは楽しい。
チケットを書く人がどんな気持ちでいるのか?
リアルで見えるのはいい。

@yokoba569さんの話では、チケット駆動開発が良かったよ!という話。
チケット駆動が楽しい!
Redmineが実績管理にとても向いていて、実際にデータをメンバー自ら採取して分析し始める。
見積もりと持ち工数の観点でPJ管理をどんどん改善しようとする。

@tohosaku さんはRedmine を railway にデプロイしてみた話。
@agilekawabata さんは、Redmineハンドブックの紹介。
わかりやすくてとても良い本です。

@tkusukawa さんは、Redmineを利用する趣旨のお話。
趣旨を説明するのはいつも大事。

@hiroiwsk6さんは、お役所の問い合わせ管理と帳票出力をRedmineで改善した時に、どんな設計で構築したのか、というお話。
問い合わせチケットのステータスごとに、送信メールが作られるのが面白い。
つまり、ステータスごとに、メールの内容や宛先が微妙に異なってくるので、メールテンプレートをいかに共通化して設計するかが肝なのだろう。

@naitohさんは、勉強会の参加者や利用Redmineの属性分析のお話。
もう8年以上蓄積されているので、Redmineにも波がある。

【3】今回はハイブリッド開催。
会場の参加者は26人くらいで、そのほとんどが常連さんで初めての方もチラホラ来られていた。
その後の懇親会では、久しぶりの再会を皆で喜んだ。

オンライン開催が普通になった今では、確かにZoomでやった方が正直楽だ。
しかし、会場開催の方が、反応を生で感じられるし、いろんな人達と交流できるのが楽しい。
生身の人間と肌感を感じるのがとても久しぶりだったから、本当にそう感じた。

Redmineコミュニティももう11年目で、他コミュニティに比べても古参になった。
スタッフや参加者も入れ替わりがありながら、よく続いているなと思う。
熱量がある人が入れ替わり立ち替わり居続けることで続いているんだと思う。
コミュニティは仲間から生まれて続く。

| | コメント (0)

2022/08/05

組織を芯からアジャイルにする対談の感想~今のアジャイルは先カンブリア時代なので何でもいい、アジャイル警察はいらない

組織を芯からアジャイルにする対談で、平鍋さんが話されていた。
感想をラフなメモ。

【参考】
平鍋健児 ? 市谷聡啓 ?組織を芯からアジャイルにする対談? - シン・アジャイル | Doorkeeper

認定スクラムプロダクトオーナー研修の感想: プログラマの思索

平鍋さんの穏やかな口調のお話を聞いていると、そうだよねとうなずくし、勇気づけられた点もあった。

1990年代、2000年代は、プロセスの時代。
仕様に対して、いかに仕様どおりに正しく作るか、品質を担保するか、が問題だった。
そのために、ソフトウェア工場、オブジェクト指向設計、要求工学、ソフトウェア工学などがたくさん出てきた。
そして、アジャイルが出てきて、今までのアプローチは違うのでは、と。
開発者の中でこねくり回すのではなく、顧客と対話したり、市場と対話してシステムを作り上げる。
2010年頃から、リーンスタートアップが出てきたのもその流れではないか、と。

今となっては、アジャイルも日本では普通に認識されるようになってきた。
今の日本では、アジャイルは先カンブリア時代みたいに、たくさんの人達がこれがアジャイルだ、とたくさん実践して公開してきている。
そんな中で、これが本当のアジャイルだ、と言う必要はないと思う。
アジャイル警察はいらない。
もちろん、自分のポジションや意見として、アジャイルはこうだというものはあるけれど、それで対立を煽るような議論はしない。
最近は議論をやめてます、と。

平鍋さんの話を聞いて、何となく救われたような気もした。
僕だけが感じているだけに過ぎないかもしれないが、最近のアジャイルの風潮として、自分はアジャイルをやってますと名乗るには、アジャイル開発の経験だけでなく、スクラムの認定資格を取っているか、認定スクラム資格を持つアジャイルコーチの指導があるのが条件なような気がしていたから。
カジュアルに、アジャイルをやってます、みたいなことが言えない気がしていたから。
顧客とオンサイトで超高速開発ツールを使ってすぐにデモして見せてアジャイルにやってます、みたいな場面があったりして、それは違うのでは、という違和感を感じていたから。

一方、スクラムの研修を受けると、内容は確かによく考えられているし、参考になる概念もすごく多い。
このフレームワークでプロセスの諸問題が解決されるのでは、と思えたりする。
1990年代から2000年代にかけて、たくさんのアジャイルの流派が生まれてきたけれど、2020年代の現在では、それらアジャイルの考え方、プロセスはスクラムへ収斂されていく過程ではないかと思ったりもした。

しかし、平鍋さんの話を聞けば、今のアジャイルは先カンブリア時代なので何でもいい、アジャイル警察はいらない。
そう思えば、そこまで神経質にならなくてもいいし、自分で経験して理解できたことがあれば、それを普通に表現して、自分なりに解釈してもいい。

他にも気になる話があった。

平鍋さんいわく、市谷さんの書籍は、熱い気持ちや勢いで書いている所があっていいね、と。
自分が思いついたアイデアには旬があり、今ここで書かなければいつ書くのか、みたいなタイミングがある。
特にIT業界の本はそういう傾向がある。
こういうことに気づいて考えたから、今書きたい、という熱いモチベーションがあるうちに一気に書くべき。
平鍋さんが共著で書いた本「アジャイル開発とスクラム~顧客・技術・経営をつなぐ協調的ソフトウェア開発マネジメント」も、今書かなくてどうするんだ、という熱い気持ちで書いた、と。
自分も、年末には書きたい本の目次は壁に貼っておいて、そこから書きはじめる時がある、と。

平鍋さんいわく、市谷さんが提唱した言葉「越境」「向き直り」もいいね、と。
市谷さんはネーミングが上手い。
気づいたアイデアに名前付けしてネーミングすることは重要だ。

平鍋さんがプロジェクトファシリテーションでレトロスペクティブを「ふりかえり」という言葉で概念化したが、過去を振り返るだけでなく未来にも目を向けていることを強調できなかった。
だから天野さんと議論した後で、小野小町の見返り美人もそうでしょ、後ろに顔は向いているけれど、足の方向は前向きだから、とフォローしたんだよ、と。

確かに、何かすごいことを思いついた時、そのアイデアを別の言葉でネーミングすることにより、新しい価値や意味をもたらすことができる。
そういう体験を僕も感じた。
その体験はやると病みつきになる感じ。

| | コメント (0)

2022/05/29

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

第22回東京Redmine勉強会の感想をラフなメモ。

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

2022/5/28 第22回勉強会 - redmine.tokyo - Togetter

【1】三浦さんの講演は興味深かった。
プロジェクトで発生する情報源として、3種類を抽出している。
エクセルファイルのような静的ファイル、Slackのような動的なチャットログ、日々のタスクやWikiなどの静的でもあり動的でもあるデータ。
資料では、一昔前の管理方法、昨今のリモートワークの管理方法、redmine.tokyoの管理方法などが紹介されていて、この発想が面白い。
具体例を見ると、Googleドライブ、SlackやTeams、RedmineやGitlabのように、数多くのサーバーが乱立して連携する形が多いみたい。
むしろ、情報源は1つのサーバーにまとめるのは逆に管理が面倒かもしれない。

三浦さんの考え方では、3種類の情報源はそれぞれの管理方法が違う。
エクセルファイルは共有ファイルサーバーだったり、Googleドライブで管理する。
チャットログは、メールよりもSlackやTeamsの方がいい。
チケット、Wiki、GitHubは別サーバーにある。

これらの情報は参照関係が双方向ではなく、単方向であるという制約がつく。
たとえば、チケットから共有ファイルサーバーの資料リンクはあるが、エクセルの設計書にはチケットのリンクを貼ることはあまりない。
そういう作業履歴の情報は不要だから。

また、チケットのコメント、GitHubのコメントはSlackのチャットログに流れた方が管理しやすい。
更新メールがたくさん流れても困る。

つまり、これら3種類の情報に分けた時、双方向の参照関係が実はあまりない。
この気付きが面白かった。

【2】かるねさん、門屋さん、ワテさんのRedmineの使い方はみんな異なる。

ワテさんは、ソフトウェア開発の受託案件が複数個走っているので、案件テンプレートを準備して、チケット管理のワークフローや初期設定、Git連携などは事前にテンプレート化しておく。
チケットの進捗管理、ステータス管理は細かく設定されている。

門屋さんはチケット一覧を重視する。
チケットの親子関係をうまく使って階層化してチケットをグルーピングしたり、ソート順を決めて、管理しやすくする。

一方、かるねさんは事務処理をRedmineで管理しているので、ロードマップ画面で、毎月のルーチンワークをバージョンで設定し、毎月ごとに事務処理チケットのボリューム感をコントロールしている。

それぞれの目的に応じて、Redmineの機能をピックアップして使っているのが面白い。

【3】ボウコバさんの講演では、Redmineを導入するときに、ボトムアップとトップダウンの手法をうまく組み合わせる点を話されていた。
たぶん、大企業では標準プロセスが揃っていて、それに従う必要がある。
そこで、標準プロセスをRedmineで実現しておき、スモールスタートで運用を開始して、成功しているよ、という雰囲気を社内に作り出す。
そこから少しずつ広げて、トップダウンで最後に広げていく、みたいなイメージ。

以前アカベコさんが、Redmineの運用では活況を演出するのが重要だ。
なぜならば、活発に更新されてすごく便利そう、という雰囲気を醸し出さないと、根付かないから、と言われていたが、そのやり方に似ているな、と思った。

僕は、ボウコバさんのように、チケットに情報を集約する方が好き。
そのチケットは、日々のタスク管理のようなフローの情報、課題管理や障害管理のようなストックの情報の二重性を持つ。
チケットに2つの情報が集約されることで、検索機能やハイパーリンクが使えて、Redmineがナレッジデータベースになるというイメージ。

【4】内藤さんの発表では、直近4回位のRedmine勉強会の参加者が常連さんに偏っている点がグラフで示されて、正直びっくりした。

その原因は色々あるだろう。
オンライン勉強会になったので、地方の人も参加しやすいが、対面で知り合う機会がないので、初対面同士で盛り上がりにくい。
自然に、すでに知り合いの仲間同士で盛り上がってしまい、その輪に入るのはなかなか難しい。

一方、Redmineの機能改善も、チケット管理ツールのライバル製品の機能を取り込む方が多くなっているので、独自性をアピールする点が不足していることもあるだろう。

他方、チケット管理ツールの概念はある程度知られてきていて、イノベーターやアーリーアダプターにとっては新鮮味があまりない点もあるかもしれない。

このあたりの原因は色々聞いてみたい。

とはいえ、今日の勉強会の中身も濃かったと思う。
講演もLTもちゃんと聞いていると、こんな使い方もあるのね、とか気づきが多かった。

【5】西崎さんがRedmine開発者コミュニティを作ろうと提唱されていた点も興味深かった。

やはりRedmineの開発は情報源が少ないので、もっと多くの人を巻き込まないといけない。
Redmine開発者コミュニティがハブになって、他のRedmine勉強会の人たちをつないで、開発に興味を持ってもらったり、ユーザに使ってもらってフィードバックをもらうことを考えられていた。

一方、山崎さんはRedmine Marketplaceを作り、Redmineのプラグインを集めて、有償販売できたりするWebサイトを準備されていた。

つまり、Redmineをさらに使いやすくしたり、手に届くような環境を作ろうと活動されている。
こういう活動を見ていると、やっぱり日本人にはRedmineが向いているのかな、と改めて思う。

| | コメント (0)

2022/04/10

『ものづくりの数学』の感想 #もの数

今朝、講演会『ものづくりの数学』に参加してきた。
感想をラフなメモ。
全くロジカルでないメモ。

【参考】
講演会『ものづくりの数学』 - connpass

講演会のテーマは、『ものづくりの数学のすすめ 技術革新をリードする現代数学活用法 | 松谷茂樹』の著者の先生に、企業の技術者と理論物理・純粋数学の科学者という2つの立場から、ものづくりの現場に現代数学をどのように導入して効果を上げるべきか、という内容だった。
内容は相当難しいと思う。

改めて『ものづくりの数学のすすめ 技術革新をリードする現代数学活用法 | 松谷茂樹』を読み切ってみると、読者の対象は、大学で純粋数学や理論物理、理論化学を学んだ後、社会人では一般企業の技術者や管理者、IT業界の技術者になった人だろうと思う。
大学の理論研究の経験と一般企業でのビジネス経験の両方がなければ、この本の意義は理解しにくいだろうと思う。

なぜなら、『ものづくりの数学のすすめ 技術革新をリードする現代数学活用法 | 松谷茂樹』の内容はすごく抽象的だからだ。
実際、数式は出てこないけれど、現代数学がメーカーの製品開発の背景にあるという経験がなければ腑に落ちないだろう。
また、ポパーの反証主義、トーマス・クーンのパラダイム論やフッサール現象学、ソシュールの記号論などの概念がふんだんに引用されるので、なぜこの知識が必要なのか、という意図がつかめないだろう。
専門の科学者集団はパラダイムに囚われすぎているという先生の指摘は斬新ですごく面白かった。

僕が感じた感想は3つある。

【1】今の日本の弱点は、ハードウェアに付加価値をつける点では新興国の韓国・台湾・中国に追い越され、ソフトウェアやシステムで付加価値をつける点では、米国に負けてしまっていること。
その問題を解決する時に、現代数学が役立つよ、という主張だった。
その製品開発のフェーズに現代数学を使ってモデル化を図って、理論の裏付けを持った技術に育て上げるような方向性だろうか。

だが、ハードウェアの付加価値に差別化を図ろうとする場合、より尖った製品を開発するのは困難だろうと思う。
そのマーケットがそもそも売上や利益が出るような規模なのか、そこにマーケティングを実施して掘り起こせるのか。
その市場で売上を確保できる期間が十分にあるのか。
今の時代は、世界の工場である中国にほとんど製造拠点を持って行かれているので、日本も米国のように、おそらくAppleのように安いハードウェアにソフトウェアやブランドという付加価値を付けて高値で売るようなビジネスに行かざるを得ないのではないか、と思った。

すると、ソフトウェアやシステムで付加価値をつけるフェーズで、現代数学とコンピュータサイエンスを組み合わせて、技術の差別化やビジネスモデルの構築を図る、みたいな方向性が王道になるのではと思う。
しかし、日本から世界に通用するプラットフォームビジネスを生み出せるのか。
日本で現代数学も使えるようなIT技術者を育成できるのか。

先生のお話を聞くと、日本の大学という制度はもう時代に即していないんだなと改めて思う。
明治から昭和までのやり方を未だに大学で続けようとしているが、令和の時代では違うでしょ、みたいな感じ。

akipiiさんはTwitterを使っています: 「今聞いているけど面白い。今の日本の大学という制度は時代に即していないと先生が言い切るのがすごいね。大学もお金を集めないとやっていけない現状、理論の専門家が企業に必要なのに大学が人材供給できていない現状とか色々あるだろうな。#もの数 講演会『ものづくりの数学』 https://t.co/8ijd5ko08g」 / Twitter

【2】先生のお話で面白かったのは、純粋数学や理論物理などの科学者の専門集団はパラダイムに囚われすぎていて、彼らだけに通じる基準と運用で維持し続けられているが、常にその存在意義の正当性を問われているという指摘だった。
自分も大学で数学の研究に従事していた時があったので、その雰囲気がそういう観点で見られているのが斬新だった。

ものづくりの数学のすすめ 技術革新をリードする現代数学活用法』にかかれているトーマス・クーンのパラダイム論の解釈を読むと、科学者という専門集団は真理を追いかけているように見えるが、すごく閉鎖的な集団なんだよ、という意見に聞こえてしまうのが不思議だった。

akipiiさんはTwitterを使っています: 「問題解決者よりも問題定義者が重要。学会はパラダイムに囚われすぎている。ビジネスの現場で抱えている問題は既存の学会や理論で解決できるとは限らず、むしろ無い場合が多い。現場の問題に忠実に認識してその問題を数学で分解して定義し、その一つを大学へアウトソースして解決してもらうとか #もの数」 / Twitter

一方、ビジネスマンは企業の現場で解決したい問題がすでにある。
その問題は理論や学術面で意義は小さいかもしれないが、その現場ではすごく価値がある。
そういう問題を解くのに現代数学という理論を使うとより効果的だよ、と。
そして、大学での理論研究と企業の現場の違いを認識して上手く利用したほうがいいよ、と。

akipiiさんはTwitterを使っています: 「ビジネスと理論のような大学の場の双方を知るような人材をどうやれば育てられるか?先生曰く。ビジネスマンは大学の弱点や問題点を知るのが大事。そんな話を聞くと、日本の大学は時代に即していない感じがするね。 #もの数」 / Twitter

特に、理論と技術の間にはタイムラグがある。
このタイムラグはいわゆる、死の谷、魔の川、ダーウィンの海に相当する。
すると、理論を研究したり使う時も、その技術がビジネスに使えて実際に威力を発揮できるには、いくつかのハードルを越える必要がある。

akipiiさんはTwitterを使っています: 「#もの数 フィリップスを作ったカシミールの考え方。科学と技術は違う。資本主義企業が科学を引っ張るというモデルを経営者は持つがそうではない。量子力学が生まれた時、ビジネスとも関係なく、半導体やコンピュータのビジネスに繋がることは誰も知らなかった。」 / Twitter

【3】なぜ現代数学の理論が企業の技術者やIT技術者に求められるのか?
その理由は、現場の問題を解決しようとする時、既に知られている技術や小手先の知識だけでは対処できず、20世紀以後の現代数学の理論を最終的に使わないといけない場面が出てきているからだろう。

例えば、線形代数の利用シーンが連立方程式や固有値計算だけではなく、代数・幾何・解析・確率論などの色んな場面で使われている。
特に、線形代数の理論は、ニューラルネットワークや機械学習のモデルの計算ではよく使われている。

akipiiさんはTwitterを使っています: 「先生曰く。現代数学は線形代数化している。現代数学は幾何学化している。代数幾何学も線形代数にすぎない。色んな所で線形代数が出てくるのにどの書籍にも解説していない。だから出版した、と。 #もの数」 / Twitter

akipiiさんはTwitterを使っています: 「平鍋さん曰く。行列はAIや機械学習で解きたいデータを表現していて、それを線形代数の理論で解くものと思っていた。なるほど、そういう見方で考えれば画像認識技術にAIが使われる意味が分かる気がする。 #もの数」 / Twitter

先生の話では「位相」という言葉がよく出てきて、どういう意味で使っているのか、当初は理解しにくかった。
ものづくりの数学のすすめ 技術革新をリードする現代数学活用法 | 松谷茂樹』を読んでみると、いろんな事象を分類する基準、その構造の近さを同値関係で表していると思った。

akipiiさんはTwitterを使っています: 「位相とは何ですか?という質問に先生曰く。数学者は点ではなく部分集合で考える。だから、関数単体で考えるのではなく、関数の集合で考えて、εδ論法でその構造の近さを同値関係で測定して、同じ・違うで分類するわけか。工業化学をやった人はこの考え方が分かってないと言われた。 #もの数」 / Twitter

代数幾何学が楕円曲線をドーナツの形で分類するように、いろんな事象を数学で捉える時、点ではなく部分集合でカテゴリ化して、εδ論法でその構造の近さを同値関係で測定して、同じ・違うで分類するという発想と思えた。
たぶん、現代数学を知らない人向けにそういう意味で使っているのかな、と想像した。

【4】『ものづくりの数学のすすめ 技術革新をリードする現代数学活用法 | 松谷茂樹』はとても良い本と思うけれど、現代数学の知識を適用する場所は、メーカーの現場の問題よりも、経済学に関する問題の方がよりインパクトがあるのではないかと僕は思っている。
なぜなら、数学者や物理などの科学者は1990年代頃から経済学や金融にシフトしていること、数学の理論を使えばIT技術と経済学や金融がすごく相性が良いことが分かってきたからだろうと思う。

講演会の参加者には、データサイエンスに詳しい方が割と多い気がしたけど、その人達のバックグラウンドはむしろ、経済事象やマーケティング事象などの社会科学の方が近い気がする。

IT企業が経済学者を雇い始めた理由が面白い: プログラマの思索

計量経済学における統計上の根本問題: プログラマの思索

みんなのPython勉強会#65の感想~社会変革の鍵はIT技術者にあるのかもしれない: プログラマの思索

経済学は信頼性革命や構造推定により大きく変貌している: プログラマの思索

機械学習で反実仮想や自然実験が作れる: プログラマの思索

経済数学の直観的方法の感想: プログラマの思索

「推計学のすすめ」「経済数学の直観的方法~確率統計編」の感想: プログラマの思索

僕の問題意識はちょっと別の方向にあるかもしれない。

| | コメント (0)

より以前の記事一覧