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のようなコンテナ化に解決の鍵があると感じている。

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

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

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

| | コメント (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)

2018/03/29

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

Swaggerを使うと、WebAPIドキュメントをExcel仕様書から脱却してシステム化することができる。
自分はまだ無知なので、以下は自分用のメモのリンク。

【参考1】
【連載】Swagger入門 - 初めてのAPI仕様管理講座 [1] Swaggerとは|開発ソフトウェア|IT製品の事例・解説記事

(引用開始)
システム開発のトレンドとして、マイクロサービス化が進んできています。モノリス(一枚岩)スタイルの開発に比べて、アプリケーションの単位は小さくなり、多くのサービスが構築されます。

Uberの配車ビジネスやAirbnbの民泊に代表されるデジタルビジネスにおいても、APIエコノミー化が進んできており、Google Map APIやTwitter APIなどさまざまなAPIを組み合わせて素早くシステムを構築します。
Programmable Webでは、2017年1月時点で16,590以上のAPIが検索可能で、2009年9月の10倍以上、2006年5月の90倍近くに達しています。

では、そういったマイクロサービス・APIエコノミーの開発現場では、一体どのようなことが起こっているのでしょうか。

例えば、Androidのアプリから叩いているサーバのAPIが機能追加されたために、3日間かけてテストして終わったと思ったら、いつのまにか更なる仕様変更が入っていた。APIのインタフェースを定義するドキュメントの仕様に従ってアクセスしたら、実は実装との乖離があり、うまく動かなかった。

このようにAPIプロバイダとAPIコンシューマ間の悩みはさまざまです。ただし、いずれもサービスインに影響を及ぼす重大な問題と言えます。インタフェースの向こうの世界は関与できないことが多いだけに、仕様と実装の乖離はあってはならないものなのです。
APIエコノミーを作るにあたり、このようなことを起こさないためにも、APIについて正しく記述した仕様書が必要となってきます。
(引用終了)

【参考2】
Swaggerとは何か? - プログラマでありたい

Swaggerを使ってインタラクティブなWeb APIドキュメントをつくる - Qiita

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

Swaggerの概要をまとめてみた。 - Qiita

【Swaggerの実例】
API リファレンス | SORACOM Developers

【1】Webシステムをモノリック・アーキテクチャからマイクロサービス・アーキテクチャで設計することで、まるで部品を組み立てるかのように、迅速にシステムを構築することが可能になった。
つまり、斬新なアイデアを実現するWebサービスを素早くリリースして、市場のニッチリーダーからシェア独占を狙って、先行者利益という独占利潤を得たいわけだ。

例えば、Uberの配車ビジネスやAirbnbの民泊。
日本なら、例えば、メルカリ、DMMとか。

現代は、これらシリコンバレー発祥のWebサービスが、自動車業界やホテル業界を直撃している、と言える。
よって、マイクロサービス・アーキテクチャで作られたWebサービスは、ありとあらゆる業界のビジネスモデルを一瞬にして破壊してしまう可能性が高い。
だから、こういうAPIエコノミーに対し、古い業界の人達も戦わざるを得ない。

【2】しかし、マイクロサービス・アーキテクチャの根幹となるWebAPIは、VerUpによってコロコロ変わってしまう問題がある。
そこで、I/F仕様をWebで公開して、即時に情報共有できるようにしたい。

つまり、マイクロサービス・アーキテクチャの実装基盤であるREST APIのI/F仕様を公開できるようなWeb基盤が欲しいわけだ。

【3】そこで、その候補として、Swaggerがあがる。
Swaggerの特徴は、「インタラクティブなWeb APIドキュメント」。

つまり、単純にWebへ公開できるドキュメントが作成できるだけでなく、リクエストを入力すればレスポンスを表示できる仕組みまである。
すなわち、APIをWebに公開できるだけでなく、使用しているAPIがVerUpしても使えるかどうか、事前に自動テストすることも可能。
これによって、Webサービスをリリースする時、利用しているAPIが使えなくなった、というリスクを減らすことができる。

たとえば、ソラコムさんのWebサイトが最も良い事例だろう。

API リファレンス | SORACOM Developers

上記の記事にもあるが、Dockerによるビルド環境構築やCIツールをSwaggerと組み合わせれば、マイクロサービスで組み立てたWebサービスの自動テスト、デプロイやリリース作業の自動化にもつながるだろう。
つまり、マイクロサービスで作られたWebサービスの品質向上、開発速度の向上にも役立てられるはず。

但し、Swaggerで全ての問題が解決されるわけではなく、まだ課題もある。
たとえば、Swaggerて゛のapi開発よもやま話の18ページにあるように、たくさんのAPIを一瞥できるような『オブジェクト構造図(仕様書のObjectの参照関係を階層構造で定義)』が欲しくなる。

【4】今の僕は、Excel仕様書からいかに脱却するか、というテーマを持っているが、その中でも、I/F仕様書は色んな意味で重要性が高い。

なぜなら、公開したI/Fというものは、自分のチーム以外の他チームも参照するので、説明責任が発生するし、I/Fの仕様はシステムのVerUpによって変わってしまう時が多いのに、その変更内容をExcelドキュメントへ反映する手間が結構かかるからだ。
しかも、I/FがVerUpで変わった、という事実を他チームにも随時連絡する手間も発生する。

よって、I/Fが変わったら、自チームがプッシュ通知するのではなく、他チームがプル通知で自動検知する仕組みの方が運用が楽になる。
そこで、SwaggerのようなWebAPIドキュメントの基盤を有効に活用できるだろう、と思う。

【4-1】ここで、I/F仕様書がSwaggerで置き換えられる可能性を考えると、現代という時代は、Excelドキュメントを一生懸命に書くよりも、仕様書というモノさえプログラミングする時代なのだ、という気がしてくる。

実際、単体・結合テストなどのテスト工程の作業は、TDDやCIなどの開発支援ツールでプログラミング作業に集約できる。
また、デプロイやリリース作業、そしてビルド環境や本番環境のインフラ構築作業も、DockerやGitHub、CIツール、AWSなどのクラウド環境などの技術によって、プログラミング作業で代替できるようになった。

今後は、要件定義や設計作業ではExcelドキュメントを書く、という作業も、きっとプログラミング作業で代替されるようになるだろう。
つまり、いちいち自然言語で要件や仕様を書くよりも、YAMLやJSONに似たデータ構造あるいはDSLによって、いきなりプログラムを書いた方が速いし、その後の保守更新も楽になる、という方向へ進化していくはずだ。

仕様書をプログラミング作業の本体であるテキストで代替できれば、Gitで管理できるし、そうすれば、TDD・CI・プルリクエスト・継続的デプロイなど昨今の開発支援技術の恩恵を受けられる。
よって、ドキュメントの情報共有が促進され、フィードバックを受けて修正すれば、仕様書の品質そのものも向上できるはず。

では、仕様書のExcel脱却の起点となる課題は何か?
答えは、Gitで管理できるか、そして、テキストからAPI仕様書や図表などを自動生成できるか、という課題に集約されるだろう、と思う。
幸いなことに、MarkdownやPlantUMLなどの記法でテキスト化すれば、HTMLやOfficeドキュメント、PDFへ自動生成するツール(Pandoc、MkDoc、他たくさん)で、今まさにたくさんの技術が実験されている。

この辺りの技術も、技術の進化の歴史の観点で今後整理していきたい。

| | コメント (0)

2018/03/23

自分の天分を知るとは何だろうか

ネットでウロウロしていたら、『物理の道しるべ―研究者の道とは何か』に関して、物理学者が自分の天分を知る事について記事があったのでメモ。
すごく心を揺さぶられた。
以下はラフなメモ。

【参考】
『物理の道しるべ―研究者の道とは何か』を読んだ - shiroshippo's blog

(引用開始)
少し前に読んだ。
元は雑誌『数理科学』の連載で,物理学者たちがその人生について振り返ったエッセイを集めたもの。
出てくる先生の人生も,運とか人のつながりで決まってるんだなと思った。

p.154, 155から引用。
私が物性理論という分野を選ぶまでにはいろいろな紆余曲折がありました。
高校時代は数学が3度のご飯より好きで,東大の理科I類に入学したときには当然数学科に進むつもりでいました。
実際,当時の雰囲気は最もできる学生が数学科に進学するという感じだったのです。
ご存じのように,東大では最初の2年間は駒場で教養課程を修了し,その後(実際は1年の夏休み明けごろに)学部・学科を決めるという進学振り分け制度が行われています。
その駒場での2年間,自分の適性というものを試してみるチャンスがあったわけです。

まず,大きな期待を持っていた数学ですが,すぐに自分には無理だとわかりました。
解析は良かったのですが,線形代数の講義が,いきなり体とか環とか抽象的なものばかり出てきて,公理・定理・補題…の連続に頭が痛くなってしまったからです。
その反動か,今度はドイツ文学や哲学に惹かれて文学部に進もうかと考えたり,そうかと思うと今度は化学こそは現実の世界に最も肉迫できる学問だと考えていろいろ勉強したりしていました。

ちょうどそのとき,化学の授業で「試薬分析」の課題がありました。
いろいろな試薬を使った反応を見て,試験管の中の未知の物質Xを決定せよ,という課題で,私はその日が来る前から十分な準備をして,「完璧な」場合分けの系統図を作り,どのような物質Xに対しても必ず決定できる方法を持って臨んだわけです。
ところが当日になると,匂いを嗅いだりして大体の「あたり」を勘でつけて,2, 3個の試薬を試して「わかった。
これはXXだ」と正解を出してしまった友人が近くにいたのです。

結局最後の一人になってようやく分析を終えた私に,担当の助手の先生が「君は理論に進んだ方がいいと思うね」とおっしゃったとき,人にはそれぞれの天分というものがあると実感しました。
抽象性と具象性の1次元座標を作ったときに学問分野に応じた抽象度というものがあって,数学を左端だとすると,素粒子理論,物性理論,物性実験,素粒子実験,化学,生物,医学というように並んでいてそれぞれの人に最適のところがあるのだと思います。

こういう風に,大学で何を専攻しようか迷っていた人は結構おおい。
(引用終了)

自分では理解できない現象に出会った時、自分の中でどう対処するのか?
現実問題として、生きていく中で、自分の中の知的誠実さを維持しながら、どうやって折り合いをつけていくのか?

40歳を過ぎてもまだ分からない人もいるし、20代で使命を見つけた人もいる。
自分が本当にやりたいこと、自分の使命とは何だろうか?
自分の天分とは何だろうか?

| | コメント (0)

製造業の品質管理の背後にあるSDCAという考え方をソフトウェア開発に適用できるのか

製造業の品質管理を調べてみて、その背後には、「SDCA」という考え方があるのではないか、と考えてみた。
ロジカルでないラフなメモ書き。

【参考】
日常管理 - エクセルQC館

PDCAサイクルとSDCAサイクル【品質改善と維持管理の考え方】

mame1

「当社の業務改善サイクルは『SDCA』」 トステム 佐藤方厚 執行役員IT推進統轄部統轄部長 | 日経 xTECH(クロステック)

【1】製造業の品質管理では、「標準化(Standard)」という言葉が頻繁に使われる。
彼らの意図としては、定型化できる作業、皆が知るべき技術ノウハウは標準マニュアルで整備して、安定した状態(品質)にすべき、という考え方がある。

たとえば、工場で大量生産するネジを作る時、不良品がたくさんできて歩溜まりが低いと、製造原価が高くなってしまう。
製造作業が不安定であると、製品の品質のブレが大きくなってしまうからだ。
つまり、管理図で言えば、UCLやLCLを超えた製品が多くなり、品質不良として出荷できなくなることを意味する。

そこで、ベストプラクティスを標準化という名の下に作業マニュアルにしてしまい、作業員はその作業マニュアルに従って作業すれば、安定した品質となり、歩溜まりが向上する、という方向へ持っていく。

その考え方をプロセスとして定めると、SDCA(標準→Do→Check→Action)という流れになる。
まずは標準を守って、そこから実施して評価し、是正対策を取って、標準を更新していく、という流れ。
つまり、PDCAサイクルで品質統制を行う発想だ。

このプロセスは、量産品を作るメーカーだけでなく、チェーン展開するサービス業や飲食店などにも適用しやすい。
どこに言っても同じサービスや料理の味を低価格でそこそこの品質で提供する、というやり方が向いているからだ。
たとえば、大量のアルバイトや社員を雇ったサービス業として、コンビニ、小売業、航空機内の客室乗務員、ホテルのオペレータとか。

また、個人経営の飲食店であっても、毎日提供する料理の品質を安定させることができれば、原価低減でき、利益を安定的に確保しやすくなる。

【2】しかし、昨今の時代の流れの中で、特にソフトウェア開発では、SDCAの考え方は向いていないと思う。

たとえば、業務ルールを策定したり、技術ノウハウを共有したい、と考えるWF型開発に偏ったプロジェクトリーダーは、Excelドキュメントでそれらをまとめて、共有ファイルサーバーに置いて、メールで告知して共有しようとする。
しかし、その内容はすぐに忘れられて、同じようなことを何度も繰り返す。

あるいは、社内の標準プロセスを定めて、設計書テンプレートのExcelドキュメントを作り、すべての案件に適用しようとするが、受託開発から保守案件、実費請求の要件定義案件まで多種多様なPJがあると、一つの標準では当てはまらない。
結局、数多くのカスタマイズによる派生ドキュメントが発生し、標準からどんどん離れていってしまう。

組込みソフトウェア開発のプロセス改善の違和感: プログラマの思索

【3】では、なぜ、ソフトウェア開発では標準化という考え方が上手くいかないのだろうか?

僕の考えでは2つあると直感的に思う。

【3-1】一つは、ソフトウェア開発は、組織能力よりも、個人のパフォーマンスに依存する度合いが強い事があると思う。

ソフトウェア開発では、システムの技術ノウハウや設計ノウハウは人に付いて回る。
たとえば、受託開発したシステムを本番リリース後、大量の派遣・委託のプログラマが抜けると、システムに関する知見もチームから失われ、保守コストがどんどん大きくなる、という事例はよく見かける。
そのために、数多くの設計ドキュメント、ノウハウを書いたExcelドキュメントを大量に残すけれど、結局役立たない。
システムは保守するたびにどんどん変化していくので、それらドキュメントも古くなり陳腐化してしまう。

また、新しい技術の知見も人に付いて回る。
ドキュメントを読むよりも、その人に聞いたり、レクチャを受けた方が速い。

「現場から始めるアジャイルの技術プラクティス」資料が素晴らしい~技術は人やチームに残る: プログラマの思索

すなわち、標準化しようとしても、形式知化できない部分があるし、暗黙知の部分の方が大きすぎる。
ゆえに、ソフトウェア開発の生産性は個人の能力に依存する度合いが大きく、それを組織で維持ししていくのは非常に難しい。
よって、個人のパフォーマンスを最大限に発揮できるような環境や組織体制を整備する方向へ持っていくべき、というのが最近の時代の流れなのだろう。

たとえば、議論しやすい場を設けてお菓子を用意する、プログラマが座る椅子を高価なものにする、最新のPCやサーバーを用意する、などのファシリティ(資産)が重要な理由は、個人のパフォーマンスを発揮できる環境づくり、という意味もあるのだろう。

そして、アジャイル開発がプログラマに好まれる理由の一つは、アジャイル開発は組織駆動ではなく、個人のパフォーマンス駆動であり、人重視のプロセスでやり抜く、という点にあるのだろう。

だから、人を大切にすることで、システム開発で得られた知見をチームに残す、という発想につながるのではないか。

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

【3-2】もう一つは、Excelドキュメントと相性が悪い点もあるように思う。

技術革新が速いので、Excelドキュメントに書いても、陳腐化してしまう。
Excelドキュメントの賞味期限が短すぎるのだ。

そして、Excelドキュメントは履歴管理しにくいし、検索しにくい。
日付の入ったファイル名のExcelが増殖し、最新の内容がどこにあるのか、作った人も分からなくなる時もある。

そこで、技術ノウハウはWikiに書いて残す、という手法もある。
もちろん、Wikiの内容も陳腐化してしまう可能性は高いが、Webで公開されていれば、他の人が気づいて更新することもできる。
全文検索エンジンによって、有用な情報だけ探す、ということもできる。

標準化した情報がすぐに陳腐化してしまうなら、その内容を即座に更新できたり、それらを即座に共有できたりする基盤があれば、ある程度は解決できるはずだ。
この辺りの内容は、一つのテーマとして、ずっと考えている。

仕様書にもExcel脱却が求められている: プログラマの思索

PlantUMLを使ってExcel設計書をテキスト化するアイデア: プログラマの思索

静的ジェネレータを使ってExcelマニュアルをWeb公開するアイデア: プログラマの思索

【4】SDCAという考え方が合わない場面が増えているのは、定形業務のビジネスモデルが最近は儲かりにくい、という点にもあるのだろう。
「Software is eating the world」という流れでは、定形業務や低賃金労働は全てソフトウェア化できるし、ソフトウェア化されたビジネスは、限界費用ゼロまでコストが徹底的に低くなる。
すると、人間の手でSDCAサイクルを回して品質管理をやっていく、という悠長なやり方は通用しにくくなるのではないか。

「ソフトウェアが世界を飲み込む理由」「ソフトウエア、それが問題だ」の記事のメモ: プログラマの思索

『ソフトウェアが世界を飲み込む理由』 - 渡部薫 ジークラウド CEO - 経歴・略歴 - Kaoru Watanabe, Profile, Career

ソフトウェアが世界を変えている – うめのんブログ

この辺りも整理してみる。

| | コメント (0)

2018/03/22

カイゼンジャーニーの感想~アジャイルサムライの再来かな

「カイゼンジャーニー」を一気に読んだ。
昔読んだ「アジャイルサムライ」の雰囲気に似ている。

興奮しすぎて、理解した内容をまとめきれていないけど、ラフなメモ書き。
付箋を引いた所だけ、思いつくまま書いておく。
ロジカルでないので、後で直す。

【感想】
akipiiさんのツイート: "カイゼン・ジャーニーを一気に読んだ。スクラムからモダンアジャイルまでのプラクティス、著者の経験に裏打ちされたノウハウを文章の背後からすごく感じる。アジャイルサムライの日本版だなあ。 https://t.co/B54C8o2Dw2"

akipiiさんのツイート: "素晴らしい本で凄く惹き込まれました。コラムの知識もウンウンと頷くと共に、中身の濃い本と思いました。ストーリー形式もいいですね。… "

【1】(P.80)「何のために、このチームは、こんな追い立てられるように仕事しているの?」
「ベロシティを上げることを目的とする限り、このチームは目先のタスクに圧倒され続けるやろうね。みんながそれを選択してしまっている。」

ソフトウェア開発の途中では、当初のゴールや目的を忘れて、日々のアウトプットを作るだけになってしまう時がある。
タスクの消化だけに目が向いている。
しかし、実際に作り上げたシステムは、受け入れテストで実は顧客の思いと違っていた、という結果になる事態は経験上よくある。

「カイゼンジャーニー」はここでインセプションデッキを使う。
紹介されているインセプションデッキは、筆者独自にカスタマイズされている。
そのノウハウを読むと、数多くの現場で叩かれて、鍛えあげられたのだろう、とその背景を想像してしまう。

【2】(P.117)狩野モデル

狩野モデルと商品企画:部門別スキル - 品質管理なら日本科学技術連盟

チームが狙うべきシステムの品質を狩野モデルの3つの品質で区別しようとしている。
「カイゼンジャーニー」の文脈では、アーキテクチャや開発基盤を安定させることを重視する当たり前品質から攻めるのか、iPhoneのようにユーザエクスペリエンスを重視した魅力的品質から攻めるのか、作戦を考えるべきだ、という。

僕は、狩野モデルをメーカーのハードウェア製品の観点で理解することしか知らなかったから、ソフトウェア開発における狩野モデルに軽いカルチャーショックを受けた。

製造業の品質管理における狩野モデルでも、機能安全を重視する当たり前品質から攻めるか、iPhoneや一時期のソニー製品のような魅力的品質から攻めるか、という観点が同様にある。

もう一つの別の狩野モデルの観点では、製品ライフサイクルによって、魅力的品質→一元的品質→当たり前品質へと顧客から見た品質の観念が変わっていく、と言う考え方もある。
たとえば、販売当初の熱気がある頃は魅力的品質があれば多少のキズも大目に見てもらえるが、売れ出して一巡すると、ユーザはちょっとした機能不足に不満を感じ、最終的には、そういう機能はあって当然でしょ、みたいな感覚となり、シビアに見られてしまう。
僕はむしろそちらの方がしっくりいく。

【3】(P.162)タックマンモデル

この理論も僕は好きだ。

タックマンモデルとチームビルディング – ゲームを用いて貴社のチームビルディング研修,グループワーク,階層別研修をサポートします | 株式会社HEART QUAKE

似たような話として、「世界で闘うプロダクトマネージャになるための本」の中では、プロダクトマネージャが持つべきスキルの一つとして「転換点を意識する」というものがあった。
プロジェクトの中で、ある時点(転換点)を超えると、急に決断しやすくなったり、状況が大きく変わる時がある。
そういう転換点を意識して乗り越えるようにすべきだ、と。

タックマンモデルでいう「雨降って地固まる」みたいな転換点を意識して作り出し、それを乗り越えるように、プロジェクトリーダーはそういうスキルを準備すべきなのだろう。

【4】(P.175)モダンアジャイル

Agile 2016の基調講演: モダンアジャイル

(引用開始)
モダンアジャイルの4つの指導理念は以下である。

人々を尊重する
安全な状態を前提とする
素早い実験と学習
価値を継続的に届ける
(引用終了)

2001年のアジャイル原則は、確かに時代から少しずつズレている気はする。
もっと今風の言葉で、2018年の現在に合うような言葉で言い換えたくなる。

心理的安全という言葉は、「アジャイル開発は、組織駆動ではなく、個人のパフォーマンス駆動で行うものだ」という観点では、個人の安全欲求が満たされた状態で本来のパフォーマンスを発揮してもらうための環境づくり、とも言い換えられると思う。

【5】(P.219)仮説キャンパス、(P.234)ユーザーストーリーマッピング

リーンキャンパス、ビジネスモデルキャンパスは僕も一時期、使ってみようとして色々試してみたが、まだしっくりきていない。
たぶん、ぼくの理解が未熟だからだろう。

ユーザーストーリーマッピングも実戦で試せてないので、本を読んでみると試したくなってくる。
実際の理論と現実の狭間、衝突が面白いのだ。

【6】(P.251)SL理論

リーダーシップの状況適合理論も、僕は好きだ。

2/4 リーダーシップは部下の成熟度で変化させる [リーダーシップ] All About

プロジェクトリーダーとして、チーム運営する時に、リーダーシップを発揮せざるを得ない状況になった時、チームの成熟度に応じて、自分はどんなリーダーシップの振る舞いをすべきか、をこの理論は教えてくれる。
自分の振る舞いとチームの現実が合わない場合、裸の王様に近い感じになる。

【7】(P.255)ハンガーフライト

僕がハンガーフライトと似たような感覚を持つ場所は、新しいコミュニティを立ち上げる時だ。
自分で何かをやりたい、と思った時、傍に同志がいて、彼らと夢を語り、そのエネルギーを使ってコミュニティを立ち上げる。
初めてやってみるのは多少怖いけれど、やってみれば意外に報われる時が多い。

【8】他のプラクティスにも、僕が知らないものもあったし、今までの経験でモヤモヤしていたものが「カイゼンジャーニー」を読んで改めて気づかされたものもあった。
また感想を書いておく。

| | コメント (0)

«アジャイル開発とウォーターフォール型開発の違いについて再考