2018/05/08

論文のお作法は、さかばさんから真似る

さかばさんのブログにある論文のお作法の記事がとても良くて、いつも参考にするのでリンクしておく。
以下、ラフなメモ書き。

【参考】
社会人のためのシンポジウム発表入門 リーン論文作法: ソフトウェアさかば

論文の善し悪しをサンプルで見る: ソフトウェアさかば

できる人を観察して勝負する: ソフトウェアさかば

さかば流・論文作法 その1 - 論文の構成 -: ソフトウェアさかば

さかば流・論文作法 その2 - 論文を書く上での注意点 -: ソフトウェアさかば

さかば流・論文作法 その3 - 良い技術 -: ソフトウェアさかば

【1】僕も論文を書くのは嫌いだったかな。
学生の頃、先生からいつもたくさんの指摘を受けて直すのに、OKの返事がもらえなくて苦労した。

今思い出すと、その理由は、論文特有の書き方を知らなかったから、だけでなく、経験した現実とあるべき理想の対立を自分の心の中で強く持っていなかったから、とも思う。
僕は世間にこういうことを主張したい、という熱い気持ちで書き出して、その内容を数多くの人に叩かれたり議論したりして、アイデアを鍛えて、内容をブラッシュアップしていく、という過程を、その頃は経験できていなかったから、とも思う。
ずいぶん自分のレベルが低かったと思う。

まず言いたい主張が先にある。
そこから、その主張がどんな問題を解決するのか、何が課題として今後の研究テーマになるのか、などの骨組みが決まっていく。

【2】さかばさんの下記のツイートが好き。

【2-1】
さかばさんのツイート: できる人は、頭の中で知識の構造を常にリファクタリングしている。凡人は、整理しないままで置いておくから活用できない。大学院で学んだ事の一つです。

僕はSEA関西の知的サロンのような雰囲気が好きなのだが、そこでは、アジャイル開発とか新しい技術とか議論していると、必ず定義を聞かれることがあった。
互いの議論によって、自分が持っている知識体系、理解している知識ツリーに入れば理解できたことになる。
その作業が、知識構造のリファクタリングにつながる。
世話人の方は、たぶんそういう作業を常にされているのだろう。

僕自身の経験でも、いつもポンチ絵を描いている。
モヤモヤしたアイデアを明確にするために絵を描く。
新しい知識を色んな観点で比較評価するために絵を描く。
絵を何度もリファクタリングして描き直すうちに、あるべきイメージが固まっていく。

【2-2】
さかばさんのツイート: @tunemage まずは論文で主張したい点を3つにまとめて、それを裏返して問題設定すると論文の概要ができます。それを端的に表現すればタイトル。用語を説明すれば背景になります。各段落を一行で表した箇条書きを作ってから書き出すと綺麗な構造になりますよ。

普通は、自分が言いたい主張が必ず先に存在する。
その主張から問題点を明確にして、主張を正当化する必要がある。
その作業は、「Justify」と呼ばれている。
数学ならwell-definedに相当するだろうか。

論文作成の技法part2~論文作成の観点 : プログラマの思索

Well-defined - Wikipedia

このJustifyの作業を「主張の裏返し」という言葉でさかばさんが表現されているのは凄いなあ、と思う。
自分の経験を振り返れば、主張と問題点に線を引いて因果になっているか、トレースできているか、自分でチェックしていたけれど、その作業と同じだったわけか。

問題を明確にするというJustifyの作業が重要な理由は、問題となる前提条件、スコープが明確にされなければ、主張したいアイデアが何を解決するのか、一方、現在の主張では解決できないので何が課題として残るのか、というストーリーを説明できなくなるからだ。

自分の主張で、全ての問題が解決するわけではない。
普通は解決できた部分はごく一部だけ。

でも、その主張のアイデアが優れていれば、未開拓の分野にどんどん適用されて、関連研究が広がる。
たとえば、科学者の論文でも、すごく偉い科学者が理論を打ち立てたら、その後続の凡庸な科学者は、その理論を使って細かい問題をしらみ潰しに論文を量産していく、というパターンが多い。
そういう凡庸な論文が多いので、それを関連研究として整理するのもまた一苦労、みたいな感じかな。

【3】論文作成のお作法であるロジックの組み立て方は過去にまとめていた。

論文作成の技法part1~論文の構造: プログラマの思索

【4】さかばさんの「リーン論文作法」の発表資料には、そういうノウハウが濃縮されている。
なので、さかばさんの「リーン論文作法」の発表資料はお勧めです。
ダウンロードできるので、印刷したり、スマホに常に持っておき、いつでも参照すると便利です。

| | コメント (0)

2018/05/06

Excelの表をMarkdown形式に変換するExcelアドオン、Webサービスのリンク

最近、Markdownで資料を書いて、WordやPDF、epubに変換したり、RedmineやConpass等に書く場合が多い。
しかし、いつも表形式が書きにくい。
そこで、Excelの表をMarkdown形式に変換するExcelアドオン、Webサービスをリンクしておく。

【参考1】
選択したExcelのセルをMarkdown形式でコピーするExcelアドインをリリースしました。 - nuits.jp blog

nuitsjp/CopyToMarkdownAddIn: Add-In for copying from Excel to Markdown

Excelのアドオン。
Excel上で右クリックした後、テキストに貼り付けるだけ。
こちらを愛用してる。

【参考2】
Excelの表をMarkdown形式に変換 - Qiita

Markdown Tables generator - TablesGenerator.com

Excel上でコピーして貼り付けるだけ。

【参考3】
Markdown で書いた試験仕様書を Excel に変換するツールを作った

Markdownのテスト仕様書からExcelに変換するツールを作られたらしい。

似たような例として、FreeMindのマインドマップからテストケースを自動生成するツールもあったな。
因子の組合せによるテストケース生成は、ツールを使った方が簡単。

FreeMindからテストケースを自動生成するテストツールFMPictをリリース - 千里霧中

fmpict/manual.md at master ・ hiro-iseri/fmpict

こんな本もあった。

『マインドマップから始めるソフトウェアテスト』を読んでマインドマップを書こう! - そこに仁義はあるのか(仮)

| | コメント (0)

2018/04/28

第62回IT勉強宴会のメモ~2人の方法論者によるデータモデリング激レア対談

昨夜の関西IT宴会「2人の方法論者によるデータモデリング激レア対談」が開催された。
自分が後で読み直すために、殴り書きのメモ。
自分の感想も入れておく。
DOA屋さんから見れば、理解してないな、と思われるかもしれないが、気にせずに公開しておく。

2人の方法論者によるデータモデリング激レア対談 - connpass

2人の方法論者によるデータモデリング激レア対談<第62回IT勉強宴会in新大阪> | IT勉強宴会blog

【1】By 佐野さん
オブジェクト指向は、ゲームや組込みシステムには向いているだろう。
しかし、業務システムのように、帳簿組織を起源に持つシステムには、オブジェクト指向は向かない。
帳簿組織の業務はデータモデリングすべき。

【2】By 佐藤さん
昔はT字形ERだったが、今はTMと呼んでいる。
中身は別物。
(注:その意味は、後述)
(注:僕はT字形ERの本しか持っていないので、以後は、T字形ERと書く)

TM手法はOOAみたい、と言われる。
理由は、astahで描けるから。

注:たぶん、下記の記事のことかな?
「データモデリング入門-astah*を使って、TMの手法を使う-」はとても良いモデリング資料: プログラマの思索

T字形ERの対照表は、OOAの関連クラスと同じ。

【3】By 渡辺さん
AS400の頃に、RDBを本格的に触り始めた。
私は理系なので、「テーブルA:カラムa, b, c・・・」とモデルを書いていたが、周りのSEが全く理解してもらえない。
しかし、具体的にモデルを書くと、SEも理解してくれる。
仕方なく(?)、今の渡辺式ER図のようなデータモデルを書いている。

その頃に流行した4CLでモデルのテンプレートを作り、システムを自動生成するような仕組みを作っていた。
そして、自分で、Delphiでモデルのテンプレートを作り、システムを自動生成するようなモデリング支援ツールを自作していた。
それが、今の三要素分析手法のきっかけ。

感想:
DOA屋さんがOOA屋さんと同じくモデル駆動開発に行き着くのは、モデリング支援ツールを作りたかったという動機があるんだろうな、とふと思った。

【4】By 佐藤さん

Coddの論文を元に、商用ベンダーは商用RDBMSを実装した。
しかし、実際にRDBをそのまま使うとパフォーマンスが出ない。
DBMSには、性能が悪化しないように工夫している。
だから、DBMSの仕組みを理解しないと、パフォーマンスが出ない。

T字形ERは、Coddの弱点に気づいて理論として構築した。
でも、まだ欠陥が残っていた。
TM手法を構築して、佐藤さんの中では完全に解決した。

【5】By 佐野さん

OOAを毛嫌いする理由は、関数従属性を前提にしないこと。
モデルでは、単なる関連で書いている。

【6】By 渡辺さん

三要素分析法は、ER図、DFD、アクションツリーから成る。
データの形はER図、仕事の連携はDFDやアクションツリーで表現される。

データの形が決まれば、画面UIはほぼ確定してしまう。
また、データの形が決まれば、バッチ処理も決まってしまう。
仕事の連携が決まれば、システムの機能(仕様)も決まる。

そういう発想から、三要素分析法は生まれた。

XEAD Tools and Resources - 設計方法論 三要素分析法(TEA Method)

【7】By 佐藤さん

インデックス設計でアクセスパスが自然に決まる。
T字形ERでは、アクセスパスは自然に実装される。

なぜモデルは普及しないのか?という質問に対し、
モデルはあって当然。
それをユーザの環境に合わせて、どのように導入するか?をモデラーは考えるべき。

【8】By 渡辺さん

経理マンの専門知識をデータモデルで表現すると、システムの知識を知らない経理マンも、そのデータモデルを理解できる、という経験をした。
そして、経理マンは勝手に自分達でモデルを描き始める。
そういう経験を経て、モデルの重要性を感じている。

注:懇親会で佐藤さんに、T字形ERでは、顧客のビジネスをデータモデルで表現した時、イベントとリソースのテーブルの個数を数えて比較する。
その時、イベントの個数がリソースの個数よりも少なければ、顧客の潜在的なビジネスモデルを構築できる可能性がある、という話を読んで、すごく納得した、と僕は話した。
つまり、イベントとリソースの組合せで新たなイベントを作り出せる可能性があること、それは顧客の新たなビジネスモデルを構築することにつながることと同じ。

すると、佐藤さんから、ああ、その話では続きがあって、そのデータモデルを顧客に見せたら、顧客自身が自分達でビジネスモデルを作り始めたんだよ、と言われた。
その話と同じかな。

リソース数がビジネスの可能性に関係する理由: プログラマの思索

候補キーと2次識別子に関する概念: プログラマの思索

【9】By 佐野さん

情報系の大学の学生は、学校でデータモデルを習わない。
UMLは習うのに。
彼らも、Postgresは知っているし、使える。
でも、中身のテーブルは全てサロゲートキーになっている。
関数従属性を気にしていない。
そもそも関数従属性を考える、という行為すらしていない。
テーブルは単にデータを格納するだけ、にすぎない。

【10】By 佐藤さん

元々RADを目指していた。
T字形ERで設計すると、当時100万ステップのプログラムのうち、7割は不要になる。

でも、いつも背中から撃たれた。
同業者から嫌われる。

たとえば、大手SIのSEから、T字形ERみたいなこんなに正規化しすぎるとパフォーマンスが悪くなりますよ。
だから、パフォーマンス向上のために、あえて非正規化を施し、森羅万象テーブルみたいに1個のテーブルに300個以上のカラムを設計する、みたいなデータモデルを作ってくる。

「大規模集積回路モデル」と「板チョコモデル」: 設計者の発言

SIでは、生産性を上げたくない。
人月商売なので、開発者の人数が減ると売上が減ってしまうから。
SIは、高価格で、バグ込みのソフトウェアを納品しているんですよ、と。

【11】By 佐野さん

T字形ERはモノありき、のように感じている。
(注:たぶん、業務システムのリプレース案件では、DOAが最強だからだろう、と思った)

他のDOAの流派でも、AsIsベースが多い。
例えば、請求書をデータモデルにする、とか。

渡辺式DOAの凄い所は、いきなりToBeを描く所。
何もない所から作る。

注:懇親会で佐藤さんから、T字形ERは他のDOAと違う。
他のDOAの流派は具体論ばかり話す。
T字形ERは理論から始める。
だから、数学基礎論から勉強し直した、と言われたのが印象に残った。

Oracleを初めて触り始めた頃、OracleでSQLを書くと、テーブルをJoinした時、小さなテーブルを先に読むとパフォーマンスが遅くなる。
Oracleの中身を知らないと、なぜSQLのパフォーマンスが悪化するのか分からない。

真因は、DB設計できていないから、SQLのパフォーマンスが出ないことにある。
だから、SQLは重視しない。
むしろ、真の問題はデータモデリングにある。

X-TEA Driverの面白い所は、複数のDBも扱える。
例えば、マスタはOracle、トランザクションはPostgres、とかでもOK。
しかも、複数のDBのテーブルもJoinできる。

また、データモデルと業務の整合性も事前にチェックしてくれる。

【12】By 佐藤さん

SQLを何も考えずに書くのは信じられない。

モデルはアトリビュート、インデックス定義が含まれる。
実は、アルゴリズム指示書もある。

その中身は、Input=モデル、Process=アルゴリズム、Output=インデックスのような詳細設計書。
すると、アルゴリズムの部分は、ほとんどプログラム自動生成に近い。
プログラマは不要で、コーダーさんに近い。
SIは不要だね。

【13】By 佐野さん

ORマッパーが普及したので、SQLを書けない人も多い。

一方、SQLマッパーというモノもある。
SQLで書いたモノがオブジェクトになる。
たとえば、下地さんのRMenuではjson形式でSQLを表現でき、そのままパースできるので便利。

注:懇親会で下地さんに聞いたら、RMenuで業務システムを実装したら、最初はあえてインデックスを貼らない。
システムの運用後、データが蓄積されて、遅くなった、と言われたら、該当の画面からjson形式のSQLを抽出し、それをパースしてインデックスを生成して、組み込んでいる。
jsonだからすごく使い勝手がいいよ、と。

【14】By 下地さん

プログラムは使い捨てであるべきだ。
なぜなら、プログラムは資産ではない。
その時限りの費用で計上すべきものだ。

注:その意図は、データモデリングを極めると、テーブル設計さえ確定すれば画面UIはほぼ確定されてしまうので、プログラムはほとんど自動生成できてしまう。
つまり、プログラムで書くべき部分はすごく少なくなる。
すると、プログラムは資産というよりも、データモデルに付随したモノに過ぎない、という考え。

佐藤正美さんも、ソフトウェアを資産と考える考え方は嫌いだ、と言っていた。

但し、会計の理論上では、ソフトウェアは無形固定資産に含まれる。
だから、業務システムは保守フェーズで減価償却費が発生するし、システムの改善は、価値が目減りした資産を増やす行為になるので、会計処理も複雑になるデメリットもある。

注:
アジャイル開発では、ソフトウェア(=プログラム)は、最初は負債であり(なぜなら何もないところに投資するから)、その後、キャッシュを生み出して売上を上げていき、損益分岐点を超えたら初めて黒字になるイメージだ。
そういうアジャイル開発の考え方と整合性は取れるか?

プロエンジニアになるための「アジャイル開発」再入門

「プロエンジニアになるための「アジャイル開発」再入門」が素晴らしい: プログラマの思索

| | コメント (0)

技術革新とエンジニアのキャリア形成にオープンソースコミュニティの存在が重要性を増している

Publickey主宰者のインタビュー記事を読んで、気付いたことをメモ。
ラフなメモ書き。

【参考】
Publickey主宰者・新野淳一氏に聞く、エンジニアのキャリア・スキルの磨き方、「稼ぐ力」の付け方 - GeekOut

【1】Publickey主宰者のインタビュー記事を読んで、印象に残った点は2つある。
一つは、クラウドとオープンソースにより技術革新の場がベンダからオープンソースのコミュニティへ移ったこと。
もう一つは、エンジニアのキャリア形成に、オープンソース活動やコミュニティ活動による貢献が重要性を増していること。

【2】現在では、技術革新の場はベンダーから発信されるよりも、オープンソースのコミュニティを中心に発信させる場合の方が多い。
たぶん、その事実もかなり知られている。

(引用開始)
取材するスタイルも昔とはずいぶん変わりました。かつてはベンダが一番情報を持っていたので、発表会に出席して、新製品や技術のことを取材していましたが、いまのメインストリームは明らかにコミュニティです。僕もオープンソースのコミュニティの情報や、フォローしているオープンソースエンジニアのTwitterを見て、業界動向をウォッチしています。
(引用終了)

上記の記事のように、一昔前は、IBMやMSなどの大企業の技術動向をウォッチするために、大企業のイベントに出向いて、情報収集するのが普通だった。
でも、今では、LinuxやRuby、Python、Wordpress、LibreOfficeなど数多くのオープンソースが市場を支配して影響を与えている。
これらオープンソースコミュニティに出向いて、優れたコミッタやそのリーダーをウォッチしたり、直接話したりする方が、情報収集が速い。

この変化によって、大企業よりも、優れた中小ベンチャーやコミッタの方がIT業界において、政治的影響力を増している、という事実が挙げられるだろう。
たとえば、UberやAirbnbなどのシェアリングサービスも一気に普及し、昨今のAIブームに乗って大きく成長している。

つまり、オープンソースを中心としたコミュニティが技術革新と新しいビジネスの創出を生み出している。
その変化にエンジニアも付いていかないといけない。

【3】すると、エンジニアのキャリア形成に、オープンソース活動が大きな影響を与えてきている。

【3-1】エンジニアがスキルを向上させるために、オープンソース活動に積極的に関わり、貢献することで、周囲に彼のスキルを認めてもらい、彼自身の価値を上げていく、という成長のらせん構造が生まれている。

(引用開始)
 そうすると、エンジニアの働き方やキャリアも変わります。それまでは、最新技術はほとんどベンダに集まっており、ベンダの技術に詳しい人が求められてきました。しかし、オープンソースという新しい価値観が生まれることで、コミュニティへの貢献がキャリアに好影響を及ぼし、スキルアップにつながるようになりました。そういう新たなエンジニアのヒーロー像が生まれたのです。

 あとは、やっぱりクラウドですね。クラウドの最大の特徴は、一言では表現できないジャンルの広さです。その分、クラウドを活用することは非常に難しくなっている。社内で学べる範囲を超えているんですね。あらゆるレイヤーに精通する必要がありますし、オープンソースやベンダの技術も追っていかなければなりません。技術だけではなく、仕事や業務についても勉強する必要があります。そういう包括的な知識は、単に仕事をこなすだけではなかなか学べないのです。会社の枠を超えて物事を学ぶ姿勢を保ち続けないと、クラウドをキャッチアップできないと思います。

 クラウドとオープンソースが出てきたおかげで、会社の中でキャリアを考える時代から、会社を超えて自分のスキルやキャリアを考える時代へと変化しました。そうでないと、エンジニアは自分のキャリア人生を生き抜けなくなってきています。Linuxが出てきた頃からそういう雰囲気はありましたが、クラウドの登場で、その傾向が一段と鮮明になってきた。僕はそう思っています。
(引用終了)

【3-2】似たような話として、下記の記事もあった。

会津大学で「これからのエンジニア像」についてお話してきました - インフラエンジニアway - Powered by HEARTBEATS

(引用開始)
これからのエンジニア像

この先とか言ってるけど、未来人じゃないから先に事はわからないよ
・なので歴史を踏まえて推測するね

ここ20年を振り返ると、ITは10年でスキルの価値がなくなる業界です
・最先端の貴重なスキル =(10年)=> ふつうのスキル =(10年)=> こどもでもできる

世間的なエンジニアの評価軸が技術領域ベースから価値ベースにシフトしてきたよ
・ネットワークエンジニア => Webサービスエンジニア...

みなさんはきっと75歳くらいまでは働く必要があります
・たぶん私もね

ホワイトカラーは一生勉強し続ける必要があります
・宿命ってやつですね

いまのうちにじっくり基礎から勉強の仕方・活かし方を身に着けておくとよいですよ
・基礎知識と、学びの習慣化をしておこう

とにかくまず学校の勉強をきちんと真面目にやるのが最高
(引用終了)

IT業界にいて、つくづく思うのは、身につけた技術は10年経つと陳腐化してしまい、無意味になってしまう可能性が高い事実だろう。
実際、Cobolやメインフレームでバリバリ、プログラミングして経験を積んで、部課長に成り上がった人達を見ると、彼らの話が既に時代に合わなくなっていることをいつも感じる。
そして、彼らの経験やノウハウが陳腐化されるのと同様に、自分もそうならないか、といつも自問している。

アジャイル開発は常識だ: プログラマの思索

ライフ・シフト」のように、人生100年時代の中で、現代を生きる人は皆、死ぬ直前まで働くことを前提に、一生勉強し続けることを準備しなくてはならないのだろう。

たとえば、昨今は、いわゆる文系の士業は人工知能で代替されるニュースが相次いでいるので、士業の受験者数がかなり減少していて、危機感を持つ人が増えている、という話も聞いた。
いわゆる士業のAI受難だ。
よって、士業だけでなく、普通のホワイトカラーも、価値を生み出さないエンジニアもAIで代替されてしまうリスクがあるのだろう。

AIによる代替可能性90%以上の士業は3つの士業 | 株式会社ネクストフェイズ

では、技術や知識を得たとしてもすぐに陳腐化してしまう時代において、どんな方針で働くべきなのか?

現状では、社内研修やOJTだけでは、エンジニアのキャリア形成は不十分だ。
むしろ、エンジニア自身が積極的に、オープンソース活動に加わった方がいい。

現代では、オープンソースコミュティが技術革新の発信源であるからだ。
だからこそ、オープンソース活動に加われば、自身より優れた開発者と交流することで、やる気も出るし、自身の能力向上にも役立つ。

自分にも銘じておく。

| | コメント (0)

2018/04/25

Redmineの直近の課題~競合ツールGitlabに対抗できるか

2018年4月現在、Redmineの今後の課題について考えてみる。
以下はラフなメモ書き。

【1】Redmine大阪や東京Redmine勉強会にスタッフとして活動してきた中、参加者も大幅に増えて、参加者層も初心者から経験者まで広がり、業種もIT業界だけでなく特に製造業にも広がっている印象を持っている。

たぶん、RedmineはRailsアプリ、そしてチケット管理ツールの中で、日本で最も普及したアプリの一つだろう、と思う。

しかし、技術革新の流れが早い中、Redmineにも課題がチラホラ見えてきたように思う。
僕は、Redmineの直近の課題は、Redmineのシングルページアプリケーション化、Redmineのコンテナ化、Git連携の強化だろうと思う。

【2】1つ目は、RedmineのUIが古臭いと言われる問題意識だ。
たとえば、スマホに慣れていると、Redmineのように画面更新のたびにリフレッシュされる仕組みは正直手間がかかるイメージだ。
一つの画面内で、必要な箇所だけ更新するだけで、画面全体がリフレッシュされる必要はないはず。
その分、処理速度も早くなるし、ユーザの利便性も上がる。
つまり、昨今のUIで主流のシングルページアプリケーションのような仕組みをRedmineにも導入していくべきだろう。

以前、RailsはJavascriptと相性が良いので画面UIもリッチで使いやすかった。
しかし、Railsフロントエンド技術も、昨今の時代の流れの影響を受けて、どんどん進化している。

Railsフロントエンド技術の今とこれから - Hack Your Design!

rails × AngularJSでシングルページアプリケーションを作るTips - Qiita

Rails5.1に向けてフロントエンド周りで起こっている革命まとめ - Qiita

一方、競合の状況を見ると、有償のチケット管理ツールであるJiraやBacklogに比較されやすい。
それらツールは、昨今の時流に合わせてUIフレンドリーな画面になっている。
もちろん、OSSのRedmineに対し、営利目的の会社が多数の開発者というリソースを持つ競合の方が恵まれている点は否めない。

【2】2つ目は、Redmineのインストールやバージョンアップが難しいと言われる点だ。
初心者にとって、RubyやGemをインストールする時、バージョン違いによって、ハマってしまう場合が多い。
Redmineを使いたいだけなのに、セットアップに手間取ってしまって断念するケースも多いのではないか。

Redmine 3.4をCentOS 7.3にインストールする手順 | Redmine.JP Blog

この点に関しては、最近、Gitlabにも注目している。
特に、Gitlabでは、バックアップやコンテナ化など技術的にも優れている点が見えてくる。

たとえば、バックアップやリストアはrakeタスクで用意されているので、Cron化しておけば、保守で気にする必要はない。

Rake tasks | GitLab

また、GitlabCIまでセットアップすれば、Redmine+Jenkinsよりも使いやすい点はあるだろう。
インストール対象が2つのツール(RedmineとJenkins)よりも1個のツール(GitlabCI)の方が楽だから。

Gitlab + Gitlab CI をためす - LGTM

個人的には、RedmineのバージョンアップをiOSの自動更新みたいに、もっと手軽にすべきだろう、と思う。
現状でも、プラグインをGem化するアイデア、RedmineをDockerでコンテナ化する、等が色々試されている。

Feature #27705: Gemify redmine plugins - Redmine

これらアイデアをさらに発展させて、Redmineのバージョンアップの自動更新がワンクリックで可能になるように、改善されるべきだろう。
たぶん、Dockerのようなコンテナ化に解決の鍵があると感じている。

なぜなら、ちょうど今はコンテナ化や仮想化のように、インフラ基盤をプログラム化する技術が一番ホットな話題であること、それら技術がクラウドと相性がすごく良い事もあるからだ。

【追記】
RedmineのDockerは下記でインストールできる。
Windowsでも問題なくインストールできるのはすごく良い。

Redmineインストール from Docker Hub - Qiita

【3】3つ目は、RedmineはGit連携の機能が弱い点は、従来からずっと知られていた。

一方、Gitlabのチケット管理もRedmineより弱いとは言え、着実に改善されている。
一般に、SVNよりもGitを使うのが普通なので、この点に関してRedmineは多少不利な面がある。
いつか、Redmineの競合候補になってくるのではないか。

RedmineとGitLabを連携すると、RedmineをGitHub化できるか: プログラマの思索

RedmineとGitを巡る疑問点~Gitとの連携機能の強化がRedmineの課題: プログラマの思索

【4】個人的には、Redmineの競合ツールは有償ツールであるJiraやBacklogではなく、OSSのGitlabになるのではないか、と思っている。

理由は、ポジショニングマップで書くと、RedmineとGitlabはちょうど正反対の位置に配置されるからだ。
実際、「Git連携が強い・弱い」軸と「チケット管理機能が強い・弱い」軸の2次元でプロットしてみれば、「Git連携が強く、チケット機能が弱い」GitLabと、「Git連携が弱く、チケット機能が強い」Redmineで斜め方向にプロットできる。

よって、RedmineとGitlabは全く正反対の性質を持つツールなので、現在は双方を連携することで相互補完する方向に進化している。
すなわち、Redmineでチケット管理して、Git管理やプルリクエストはGitlabで行い、WebhookによりチケットとGitを連携できるようにする運用スタイルだ。

GitLabとRedmineを連携してみるの巻 - アルパカDiary Pro

GitlabとRedmineを連携させる方法の覚書。 - Qiita

でも、RedmineもGitlabもGit管理やチケット管理の機能を強化していく方向へ進化するならば、競合することになるだろう。

なお、Gitlabには、GithubクローンとしてOSS版とエンタープライズ版が提供されている。
ビジネスモデルとしても、うまいやり方だと思う。
なぜなら、OSSで提供することにより、ユーザ数を増やせること、また、ユーザのフィードバックを受けて有償ツールに反映してどんどん機能拡張できること、があるからだ。

GitlabもRedmineと同じくRails基盤なので、改修しやすいし、機能改善の進化も速いので、近い将来、現在のRedmineの優位性は変化していくかもしれない。

たとえば、Gitlabが強力なチケット管理機能を実装したら、プログラマ層は皆、RedmineよりもGitlabに流れてしまい、Redmineのユーザ数は減ってしまうだろう。

現在は、たまたま、日本のRedmineユーザに熱いパッションを持つ人達が多いので、最新機能をいち早く試して人柱になったり、数多くの運用事例を紹介してくれたりして、コミュニティ中心に盛り上がっているけれど、いつまでもそういう幸運は続かないかもしれない。

GitLabでタスク管理してみた感想(主にRedmineとの比較) - YoshinoriN's Memento

【5】とはいえ、そういう課題がRedmineに見えてきたが、たぶん、解決できるだろうと楽観視している。
また、技術者として、ツールの課題を技術面から解決していったり、それについて色々試行錯誤して技術を試すことは楽しい。

今後もいろいろ考えてみる。

【追記1】
Gitlabの場合、RPMが提供されている。
よって、yum updateだけで簡単にバージョンアップできる。

Manually Downloading and Installing a GitLab Package | GitLab

GitLabを7.9.2から7.12.0にアップデートした時の話 - Qiita

Git lab rpm でインストール - Qiita

Redmineでも、RPMを提供できないだろうか??
また、Redmineのバックアップ用のrakeタスクも実装できないだろうか?

そうすれば、プラグイン無しの標準Redmineであれば、DBバックアップと添付ファイルバックアップだけすれば、VerUp作業そのものを自動化できるからだ。
RedmineやRubyの初心者であっても、インストールやバージョンアップ、バックアップに苦労する問題はなくなるだろう。

【追記2】
皆同じ事は考えている。

taikiixさんのツイート: "現代の開発フローがGitとPRを中心としていることを考えるとPRの実装は喫緊の課題だと思います。でもそれ以上に、半年でメジャーバージョンアップするGitLabに対抗するには今の開発スピードでは歯が立たない。だからRedmineはGitHubに開発の場を移し、広くcontributorを集める必要があると思います。… https://t.co/jt4Kmk9pCx"

MAEDA Goさんのツイート: "gitへの移行はJPLがその気になる必要があるため、簡単には進まないと思います。本家のやり方を変えずに開発への参加のハードルを下げる方法として、非公式のミラーリポジトリでプルリクエストを受け付けて私がGitHubとチケットの中継をするのはありだと思います。私が中継するので日本語でOKです。… https://t.co/LIFzu4B1lk"

【追記3】
akipiiさんのツイート: "日本の熱心なRedmine ユーザーは自らモルモットとなり、自ら海に飛び込んでいくのです!その結果は如何に?… "

あさこさんのツイート: "大きな海に溺れるも、無人島にたどり着く。そこの名は、redmineアップデートセンター…‼… "

akipiiさんのツイート: "@agilekawabata さんに解決してもらって、 @g_maeda さんに本家に取り入れてもらいましょう。。。… https://t.co/svy5cW1puI"

やっさんさんのツイート: "GitHubがメインリポジトリならもっと参加者増えて開発も回りそうな気もするんですけどねぇ🤔… https://t.co/YekJeR0RRl"

【追記4】
門屋 浩文さんのツイート: "こちらこそー。これは感覚論だけど、同じシステムを使う人は似たような振る舞いをするようになる。社会や文化と同じように。redmine関係者の振る舞いや感性は、正直好きだね。いろいろおいてきた、できなかったことが少しずつできるようになるヨ・カ・ン… "

akipiiさんのツイート: "似た振る舞いになる、と言う話は同感。たぶんチケット管理してれば、Redmine でもJiraでもTrelloでも手法や考え方は同じ。以前できなかった事がチケット管理ツールで実現できる予感も同感。ソフトウェア工学は本来はこういう開発基盤が欲しかったはず、といつも思う。… https://t.co/3OzYY4e39R"

akipiiさんのツイート: "Redmine にある機能は、細かな一機能に過ぎないかもしれないが、人の行動を変えさせるきっかけになる、と言う事例は心当たりがないですか? 是非エバンジェリスト会でネタを集めてください笑… "

akipiiさんのツイート: "Redmine でバージョンアップごとに改善された機能には、世界中の開発者が試したベストプラクティスが反映されてる。ツールの機能とプラクティス、そして開発プロセスは表裏一体と思います。特に最近のRedmine,Gitlab,Jenkinsはそう強く感じる。… https://t.co/N1LJQ69erp"

あさこさんのツイート: "redmineにも、アップデートセンター入れてほしい。… "

あさこさんのツイート: "あわわわわわ… 川口さんが、jenkinsはアップデートセンター入れてから爆発的に広がったと言っていたので、同じような経路をたどるかもしれませんね。。 そうすると、redmineバージョンアップの毒沼地はいい感じで消えていってくれる…かもしれませんね(・_・;)… https://t.co/tSddJPec3O"

akipiiさんのツイート: "似た話として、Gitlabにはrakeコマンドで自動バックアップするコマンドがあった気がする。Redmine と同じRailsアプリならば、他ツールの機能をパクるやり方もありですね。… "

【追記5】
RedmineのREST APIにも、SwaggerのようなI/F仕様書のWebサーバーがあれば、もっと使い勝手は良くなるだろう。

SwaggerでRESTful APIの管理を楽にする - Qiita

SwaggerでWebAPIドキュメントをExcel仕様書から脱却するアイデア: プログラマの思索

あきこさんのツイート: "RedmineのAPIはドキュメントが分かりにくいかな? 公式サイトにも載ってるけれど、GETしか対応してなかったり。 apipieやswagger docのようにソースコード中のコメントや説明がそのままドキュメントとして表示できるようになってたらなあ...なんて思います。"

あきこさんのツイート: "他はわからないんだけれど、JenkinsはRest APIのドキュメントのページがアプリケーションの一部としてくっついてた。JIRAやConfluenceも、ローカルで動かしたとき、Rest API Browserっていうのがあって、APIの仕様の確認がしやすかったなー。"

| | コメント (0)

2018/04/06

「小水力発電が地域を救う」の感想

佐藤知一さんのBlogで「小水力発電が地域を救う」が紹介されていたので読んでみた。
読みやすかったので簡単なメモ。

【参考】
書評:「小水力発電が地域を救う」中島大・著 : タイム・コンサルタントの日誌から

Life is beautiful: 私が事故後、脱原発派に転向した一番の理由

【1】本を読んでみて、小水力発電の技術だけでなく、小水力発電を中核とした地域経済のエコシステム、そして、超低金利が普通となった現代において資本主義の終焉が間近に語られるようになった今、今後の文明の行き先みたいなことまで妄想してしまった。

【2】P.17-18
世界的に、経済のグローバル化と、それに抵抗する動きの対立が目立つようになりました。
(中略)
私自身の意見は、世界はモザイクのように個性的な市場がたくさん存在するのが自然だということになります。

P.18
東京の生活はお金さえあればとても便利ですが、いざ物資が入らなくなったら何もできません。
分業が進むと効率が上がりますが、効率性は脆弱性と裏表の関係にあります。

震災や福島原発の事故があった時の東京、関西を思い出せば、都市の生活は非常に脆いと身を持って感じた。

【3】P.176
町育ちの人たちばかりになると、社会が脆くなります。

P.177
私は、都市は人を育てない、と考えています。
都市は競争社会です。腕に覚えのある人が集まるウィンブルドンのようなものです。

一方、人を育てるというのは、とても冗長な営みです。
多様な才能を丁寧に育てないと優秀な人材は育ちませんし、育った優秀な人材がその時代の社会に適合するとは限りません。

これも同感。
だから、グローバル化に反対する人が欧米でも日本でも多くなったような気もする。
冨山和彦さんが提唱する「グローバル経済圏、ローカル経済圏」の話(「なぜローカル経済から日本は甦るのか」)もこれに通じる。

【4】P.22
小水力発電の可能性のある場所を開発すれば、山間地は電力の面で自立できるわけで、地域にとっては十分に大きな電力だと言えるのです。

p.47
農産加工品などの市場開拓は簡単ではありません。ところが、小水力発電の電気は、FITのおかげで必ず売れるという利点があります。

P.38
小学校の存続は、地域が存続するかどうかの先行指標と言っても過言ではありません。
子育て環境の悪化で若い夫婦がいなくなるだけでなく、子どもたちの帰属意識が薄れ、高校・大学を卒業した後戻ってくる動機が弱くなるからです。

子育てが重要な理由は、子供たちが大人になって、また地元の経済を活性化させる、というエコシステムの一部であるからだろう。
だから、今の日本では少子高齢化の危機意識が高まっているわけだ。

P.66
山村の土建会社は小水力発電で生き残れ

P.67
建設業者は水力発電と相性がいい。

P.138
(村長が発言)
道路をつくる予算を使って、代わりに水力発電所をつくれば、毎年、お金が入ってくる。
そのお金はムラのために使うことのできる自由なお金だ。

本来、日本は山が多い国なので、小水力発電に向く場所は多い。
小水力発電による発電量は少ないかもしれないが、村の住民の電気を賄うことは可能だし、今は売電することで安定的に利益も得られるメリットがある。

一方、村の土建業者にとって、小水力発電の建設、修繕、復旧などの作業は自分達のノウハウをそのまま流用できるので、技術的にも相性が良い。
しかも、公共工事の変動に左右されずに、売電収入が安定的に得られるメリットもある。
そして、土建会社の経営者は、経営面でもコスト感覚の優れた人達が多いので、小水力発電のようなビジネスを上手く回すのに向いている。
また、村の土建会社の経営者は、その地域の有力者の一人の場合が多いので、地域社会の取りまとめ役にも最適だ、と言う。

この辺りの内容は、書評:「小水力発電が地域を救う」中島大・著 : タイム・コンサルタントの日誌からの記事で詳しく解説されているので分かりやすい。

【5】P.145
自分達が主体になれば、地域が長く生き残れる

しかし、過疎地域で小水力発電を実現するには、地域の人達自身がリーダーシップを発揮して、彼ら自身で運営する仕組みが必要だ。
つまり、小水力発電という中核システムを基盤として、地域経済の持続的発展を目指すように、地域内の利害関係者が団結する必要がある。

「補償金は人を幸せにしない」「オープンにすることで地域利益を確保する」などのノウハウも書かれていて面白い。

【6】P.129
水力は高いは本当か?
水力発電は太陽光や風力に比べて初期投資の金額が大きくなるからです。

P.130
そのかわり、水力発電には、太陽光や風力よりも設備の耐用年数が長いことと、年間発電量が多いことの二つの利点があります。
100年間の総費用を100年間の総発電量で割って平均コストを算出すれば、おそらく太陽光や風力と同じか、むしろ安くなるはずだと考えています。
ただし、この計算では金利を一切考慮していません。

P.130
ソフト・エネルギー・パス」で「長期割引率はゼロもしくは若干マイナスと」すべき、と書いて以来、エネルギーシステムの持続可能性の議論において、割引率をプラスで考えるか、ゼロ以下にすべきか、経済はと環境派の対立点の一つになってきました。

P.131
割引率をゼロとする立場に立てば、金利を考えない100年間の平均コスト比較に合理性があるはずです。
また、現実の話、今の超低金利は一時的な現象ではなく、これからの標準的な状況だと考えています。

P.131
そもそも、高度経済成長期のような、リスクを取らずに金利が得られるという経済状況がむしろ珍しく、イスラム金融ルールのように、リスクを取らなければ金利を取るべきではないという経済状況の方が歴史的にはむしろ普通だったのではないでしょうか。

水力発電は他の再生利用エネルギーよりもコストが高いか否か、という問題点は重要だ。
筆者の意見では、長期的な割引率をゼロ以下とみなせば、むしろ安くなるはず、という。
理由は、現在の超低金利は一過性の事象ではなく、今後の標準的な事象とみなせるから、と。

この点に関しては、僕も同感。
既に、日本だけでなく欧米でも経済成長率がかなり落ち込んでいるのは誰が見ても明らか。
そして、日本や欧米の超低金利は一過性の事象ではなく、今後も続くだろう、とたぶん誰もが心の中で感じているのではないか。

ティール組織」でも、P.491にて「経済成長率がゼロの社会では、利子を産まないかマイナス利子を生む新しいタイプの通貨に投資しなければならなくなると考えている」という一節がある。
将来の経済について深く考えている人たちは、金利がマイナスになる経済、つまり資本主義の終焉について既に色々考えているのだろう、と思う。

| | コメント (0)

2018/04/04

「プロエンジニアになるための「アジャイル開発」再入門」が素晴らしい

倉貫さんの資料プロエンジニアになるための「アジャイル開発」再入門が素晴らしいのでリンクしておく。
新入社員向けのアジャイル研修の資料は、これを使えば十分ではないかな、と思った。
以下はラフなメモ書き。

【研修資料】

【参考】
アジャイル開発とウォーターフォール型開発の違いについて再考: プログラマの思索

アジャイルとウォーターフォールは文化や価値観のレベルで異なるという話 - たなかこういちの開発ノート

アジャイル開発の本質 ? アジャイルとウォーターフォールの違いとは | Social Change!

ソフトウェアは完成しても価値はない ? アジャイル開発は何を解決するのか | Social Change!

アジャイル開発とは:「アジャイル開発」をエグゼクティブサマリにまとめてみた | Social Change!

ドキュメントをなくしてもうまくいく? ? 人に依存するリスクへの対処とは | Social Change!

【1】「ソフトウェア開発をチームで行う内容をよく知らない新入社員に、アジャイル開発をどのように説明すればよいか?」という問題に対し、上記の資料はその解決にとても役立つ。

倉貫さんのBlogや資料がとても読みやすく優れているなあ、と思う点は、ITをよく知らない人、アジャイル開発を知らない人に対して、普段着の言葉でその本質を上手く的確に表現している点だろうと思う。

既にアジャイル開発を知っている人ならば、上記の資料はとても当たり前の内容だろう。
しかし、その当たり前に思っている感覚を、新入社員やITに詳しくない経営者に説明して納得させるのは、とても難しい。
自分がこれだけ、今後のソフトウェア開発はアジャイル開発になるべきだ、と確信していても、普通の人には伝わらない。

一番分かりやすい説明方法の一つは、対比させることだろう。
たとえば、上記資料では、「これまでの開発は、ノンビリしていたな」「でも、これからの開発は、Software is eating the World」のように、従来と今後の開発スタイルを的確に表現している。

また、アジャイル開発の特徴である「最初に決めた機能を全部作らない」「最大限の構想よりも最小限の完成品を作る」「何を作るのか、ではなく、何を作らないか」「タスクをバラし、見積もりし、優先順位を決める」などを分かりやすく説明してくれている。

【2】日本人がアジャイル開発を理解しにくい理由は、日本人が製造業の成功体験に縛られていて、品質の考え方をアジャイル開発へ置き換えられない事が、最大の原因ではないか、とずっと思っている。

【2-1】上記資料では、その点について「“Point of Sales”から“Point of Use”へ」で明確に記されている。
製造業では、一度作った製品はその後で変更できないのが普通なので、出荷時に最高品質を保証できるように頑張る。

一方、ソフトウェアは一度リリースしたとしても、それから利用し始めて初めて、ユーザにとって、ありがたみを感じることになる。
つまり、本番リリース後の保守フェーズで品質を上げていく発想が重要だ。
この点は何度強調しても強調しきれない。

すなわち、ソフトウェアは完成しても価値はない ? アジャイル開発は何を解決するのか | Social Change!の記事の通り、「ソフトウェアは完成だけしても意味はない。むしろ負債である」という事を意味している。

【2-2】経営者ならば、損益分岐点分析は必ず知っているが、それをソフトウェアに適用すると、まさに初回リリース時点では、まだ利用していないのだから、初期投資した分だけ赤字だ。
そこからシステムを利用して、実際に回収して、初めて、損益分岐点を上回れば、元を取った、という事になる。
それまでは、システムはずっと負債であり、利益を得るまで回収する責任や義務が発生するわけだ。

僕も、経験上、ソフトウェア投資は資産なのか負債なのか、と暗黙的に疑問に感じてきたが、上記資料では、明確に、「ソフトウェアは負債だ」と明確に説明してくれているので、改めて腑に落ちている。

【2-3】では、この発想を受け入れると、どんな影響が出てくるか?

結論は、ソフトウェア開発の目的が品質重視から、価値重視へと変換されることだろう。
それはどんな意味を持つのか?

従来の製造業の発想では、マーケティング1.0の供給者重視からマーケティング2.0の顧客重視へ変わった。
さらに、上記の発想では、マーケティング2.0の顧客重視だけでなく、顧客に届ける価値を重視する発想、つまり、持続可能な社会を実現するマーケティング3.0へ発展するだろう、と考える。

なぜなら、顧客が利用し続けて、高額な初期投資を回収できて利益が得られるならば、いかに早く回収するか、という方向へ発展して、最終的には、では、顧客が使い続けてくれるにはどこに価値を感じてくれるのか、という方向へ考えるようになるだろうからだ。

すなわち、顧客の企業だけが儲かれば良い、という発想ではなく、持続的に成長して会社を半永久的に維持していくには、顧客の企業を取り巻くステークホルダー、たとえば、従業員や取引先、地域の人々、との関係性を重視して、エコシステムを作っていく、という流れに変わっていかざるを得ないからだ。
そうでなければ、顧客の価値を実現したとは言えないと思う。

つまり、アジャイル開発で「価値重視」と呼ばれる所以は、そういう背景がある、と考える。

【2-4】すると、ソフトウェアの品質にすごく影響してくる。
初回リリース前のテストでいくら頑張ったとしても、本番リリース後にユーザが価値を感じて利用してくれなければ、システムはただのゴミ箱に過ぎない。
また、利用中に機能追加していくうちに、使いづらくなった、と感じて、利用が減ると、ソフトウェアの価値はどんどん減ってしまう。

つまり、保守フェーズでの品質維持、さらには利用頻度向上が大事になるので、機能性や信頼性よりも、保守性や移植性という品質特性が重視されるようになるだろう。
ソフトウェアはそのまま放置しておくと、エントロピーが増大して、その複雑性が手に負えなくなっていくからだ。

そのために、リファクタリング、テスト駆動、継続的デプロイ、DevOpsなどの開発技術が研究され、今も技術革新されているわけだ。
そして「アジャイル開発では全部作らない」という発想へつながっていく。

【3】さらに、プログラマに求められる価値は、製造業のワーカーのように、技術標準や作業標準を起点としてPDCA(つまりSDCA)サイクルを回す方法ではなく、クリエイティブな発想を大切にしながらそれを実現していく方法へ変わっていく。
この辺りの内容は、数多くの手法が提唱されていて、どれかに理論として一つに統一されている感覚は受けない。
つまり、まさに色んな人達が、汎用的な手法を試行錯誤している所だろう、と思う。

おそらく、プログラマのいるソフトウェア開発の会社は、従来の病院や会計事務所、法律事務所などのような「プロフェッショナル官僚制」へと発展していくのかな、と思ったりもする。
なぜなら、倉貫さんが提唱する顧問プログラマは、顧問弁護士、顧問税理士にたとえられるので、プログラマの人数が増えれば、そういう方向へ進化するのではないか、と想像できるから。

H. ミンツバーグ経営論 : 戸崎将宏の行政経営百夜百冊

官僚制と管理システム

「H.ミンツバーグ経営論 第8章「組織設計:流行を追うか、適合性を選ぶか」」のオーディオブック - audiobook.jp

しかし、一方で、「ティール組織」のように、個人のパフォーマンス重視の組織へ進化するアイデアも提唱されている。
実際、倉貫さんが提唱するホラクラシーは、「ティール組織」が提唱する最終型の組織にぴったりだ。

「ティール組織」の本を読んでみて、アジャイルとウォーターフォールは文化や価値観のレベルで異なるという話 - たなかこういちの開発ノートの内容がまさに当てはまる、と感じた。

つまり、「ティール組織」が提唱する最終型の組織は、従来の我々が知っている組織文化や価値観と全く違うのだ。
そういう事実を理解しなければ、「ティール組織」は大変読みにくい本だろう、と思う。

「ティール組織」の感想はまた後で書く。

| | コメント (0)

«SwaggerでWebAPIドキュメントをExcel仕様書から脱却するアイデア