« 2020年5月 | トップページ | 2020年7月 »

2020年6月

2020/06/17

相殺フィードバックを再考

システム思考で出てくる相殺フィードバックをメモ。

【参考1】
学習する組織 - ごろにゃ~の手帳(備忘録)-パーソナルMBA的な

(引用開始)
強く押せば押すほど、システムが強く押し返してくる
よかれと思って行った介入が、その介入の利点を相殺するような反応をシステムから引き出す現象である。
私たちは誰もが、相殺フィードバックに直面するのはどんな感じか知っている。
押せば押すほど、システムが強く押し返してくる――つまり、物事を改善しようと努力すればするほど、 さらに多くの努力が必要に思えてくるのだ。
(引用終了)

【参考2】
組織は「苦労」や「一生懸命努力すること」を美化してはいけない。 | Books&Apps

(引用開始)
MITスローン経営大学院のピーター・M・センゲは著書「学習する組織」においてこの現象を「相殺フィードバック」と呼ぶ。
多くの企業が、自社製品が突然に市場での魅力を失い始めるとき、相殺フィードバックを経験する。企業はより積極的な売り込みを推し進める―それが今までいつもうまく言っていたやり方だ。宣伝費を増やし、価格を下げるのである。
こう言った方法によって、一時的には顧客が戻ってくるかもしれないが、同時に会社からお金が流れ出ていくので、会社はそれを補うために経費を切り詰め、サービスの質(例えば、納期の早さや検査の丁寧さ)が低下し始める。
長期的には、会社が熱心に売り込めば売り込むほど、より多くの顧客を失うことになるのだ。
(中略)
私が見た現象は、サービスの質を改善せず、全員を「テレアポ」と「飛び込み」などの労働集約的な仕事に邁進させる、というやり方だったが、上と全く結果は同じであった。顧客は流出し、人材は会社を辞め、競合にシェアを奪われたのだ。
(引用終了)

相殺フィードバック: プログラマの思索でも書いたが、IT業界は相殺フィードバックによる問題発生が多い。

たとえば、過去に直したバグ修正が、今の障害の発生原因になっている。
たとえば、以前下した判断や意思決定が、今回の問題の発生原因になっている。
その時は良かれと思ったことが、実は場当たり的な対応であって、より一層症状を悪化させた。

僕の経験上、相殺フィードバックという症状は、ソフトウェア開発で非常に発生しがちと思う。
従来のソフトウェア開発の現場では、元請けのPMと下請けのプログラマが混成チームを形成するが、彼らは顧客と切り離されているので、顧客からのフィードバックを得るタイミングが最初と最後のフェーズしかない。
だから、現在の意思決定がどんな影響を及ぼすのか、想像できない。

ソフトウェア開発は自己目的化しやすい: プログラマの思索

相殺フィードバック: プログラマの思索

僕は、相殺フィードバックをなくすには、システム思考に出てくる因果ループ図のような発想方法よりも、ランダム比較化実験を使って行動経済学の知見を導き出す手法の方が効果的ではないか、と直感している。
最初から、相殺フィードバックにはまらないような意思決定を下すのは難しい。
できれば、傷が浅い程度の失敗は許容できる時期に、2つの意思決定をランダム比較化実験で試して、人間の行動や集団行動がその後にどのような影響を与えるのか、を見極めた方がいいと思っている。

以前はそういう手法が使えなかったが、今はWebアプリはクラウド上で即座に作れるし、スマホ経由でランダム比較実験をしてみるのは易しい。
行動経済学の知見をソフトウェア開発やソフトウェア工学に活用するアイデアは試して見る価値があるように思える。


| | コメント (0)

Redmine活動タブの機能改善が提案されている

@g_maedaさんが、Redmine活動タブにTracみたいなポップアップフィルターによる検索機能を提案されていたのでメモ。
門屋さんが一番喜びそうな機能だと思う。

【参考】
Feature #33602: Add an interface to filter activities by user - Redmine

Feature #1422: Date selection for Activity Page - Redmine

#redmine活動家 - Twitter検索 / Twitter

Redmine警察・マイスター・活動家は導入の立役者 | マドびっ! Madosan's View

機能改善の提案は2つ。
一つは、活動タブに「auther」による検索機能を追加して、ユーザ単位の活動ログをフィルタリングすること。
メンバー単位にPJにどれだけ関わって活動したのか、確認する時に役立つ。

もう一つは、活動タブに期間による検索機能を追加して、一定期間の活動ログをフィルタリングすること。
PJの一定期間で、PJがどれだけ活発に動いていたのか、を確認する時に役立つ。

活動ログの更新頻度が多いことは、良い兆候だと考える。
なぜならば、作業の進捗や、作業を妨げる課題や障害をやり取りしている行動が、全て活動ログを経由して探ることができるからだ。
活動ログに表示されない作業は、PJの他メンバーと情報共有しにくいし、誰にも公開されない情報は、結局誰にも役立たない。

どんどんコミットできた、という良いこともあれば、仕様の不備や作業負荷が多すぎる不満もチケットに書かれているだろう。
そういう兆候が活動タブで見える化されなければ、PJにどんより曇った雰囲気が円満し、最後の受入テストで品質悪化や納期遅延が発覚して、炎上案件になってしまう。
PJの喜びも阿鼻叫喚も、Redmine活動ログを見れば、分かるはず。

プロジェクトリーダーであれば、担当PJだけしか見ないけれど、PMOという立場であれば、複数PJを横串で、どんなメンバーがどれだけ活発にチケット更新していたのか、を見たくなる。
活動ログを見れば、上手く進んでいるPJもあれば、火を噴く直前までヒートアップしたPJもあるだろう。

PJ内にある全ての残作業、残課題、障害が見える化されなければ、どんな対処方法が有効なのか、どんな打ち手があるのか、見極めることはできない。
僕もそういう経験は何度もしてきた。

Scrumには、3本柱として、透明性と検査と適応があるが、活動タブはPJの透明性の度合いを評価するのに役立つ。

透明性 - Large Scale Scrum (LeSS)

(引用開始)
スクラムは、チームがプロダクト開発においてどれだけ良い成果を出せているかの鏡として作用し、チームや組織の問題を明らかにします。
この可視性は、 チーム、PO、組織に継続的な改善を促す「検査-適応サイクル」と共に、経験的プロセス管理を支えます。
(引用終了)

メンバー自身の行動がPJにどれだけ貢献できたのか、その貢献度合いは活動タブで表現される。
活動タブを通じて、チケットのログ、Wikiのログ、Gitのログなどへドリルダウンされて、より詳細な活動履歴が分かる。

僕もプロジェクトリーダーとしてRedmineでPJ運営した時、活動タブやロードマップを見るのが好きだった。
面白かったのは、活動タブに活発に表示される若手メンバーは、どんどんモチベーションが上がり、朝会や打合せで堂々と発言する機会が多くなったことだった。
貢献度が見える化されることは、プレッシャーがかかることではなく、メンバーの貢献意欲を高揚させて、より一層成長させるきっかけになりうる。

Redmineのほんのちょっとした機能改善が、プロジェクトメンバーの貢献意欲を引き出し、チームを活性化させる。
そういう機能改善の提案をどんどんしていきたい。

MAEDA GoさんはTwitterを使っています 「@akipii 日付指定のパッチは昼前にコミットしました。Redmine 4.2 / RedMica 1.2 で使えるようになります。 https://t.co/wBWwZ99idl https://t.co/k8FWWOH53v」 / Twitter

門屋浩文@redmineエバンジェリストの会1号さんはTwitterを使っています 「@akipii そういや、活動タブで人の名前でブラウザ機能の検索したりしてましたから、いろいろできると嬉しい」 / Twitter

Redmine.JPさんはTwitterを使っています 「プロジェクトが活発に動いているか役立つRedmineの活動画面。その活動画面に対する機能改善がRedmine公式サイトで2件提案されている。ユーザーを指定しての絞り込みと、表示対象の日付の指定。 https://t.co/1zH7DZM4xM」 / Twitter

| | コメント (0)

2020/06/14

SaaSのビジネスモデルがアジャイル開発を促進したという仮説

「ソフトウェア・ファースト」を読んで、改めて、アジャイル開発はSaaSの開発プロセスを発展させたものとみなすのだと考えた。
ラフなメモ書き。

【参考】
ソフトウェア・ファーストの感想: プログラマの思索

【1】「ソフトウェア・ファースト」を読むと、製造業などの一般産業は、SaaSのようにどんどんサービス化すべきだ、という主張が背景にあるのが分かる。

では、SaaSというビジネスモデルの特徴や本質は何だろうか?

この問いに自分なりに考えてみたら、複数の特徴があるように思う。

【2】SaaSはScrumと相性が良い。
たとえば、パッケージ製品ビジネスや大量生産ビジネスでは、たくさん作って販売してそれで終わり。
一括請負契約で作って納品したら終わり。
顧客とメーカーは、クライアント-ベンダー-アンチパターンにはまりやすい。

「クライアント-ベンダーアンチパターン」という根本問題: プログラマの思索

一方、SaaSでは、常にサービスや機能を頻繁にVerUpしていく。
その頻度も1ヶ月に1回ではなく、1日に数十回もざらだ。
SaaSのインターフェイスは、ユーザがスマホやPCで触っているので、すぐにその機能を試してもらえるし、彼らの要望を即座に反映するほど、顧客満足も高まる。
そういうニーズがあるので、頻繁なリリースを実施する動機づけになる。

その場合、社内の開発体制はScrumに似せると開発しやすくなる。
マーケティング担当者や経営者がプロダクトオーナーの役割を担えば、社内に開発チームとスクラムマスターを作れば、即座にScrumが出来上がる。
SaaSの場合、プロダクトオーナーに相当する人が社内に存在し、その能力を持ち合わせている時も多いのがメリットだろう。
その後は、会社の規模やビジネスの規模に合わせて、Scrumをスケールすればいい。

【3】SaaSはDevOpsと相性が良い。
リリースしたら、その後も運用し続けるので、開発と運用保守は一体化すべき流れになる。

一方、普通のSIであれば、インフラチームと開発チームは分離されていて、機能別組織になりやすい。
機能別組織の弱点は、チームや組織ごとに体制の壁ができてしまい、意思疎通が困難になることだ。
コンウェイの法則「アーキテクチャは組織に従う」によって、システムのアーキテクチャは縦割りの複雑な組織構造を反映した形になってしまい、システムはどんどん複雑化してしまう。

もちろんSaaSも、ビジネスが発展すれば肥大化するだろう。
しかし、開発と運用保守は一体化した方がいいというビジネス要求や現場からの要求が出てきやすいので、DevOpsを推進する動機づけになる。

もちろん、技術的にも、SaaSはクラウドと相性が良い。
だから、クラウドエンジニアはインフラエンジニアだけでなく、開発者でもありうるので、事実上、インフラチームと開発チームは一体化しやすい。

また、ここからマイクロサービス・アーキテクチャも実装しやすい。
AWS上でSaaSを運用すれば、LambdaやAurora、AWSの各種サービスを利用することになるだろう。
単に性能改善やスケールメリットが活かせるだけでなく、システム基盤をマイクロサービスとして組み立て直すことにより、SaaSは汎用的なAPI基盤になっていくだろう。
そうすれば、外部サービスと連携できるので、より多種多様な機能を顧客に提供しやすくなるメリットも出てくる。

【4】SaaSはB2Cのプラットフォームビジネスと言える。

アメリカのGoogle、Amazon、Apple、Facebookがそうだし、中国のBATも同様だ。
多数の顧客に対し、プラットフォームを提供することで利便性がどんどん増していく。
そのビジネスの本質は、製造業が持つ規模の経済ではなく、ソフトウェア特有のネットワークの経済という理論が背景にあるはず。
たくさんのユーザが使ってくれるほど、SaaSは重要性を増して、売上を指数関数的増大させていく。
「プラットフォーム革命――経済を支配するビジネスモデルはどう機能し、どう作られるのか」を読むと、プラットフォームのビジネスモデルは独占ビジネスなので、その売上は、そのサービスの市場規模と同等になるまで高められる。
つまり、市場規模と同等だから、小さい国家のGDPよりもはるかに大きな利益を得ることも可能。

SaaSはB2Cのビジネスなので、顧客のフィードバックをすぐに取り込みやすい。
ランダム実験やABテストも実現しやすいので、サービスやビジネスモデルを仮説検証しやすい。
つまり、SaaSでは、念入りに考え抜いた計画を作って数年かけてリリースするよりも、仮設を立てたら、複数のサービスを同時リリースして、ランダム比較化実験でその効果を測定した方が速い。

興味深いのは、米国や中国では、SaaSのトッププレーヤーはB2Cなのに、日本の楽天やモノタロウなどはB2B2Cというスタイルで異なる点だ。
もちろん、LINEのように、日本国民の殆どとつながっていて、その連絡先とつぶやきのようなログデータを既に持っている会社はB2Cだ。
しかし、日本で目立つSaaSプレーヤーはB2Bのクッションを通過した後でB2Cを提供するビジネスモデルが多いように思える。
その理由は分からないので、いつか知りたい。

プラットフォーム革命の感想~プラットフォーム企業は新たな独占企業である: プログラマの思索

規模の経済と経験曲線効果のメモ: プログラマの思索

【5】SaaSでは、大量のログデータがビジネスの副産物として採取される。
データはいくらでもある。
そこから、機械学習やディープニューラルネットワークに大量データを食わせることで、優れたAIエンジンを生み出すことも可能だ。
B2Cのプラットフォームビジネスでは、ユーザの個人情報は特定できるし、その購買行動はプラットフォーム上で全て追跡できる。
よって、ペルソナを仮想的に作って、より購買を促すようなプロモーションを打ち出して、潜在ニーズを掘り起こせる。

「告発 フェイスブックを揺るがした巨大スキャンダル」によれば、Facebookで、個人に68個のいいねがあれば、その人物に関する非常に具体的な情報をモデルから予測できる。
70個のいいねで、そのユーザの友人が知るよりも、その人の多くの個人情報がモデルから推測される。
150個のいいねで、親よりも、その人の多くの個人情報がモデルから推測される。
300個のいいねで、パートナーよりも、その人の多くの個人情報がモデルから推測される。
さらにその多くのいいねを見れば、ユーザが自分自身について知っていると思っている以上の個人情報がモデルから推測される。
つまり、個人の大量のログデータを収集できれば、その個人を丸裸にできる。
その個人情報を他人が知っている情報だけでなく、その個人自身が知らない潜在ニーズまで推測できるわけだ。
すなわち、ジョハリの窓という理論は、AIを使えばほぼ完全に実現できる可能性があると思う。

(それを悪用したのが、ケンブリッジ・アナリティカであり、彼らは、どの個人にどんなプロモーションを送ればどんな選挙行動に移してくれるか、を徹底的に研究して、トランプ効果や英国のEC離脱を生み出したわけだが。)

そんなことを考えると、SaaSは機械学習やニューラルネットワークと非常に相性がいい。
だから、テスラみたいに製造業もどんどんSaaSにシフトしているのだろうと思う。

| | コメント (0)

2020/06/13

機械学習が抱える問題

機械学習(深層学習も含む)が抱える問題とは一体、何だろうか?
「scikit-learnとTensorFlowによる実践機械学習」を読みながら、考えたことをラフなメモ書き。
初心者のメモなので、間違っていたら後で直す。

【1】機械学習が抱える問題とは一体何だろうか?
機械学習の主要なタスクは、学習アルゴリズムを指定して、訓練データを元にモデルをFitさせること。
つまり、まずいデータ、まずいアルゴリズムに問題の原因がある。

「scikit-learnとTensorFlowによる実践機械学習」で一番興味を惹いた点は、「複雑な問題ではアルゴリズムよりも大量のデータの方が重要になる」という考え方が論文で紹介されていることだ。
つまり、最適なアルゴリズムを考えるよりも、大量データを元に、統計アルゴリズムを駆使する方が、より良い最適解を得られることを意味する。
特に、ディープラーニングのように、特徴量を自動的に導出できる場合がそうだ。

つまり、天才が優れたアルゴリズムを考え抜くよりも、コンピューティングパワーに任せて、モデルに大量データを食わせてモデルを訓練する方が最短の解決方法になるわけだ。

しかし、インターネットが発明されるまでは、大量データを採取することすら難しかった。
またコンピューティングパワーも不足していた。
2010年代になってようやく、クラウドとGPUなどにより、大量データをいくらでも機械学習アルゴリズムに食わせることができるようになったわけだ。

特に、GAFAのように、BtoCのSaaSのビジネスモデルの場合、消費者の購買活動は全て手に入れられるので、ビジネスの副産物として大量データをかんたんに入手できる。
そして、そのデータは個人を特定できるデータなので、データの質もいいはずだ。

【2】機械学習の最大の難問は、過学習への対応方法だろう。
モデルが訓練データで良い性能を発揮しても、未知のデータである汎用データに対し性能が悪ければ、過学習に陥ってしまう。
つまり、モデルが訓練データにFitしすぎて、訓練誤差は小さいが、汎化誤差は小さく収束しないことを意味する。

過学習への対策としては、次元削減や交差検証などがある。
交差検証は、訓練データと汎化データの品質を保つような仕組みが組み込まれていて、よく考えられているなと思う。

次元削減は、高次元空間ではデータはスパース(疎)になりやすいという次元の呪いを解決するために、色んなアルゴリズムが作られている。
次元削減によって、特徴量を自動計算できて、シンボルグラウンディング問題を解決させるわけだ。

この辺りを考えると、昔、ソシュール哲学の本を読んだ時に何を言っているのか分からなかった時を思い出す。
プラトンのイデア論を言い換えれば、本来の真理ないし実体と、それを表現する記号や言語があり、記号や言語の背後には特徴量というイデアがあると思える。

【3】ディープニューラルネットワークの考え方は面白い。
畳み込みニューラルネットワーク(CNN)は画像認識、再帰ニューラルネットワーク(RNN)は時系列データに強い。

CNNでは、画像の一部の要素に反応して、それらを次元削減してどんどん特徴量にまとめあげていく。
人がぼーっと夕焼けや景色を見ている時、そういうアルゴリズムで見ていると思うと、何となく腑に落ちる。

特に、RNNが自然言語処理に強い、という意見が興味深かった。
RNNでは、LSTMという長短期記憶の概念が出てくるが、これは、TOEIC勉強で習った「retain(保持)」の考え方に似ている。
日本人は英語を返り読みする悪い癖があるのは、長文の英文にある単語をretainすることができないからだ。
つまり、文章の単語の前後を短期記憶して、すぐに取り出して意味を見出す訓練が足りない。
RNNはその仕組みを実現しているから、自然言語処理に向いているのだろう。

【4】深層学習を含む機械学習がいくつかの従来の問題を解決してきた現在、今後、深層学習は人間の知能により近づき、いつかは追い越すかも知れない。
カーツワイルは技術的特異点が2045年と主張した。
確かに、コンピューティングパワーが進化すれば、単純な作業は全てAI化されるだろう。

しかし、大量の訓練データでFitしたモデルは、人間の知能を本当に超えるのか?
気になる点は、そういうモデルが意識を持つのか、という点だ。

直近のディープニューラルネットワークのブームは、先カンブリア紀の生物大爆発に例えられる。
つまり、生物が眼を発明したことで飛躍的に進化し、その原型は作られた。
しかし、生物が意識を持ち、自ら文明を作り出すまでに、さらに5億年以上の歳月が必要だった。
そこから類推すると、ディープニューラルネットワークに後もう一つの発見や発明が必要な気がする。

強化学習や敵対的生成ネットワーク等のように、AIやロボットが自ら進化していく仕組みは提案されている。
でも、まだ何か足りない気がする。
それを考えるのも楽しい。

| | コメント (0)

2020/06/11

DevOpsがアジャイル開発を促進する

今となっては古い2015年の記事を読んで、もう時代は変わったのだという認識をメモ。

クラウド専業SIerは従来のSIerとどこが違うのか? 夏サミ2015 - Publickey

社内サーバゼロ、フリーアドレス、メールをやめてSlack。クラウド専業SIerが模索するクラウド時代の働き方 夏サミ2015 - Publickey

クラウド専業SIerが語る、クラウド時代のエンジニアに必要な3つのスキル 夏サミ2015 - Publickey

技術のトレンドとしては、いかに作らずに、既にあるサービスやオープンソース、クラウドを組合せてローンチできるか。
プロジェクト管理のトレンドとしては、優秀な人員の調達能力やリソース配分能力よりも、クラウドの技術やサービスを知り尽くす技術者が少人数で速くローンチできるか。

AWSサービスも少しずつ勉強しているが、毎年数多くの新サービスがどんどん出てくるので、それらを組み合わせるとどんなメリットが出てくるのか、を研究していく必要がある。
枯れた技術を優先して流用して開発するスタイルはもう古い。

オープンソースとクラウドが当たり前の時代では、開発もインフラ構築も1人の開発者が対応できるし、よりアジャイルに開発できる。
技術がプロセスや組織をどんどん変化させていく。
昔に、こうあるべきだ、という理想のプロセスや組織論は、今はもう現実になっていて、いかにそれを使うか、さらなる未来はあるのか、という思考に向かっている。

| | コメント (0)

2020/06/09

なぜなぜ分析、FMEA、FTAの違い

なぜなぜ分析、FMEA、FTA、STAMPの違いをメモ。
間違っていたら後で直す。

「情報処理システム高信頼化教訓集(ITサービス編)」2017年度版公開:IPA 独立行政法人 情報処理推進機構

高信頼化教訓集

なぜなぜ分析は、発生した障害に対し、真因を導き出し、再発防止策を策定する。

FMEA(故障モード影響解析:(Failure Mode and Effect Analysis))は、潜在的な障害(リスク)に対し、製品及びプロセスが持つ潜在的なリスクを主にその設計段階で評価し、そのリスクを未然に排除する。

FTA(故障木解析(Fault Tree Analysis))は、障害(リスク)の発生確率を予測する為に、好ましくない事象(リスク)から原因を分解展開して、定量的に発生確率を把握する。

STAMPは、コンポーネントの信頼性の分析よりも、コンポーネント間の相互作用に着目して、信頼性や安全性を分析する手法。

最近の傾向としては、なぜなぜ分析、FMEA、FTAはかなり枯れた技法で、STAMPが脚光を浴びているイメージかな。
STAMPは、複数の部品を組み合わせた時の影響度合いやリスクを洗い出す手法として使われているイメージ。

| | コメント (0)

なぜなぜ分析と特性要因図の違い

なぜなぜ分析と特性要因図の違いをメモ。

【参考】
なぜなぜ分析と特性要因図 : CMMIを実践するエンジニアのブログ

10 分で理解できる特性要因図|書き方から原因を特定する方法まで

特性要因図は、事象の要因を複数個あげて、その要因を引き起こす要因へ詳細化していき、改善効果のある要因を原因として抽出する。
特性要因図は、原因分析ではなく要因分析である。
特性要因図の目的は、問題(特性)を引き起こしていると推測される要因を洗い出し、最も効果のある要因を原因として見つけ出すこと。

なぜなぜ分析は、事象に対し、事実と原因をセットにして、因果関係で掘り下げる。
なぜなぜ分析は、「事実」に基づきながら問題の原因を掘り下げていく。
なぜなぜ分析の目的は、ある事実に対する原因を発見すること。

この違いが明確ならば、特性要因図で要因を推測しながら洗い出し、原因を洗い出したら、なぜなぜ分析で因果関係にまとめる、というやり方もある、と考えた。


| | コメント (0)

AzureクラウドデザインパターンとAWSクラウドデザインパターンのリンク

AzureクラウドデザインパターンとAWSクラウドデザインパターンのリンクがあったのでメモ。

【参考】
AWS-CloudDesignPattern

Azure-CloudDesignPattern

デザイン パターンから見た AWS と Azure | Microsoft Virtual Academy ? 専門家が提供する e ラーニング コース ? | Channel 9

クラウドごとの違いはどこにあるのか?
AWSとAzureは、本質的にどこが違うのか? どこに気をつければいいのか?
AWSは細かい部分までエンジニアがパラメータを微調整する必要があるイメージだが、Azureはどうなのか?


| | コメント (0)

JRubyの終焉

一時期流行したJRubyについて、JRuby on Rails は難しい、という記事を見つけた。
ラフなメモ。

【参考】
JRuby on Rails は無理かもしれんね、という話|Seahal

Redmine on JRuby: プログラマの思索

Redmine on JRuby part2: プログラマの思索

Redmine on JRuby part3~RedmineはJRuby+Tomcatで動かす方が簡単: プログラマの思索

JRubyでRedmineBacklogsプラグインを動かす: プログラマの思索

(引用開始)
かつて JVM のメリットとされた ‘Write once, run anywhere’ というメリットも Vagrant や Docker といった仮想環境や、Go言語のように多種の環境に対応したバイナリを吐き出せるコンパイラが出てきた今、それほど JRuby に対するメリットを感じるのが難しくなってきたような気がする。
(引用終了)

Redmineでも、Ver4からJRubyが外されたので、何かあったのかな、と思っていた。
10年前は、Railsのwarファイルが作れるし、JavaのWebサーバーも使えるぞ、と思っていたが、今となってはCRubyも十分高速化されてきたし、DockerやAnsibleなどで仮想環境を構築するのも簡単になった。
Windowsでも、WSLを入れれば、Ubunts上でRuby環境を作った方が安全だ。

こういう状況を振り返ると、OSSのライブラリや言語は時代の流行り廃りはどうしても発生することを痛感する。
10年前は、JavaからRubyへ、というキャッチコピーが流行り、ドメイン特化言語に適したRubyが非常に脚光を浴びていた。
今は、機械学習や深層学習、データ分析にスポットが当たっているので、PythonとRが注目されている。
昨年、大学の生協の本屋に行ってみたら、プログラミングコーナーにはPythonとRでほとんどが占められていて、他言語は申し訳無さそうに少しだけ飾られていたのが驚きだった。


| | コメント (0)

2020/06/06

気象庁の事例「GitとRedmineを用いた気象研究所共用海洋モデル「MRI.COM」の開発管理」の論文を読み解く

気象庁の事例「GitとRedmineを用いた気象研究所共用海洋モデル「MRI.COM」の開発管理」の論文が公開されていたのでメモ。

【参考】
海の研究~GitとRedmineを用いた気象研究所共用海洋モデル「MRI.COM」の開発管理

(PDF) GitとRedmineを用いた気象研究所共用海洋モデル「MRI.COM」の開発管理

気象庁の数値予報課におけるRedmine利用事例: プログラマの思索

第18回Redmine大阪の見所~「チケット管理システムによるソフトウェア開発支援と今後の課題~気象庁のRedmine利用事例報告」: プログラマの思索

第18回Redmine大阪の感想 #RedmineOsaka: プログラマの思索

2017年にRedmineコミュニティで、気象庁の方に利用事例を聞いた時があった。
その後の論文なので、どんな内容が追加されたのか、気になった。

(引用開始)
著者らの海洋大循環モデル「気象研究所共用海洋モデル(MRI.COM)」は,開発が始まってから20 年近くが経過し,気象研究所と気象庁の様々な部門で利用されるようになるとともに,ソースコードの大規模化・複雑化が進んだ。
このような状況の下でも,バグの混入や意図しない影響を抑えながらモデルを効率的に開発するため,現代的なソフトウェア開発で用いられるツールと手法を取り入れ,開発管理体制を一新した。
まず,ソースコードの開発履歴(バージョン)を管理する「Git(ギット)」を導入した。このツールにより,複数の開発者が複数の課題に同時に取り組む並行開発が可能になった。
また,プロジェクト管理システム「Redmine(レッドマイン)」を導入し,開発状況を開発者全員で共有した。このシステムによってデータベースに逐一記録された開発過程が,他の開発者や次世代の開発者にとって財産となることが期待される。
これらのツールを用い,さらに開発手順を明確にすることで,開発チーム内の情報共有と相互チェックを日常的に行う開発体制に移行することが可能となったことは,コード品質の向上に大きく寄与している。
現在,気象庁では,MRI.COMだけでなく,気象研究所と気象庁で開発しているほぼ全てのモデルをGit(またはSVN)とRedmineで一元的に管理するシステムを構築しており,モデルの開発管理及び共有化が大きく前進している。
(引用終了)

論文の中では、Redmineのチケットの画面キャプチャ、GitのコードラインとRedmineのバージョンの関係の図が多数あり、イメージしやすい。
基本的には、開発のタスク管理、ソースコードのレビューにチケットが使われている。
そのワークフローと、チケットの進捗率はP.184で対応付けられている。

(引用開始)
具体的なメリットを以下に挙げる。
1)他人に見られることを前提にしてタスク内容を明文化することで,開発方針が明確になる。
2)担当者や期日が明示されることで,各タスクの優先度の誤認などを防ぐ。
3)実装方針など開発に関する議論が残されることで,他の開発者と将来の開発者はコード変更についての理解が容易になる。開発過程のデータベース化は,次世代の開発者にとって大きな財産となる。
4)開発内容とソースコードが関連付けられ,どのような目的で,どのようにコードが変更されたかを誰もが見えるようになる。これにより,モデル利用者に対して,なぜそのような変更を行ったのかを説明する責任を果たすことになる。これは,現業使用や外部提供もされる MRI.COM にとって重要である。
5)Redmine でチケットを一覧表示させることで,モデル開発の全体の進捗を共有できる
(引用終了)

2014年からRedmine、Git、Subversionが導入されて、数年以上の運用を経ているので、開発プロセスは標準化され、開発者にも浸透しているのだろうと思う。
コードレビューがチケットのやり取りになるので、誰が担当しているのか、説明責任が明確になり、タスクの消化が駆動される。
また、レビューや作業の結果はチケットに全て残るので、保守フェーズでも参考になる。
そういうメリットは感じられているようだ。

(引用開始)
これによるメリットは多々あるが,とりわけ,複数の開発者による並行開発の円滑化,開発過程のデータベース化,ある変更を本体に取り込む前に他の開発者がチェックする「コードレビュー」の必須化,安定版と開発版の 2 系統維持,テスト自動化は,モデル開発において有益である。
また,開発手順の標準化は,他部署や他機関の人が行ったバグ修正や開発も通常の手順で幹のソースコードに取り込む体制が確立されたことを意味する。
(引用終了)

但し、課題も感じられている。
どうやら、RedmineもGitのソースも気象庁内だけに限られているので、外部の人達と情報共有しにくい点があるらしい。
本来は、Githubで公開して、日本や世界中の学者や開発者と連携したり、共同開発できるのが望ましい。
しかし、気象庁内のサーバーで管理されていること、ソースコードの著作権の制約があること、などの理由により、なかなか進んでいないみたい。

こういう話を聞くと、Redmineは社内で閉じた空間では非常に便利なツールではあるが、社外のベンダーや開発者と共同作業する場合、セキュリティ面や著作権などの壁という課題が出てくるのだろう。
今までの日本では、大企業や官公庁は自前のオンプレのサーバーで管理できていたが、今後はクラウド上で外部の関係者と共有できる開発基盤が必要になってくる。
その時に、自前で立てたRedmineサーバーよりも、SaaSのタスク管理ツールやGithubの方が、手間のかかる運用保守から離れられる、というメリットもある。
この辺りは、Redmineの機能が足りない、というのではなく、Redmineのようなチケット管理ツールをSaaSとしてどのように展開すべきか、という問題へ変換できるのだろう。

時代の進化と共に、現場が抱える問題点は日々変化していくものだから。


| | コメント (0)

RedmineでGitHubをらSVNプロトコルで使う

りょうまさんから、RedmineでGitHubをらSVNプロトコルで使えるよ、と聞いたのでメモ。
下記の記事にもあった。

GitHub EnterpriseのリポジトリをSVNプロトコルでRedmineから直に参照....。

(引用開始)
GitHubならSVNプロトコルが使えるよ
(引用終了)

今は時間がないので後で試してみる。
これが可能ならば、GithubリポジトリとRedmineの連携は非常にスムーズになる。
Redmineの最大の弱点はGit連携が不十分という点なので、この方法でどこまで解決できるか試してみる。


| | コメント (0)

2020/06/05

Redmineはまだ死んでいないよ

「Redmine is Dead」という記事を見つけたのでメモ。

【参考】
Redmine is Dead - taikii blog

Redmineのエモい話 - taikii blog

Redmineはまだまだ知名度は低いと思うのに、「Redmine is Dead」みたいな記事があって驚いた。

僕は、Redmineは発展途上だと思っている。
テレワークが注目されている状況なのに、まだメールとExcelが幅を利かせている現場は多すぎるから。

Redmineの面白さは、自分たちで開発プロセスや業務をツールで改善できる点。
技術力さえあれば、ツールを使いこなしながら、マネジメントの経験を積める点。
この辺りをもっと深堀りしたい。

| | コメント (0)

« 2020年5月 | トップページ | 2020年7月 »