台北

先日休暇を利用して台湾に旅行した。気づいたことを書いておく。文章に対応する写真がないところがあるが、ブログにアップするために写真をとっていたわけではないので、ご容赦願いたい。

市街へ

台北桃園空港から台北市街に向かう。近代的なビルや工場があることは日本とあまり変わらない。違うとしたら一部のビルの屋上部分が瓦屋根のような形になっていたことくらいか。
市街に到着。宿泊場所が空港から台北駅に向かう途中だったので、途中で降りる。街に出ると、しばしば排気ガスの臭いに出くわす。車も多いが、それ以上にバイクの数は日本では考えられないくらい。実際東京よりも大気汚染はひどいようである。（中国本土や東南アジアの大都市と比べればはるかに良好らしい。）もっとも排気ガス、盆地であるため汚染された空気が閉じ込められること、あるいは中国などから国境を超えた汚染物質の飛来、などの要因がどのように関連しているのかはデータがないのでわからない。

排気ガスの次に気になった臭いは食べ物なのか、生ゴミなのか、腐ったような臭い。どこかで経験があると思ったが思い出せない。日本では飲食店が多い場所で時々はあるが、街を歩いてしばらくの間ずっと、ということはあまりない。後で某国の中華街での臭いだと思いだした。そうしていると、「臭豆腐」の看板が目に飛び込んできた。うわさに聞いていたあれか、と思ったが、想像していたほどではない。

食べ物

名物だということで、最初に食べたのはその臭豆腐。鼻を近づけてみたが、確かに臭いが思ったほどではない。味も至って普通。特別美味とも思わないし、かといって不味くもない。グルメの話はあまり書かないが、美味しくなかった、ということではないので、念のため。

食品の安全

農薬や食品添加物などは普段気になるものの、飲食店では割り切って色がきついものなどを避けるぐらいだが、コンビニなどに行くとついつい原材料を見てしまう。日本語ではカタカナの食品添加物は（英語表記がない限り）漢字の表示を見るしかないが、どの食品にどのような添加物が使われるかはそれほど変わりはないはずなので、大体何のことだか見当はつく。ある朝、「豆漿」（豆乳）を食べようと思って飲食店に行くと、「非基因改造黃豆」なる表示。遺伝子組み換えをしていない、という意味だろうと思ったが、実際そのようである。他にも「無防腐剤」「有機」などの表示がされているのも日本と変わらない。

もう一つ食品の安全で気になるのは衛生状態。旅行ガイドブックを見ると水道水は飲むななどと注意されている。夜市（屋台）での食事も衛生状態が気になり、火を入れたものしか食べなかった。結果として、美味しいフルーツもあまり食べなかった。（後で同僚にそんな話をしたら、もったいないと言われた。）

菜食、ハラル・・・

台北では「素食」という看板をよく見かけた。素食とは菜食のことで、肉や魚を使わない料理を食べられる。使わないものの範囲は店によって異なるかもしれないが、基本的には卵や乳製品はもとより、五葷と呼ばれるネギ、ラッキョウ、ニンニク、タマネギ、ニラも使わない。一般的な台湾の食事には肉が多く含まれるが、台湾にはベジタリアンも多いようである。日本の精進料理とも似ているが、大豆、こんにゃくなどを使って肉や魚に似せた味や食感を出そうとしている点は異なる。

街を歩いた限りではハラル対応の飲食店は一度しか見かけなかった。ただあることはあるようで、イスラム教徒向けに対応しているレストランなどが紹介されている。

「中国」

台湾が「中国」なのか、というアイデンティティが問題になっていることは知られるようになっているが、「中国」的な面の代表ともいえるのが「中正紀念堂」。紫禁城などには及ばないものの、巨大なモニュメントはまさに中国、といったところ。


なお、「中正」とは蒋介石のことだが、現在の台湾における蒋介石の評価は微妙なもので、二・二八事件などでの住民への弾圧のために否定的な評価も少なくなく、実際に陳水扁氏が総統だったころ、「台湾民主記念堂」に改名されたこともあった。

余談だが、近代日本にはこうした建築物は存在しない。ドイツ、イタリア、ソ連など1930年台の全体主義国家、また（全体主義と呼ぶべきかはともかくとして）蒋介石時代の中国も国威発揚と権力の正統化のために建築や都市計画に力を入れていたが、同時代の日本は軍事目的の資材の確保が優先され、国家総動員体制下での典型的な建築はバラック群だったという。（井上章一『夢と魅惑の全体主義』）1940年の東京オリンピックが実現していれば違っていたかもしれないが、そもそも開催返上の主な理由が資材の不足であり、この経緯も建築や都市計画の優先度が低かったことを示している。

もう一つ中国を感じさせるものが故宮博物院。これもまた巨大な建物である。中華文明を代表する所蔵品の数も多いので当然ではある。残念ながら「翠玉白菜」など見られなかったものもあるが、貴重な収蔵品が多数展示されていた。

よく知られていることだが、台北に故宮博物院があるのは、第二次世界大戦後の国共内戦に敗れた当時の国民党政府が台湾に渡るときに故宮の所蔵品も一緒に持ちだしたことによるもの。そのため価値が高いとみなされているものは（北京より）台北に多い。

建物

建物の装飾も寺社など日本の伝統的な建物とは明らかに異なる。屋根には龍など動物が彫られているし、全体としてカラフルである。
また、近代的なビルに中国風の意匠を施したような建物もある。

清朝時代の建造物がそのまま残っている地域は少ない。剥皮寮と呼ばれる一帯がそうした地区で、アーケード状になっている。アーケードはある程度の大通りの両側にはよくある。雨が多いためなのか、歩行者にとっては雨を避けられるのがありがたい。

「日本」

日本を思い出させるものは街中にあふれている。日本人は多く、特に観光地は日本語が聞こえることもしばしば。 飲食店や施設でも日本語の表示があったり、日本語が使えたりすることが多い。日本企業やブランドも至るところに見られる。中にはおかしな日本語もある。
また、日本料理店も高級店からファーストフードまでそろっている。「日式」と書いてあるのが日本（風）のもので、他には韓式、泰式（タイ）、義式（イタリア）などがあった。

日本語は様々な商品に使われているが、学習者が多いとはいえ、大半の人が理解できる言語ではない。日本でほとんどの人が理解できないフランス語が高級感を出すために使われているのと同じようなものなのかとも思ったが、実際にどのように受け止められているのかはわからない。

郊外

台北の人口は270万人程度で、郊外の新北市を含めるとさらに増えるが、東京（圏）などと比べるとかなり少ない。そのためか、中心部を少し離れれば森や畑が広がっている。中心部から10kmも離れていない故宮博物院があるあたりも周りは緑に囲まれている。電車、バス、ロープウェイなどで1時間程度かければ温泉街や茶畑があるエリアに行くことができた。

原住民

台湾の人口のうち約2%が原住民族（日本では「先住民」という表現が一般的だが、ここでは台湾で一般的に使われている言葉を使う）であるとされている。近年では（カナダやオーストラリアなどと同様で、様々な問題はあるが）原住民の権利を尊重する方向で、原住民の生活を展示する博物館があったり、 原住民が多い地域では標識に原住民の言語（おそらく）が使われていたりする。今回タイヤル族が多く住む烏来という町に行った。そこにある博物館は台風のため閉まっており、結局見られなかった。

烏来で原住民が経営し、原住民の料理を出すレストランに入った。「文化」（の一部）を商品化することで、市場経済の中で生活しようとしているというのは他の場所でもあることである。元の文脈からは切り離されることになるが、それ以外に方法はない、ということだろう。一方の自分自身も商品化された文化を消費するということに多少ためらいはあるが、これ以外の接触の仕方を想像できない。

少し話を聞いたところ、その土地に住むタイヤル族で、観光業（レストランに限る?）に関わっているのは自分たちだけだという話だった。それ以外の人がどのような生活をしているのかは聞いていない。料理は竹筒を使うなど素朴な面を残しながらも、味は中華料理に近い。長い間の漢民族との接触によって影響を受けたのだろうか。
なお、タイヤル族を含め、原住民の中には第二次世界大戦で旧日本軍の軍属として戦った人もおり、今に至るまで引きずっている問題もある。（観光客として訪れただけなので、特にそうした話はしていない。）

台風

ちょうど旅行中に台風が接近していた。烏来にいたときに最接近しており、近くを川が流れているため警戒が必要で一部の橋は閉鎖されていた。マスコミも取材に来ていたようで、原住民料理店の店主にもインタビューしていた。

帰国

帰りの山手線の中は台湾旅行の広告で埋め尽くされていた。

パソコン修理

ここ半年くらいで2回デスクトップPCを修理した。
パソコンのトラブルで調べていてこの文章を見ることになる人はあまり多くないと思うが、自分のための備忘録も兼ねて書いておく。

1回目は昨年末。しばらく使っていなかったデスクトップPCを使って2, 3か月したころ、ファンの音がうるさくてPCを起動する気にならなくなっていた。もう一つのノートPCも動きが遅いためあまり開く気がしない。仕事柄、休日PCを開かないというのはまずいと思って調べ始めたところ（例えばここ）、いくつか候補が上がる。

ブーンという音からしてファンだろうとは思ったが、クリーニングでは解決しない。（長時間は厳禁だが）障害物を置いてファンを回らないようにしたところ、CPUファンではなくケースファンを回らなくしたところ音がなくなったので、ケースファンを取り替えることに。音が問題なので、Amazonなどで買うのは不安があり、家電量販店に行って実物で音を確かめ、低振動タイプのこちら(S4)の商品を購入。それいらいファンの音で不快になったことはない。

2回目はつい最近。それまでなかったことだったが、PCを起動してしばらく（数分程度）すると突然電源が切れてしまう。偶然かと思ってもう一度起動すると、今度は1分くらいで切れてしまう。今度も前回と同様、初心者向けのページ（こことか）を調べる。他の電気機器は正常に動いているので、電力供給に問題があるとは考えにくく、CPUが疑わしい。ただ、CPUファンにほこりが詰まっている様子はない。

となると、CPUからファンを通して熱が逃げていないという可能性が浮上。1回目の修理のときにおそらくCPUファンも取り外していたと思うが、一度外すとしっかりはめ直すことがなかなかできない。自宅のPCで使われているのは「プッシュピンタイプ」と呼ばれるもののようで、その仕組みも最初よくわからなかったこともあるが、それとともに、CPU側、ファン側双方についていた灰色の物体が気になる。これはCPUグリスで、本来はこれがあるおかげでCPUの熱が逃され、冷却されているのだが、逆に接触が悪くなっている原因になっているようにも見える。暫定対策としてグリスを取り除き、ファンをしっかり固定して起動。突然電源が切れるということはなくなった。

ということで、ほぼ原因は確定。ただ、CPUグリスがない状態ではやはりCPUの温度が上がりやすく、10-20分程度使っていたら70℃近くまで上がっていたので、グリスを買うまで使わないようにする。今回もAmazonで買う気にはならず、他にも調べたいことがあったため再び量販店へ。こちらの商品を購入。

デスクトップPCはUbuntuを使っており、（いくつかの準備をすれば）sensorsコマンドで確かめられる。しばらく（1時間程度）使った後の結果は以下のようなもの。

acpitz-virtual-0
Adapter: Virtual device
temp1:        +30.0°C  (crit = +127.0°C)

coretemp-isa-0000
Adapter: ISA adapter
Core 0:       +31.0°C  (high = +89.0°C, crit = +105.0°C)
Core 2:       +28.0°C  (high = +89.0°C, crit = +105.0°C)

温度が下がっている。問題なさそうだ。もっとも、デスクトップPC自体4,5年前のもので、かなり古い。CPUだけ取り替えるとかできないかと考え、グリスを購入した時に店員さんに聞いたところ、最新のマザーボードとは端子が合わないとのこと。またマザーボード自体同じ規格のものが今はあまり出回ってなさそうということで、買い換えるしかないか…


 

Agile Japan 2016

(日本語は下記を参照)

I attended Agile Japan 2016 on May 31.
I want readers to see the materials of the sessions, many of which are uploaded on
http://www.agilejapan.org/program.html
(though written in Japanese).
I would like to write what I thought, although it may be biased.

What you can do and what you cannot / what you should do and what you shouldn't

If an individual or a team can be anything you want, how to introduce agile development is not a problem. Just "Introduce it" is sufficient. On the other hand, if you cannot change, we do not have any hope.
I took the presentations in Agile Japan as a quest for solution to the problem of what is the entry point of agile development and what kind of agile development is possible as a result.

"The strange path of a new scrum master and a QA guy" is a case in which Mr. Toyoda, the scrum master became a QA (Quality Assurance) and showed a model of a QA in agile development. He did not have experience as a QA and other QA members only had experience in waterfall (WF) process. They learned from each other and communicate with developers and product owners (PO).
As the QA sees software from customers' point of view, they can feedback to PO what they recognize during the process of test analysis and design. They can make an effective test plan if they incorporate developer's viewpoint. While the focus of attention was on the QA, the solution here was to make an agile expert join in the project.

"Break the wall of culture! A genuine DevOps journey that is possible in Japan" was a session with enthusiasm. "Installation of culture" was a keyword here. As an ex-anthropology student, I don't think it is possible to do it easily. It reminded me of Pierre Bourdieu's argument of habitus, its formation through daily activities and reproduction of social hierarchy.
The presenters were fully aware of the difficulty and showed the process to install "culture" focusing on one element of the culture of agile development, "Be lazy". In short, it means how to avoid doing needless things. In the next session, they held a workshop to try value stream mapping (VSM) to eliminate them. VSM shows operation time, lead time (LT) and produced value of processes and its relationship with each other. The point is that we can shorten the LT by locating processes that does not provide values and remove it, and by automating processes if there is a large gap between operation time and the LT.
Review processes were major foci of attention in many teams including mine. Shortening the time from the end of the previous processes to reviews, reducing the repetition of suggestion and fixation, and abolition of review itself (although not always) were what we can do to eliminate wasteful practices. VSM is a method to make what we aren't usually conscious the focus of attention but we cannot make every problem to the fore. Here also an agile coach joins in the team to improve processes (and culture).
From social scientists' or philosophers' eyes, there is infinite information in our daily activities and we select some of them, interpret them and present as "facts". In this sense, VSM itself may depend on expertise of its users and the expertise means how to define stream of events to processes. It may be interesting to see the process further.

Mr. Ushio, one of the presenters of the DevOps session, listed "breaking of 'should'" among elements of agile culture, which derives from Western one. He said it is not good to think that we should do this by that day whatever happens. (Japanese often think that we must do something at any rate. "Breaking of 'should'" is an antithesis of this mindset.)
Presenters of the session "Making agile more agile: Agile mystery analysis makes you find something" also thought that consuming "buffer" days itself is inevitable even if it exceeds the original expectation and what is important is that the management helps teams with less buffers. While agile development usually tries to satisfy deadline and quality by postponing features (functions), in this case the solution was to make other teams help the teams in critical conditions.
The famous "The Mythical Man-Month" suggests that adding work forces to late software projects is not a good solution so I think the scope of this solution is not universal but it seems to work well on the project.

---

5/31(火)に行われたAgile Japan 2016に参加してきた。多くのセッションの資料は
http://www.agilejapan.org/program.html
にアップロードされており、またレポートも出ているので、バイアスはかかっているが思ったことを書いてみる。


私が出席したセッションは以下のとおり（午前中は不参加）。品質や組織、文化に関係したものを中心に回った。
* 「新米スクラムマスタとQAおじさんのアジャイル珍道中」
* 「日本型ハイブリッドアジャイルの導入と実践」
* 「アジャイルをもっとアジャイルに ～ 足りない何かが見つかる、アジャイルミステリー分析 ～ 」
* 「文化の壁をぶち壊せ！日本でも出来る本物の DevOps ジャーニー！」
* 「効果的な自働化を目指す！ Value Stream Mapping 実践ワークショップ」

できること、できないこと/すべきこと、すべきでないこと

もし個人が、あるいはチームが望むような何者にもなることができるのであれば、アジャイル開発の導入が問題になることはない。「導入せよ」の一言で済む。一方変わりようがないのであれば、アジャイルを導入は成功するはずがない。両者の間にあって、何を突破口とすれば、どのようなアジャイルが導入できるか、という問題に対する答えをそれぞれが模索していた、というのが全体を通しての感想である。

最初に聞いた「新米スクラムマスタとQAおじさんのアジャイル珍道中」ではスクラムマスタである豊田氏が自ら（経験がない）QAになってアジャイル開発におけるQAのあり方を示す、という事例である。QAとしては未経験な発表者と、ウォーターフォール(WF)での経験のみがあったQAメンバーが互いから学びながら、開発やプロダクトオーナーとコミュニケーションしていく、という過程を紹介していた。QAは顧客の視点に立てるので、テスト分析、設計の過程で気づいたことをプロダクトオーナー（=要求・仕様）に対してフィードバックできる。また開発視点も取り入れることで効果の高いテストを計画できる。QAに焦点が当たっていたが、ここでの解決策はアジャイルの経験者を外から人を入れるということだった。

「文化の壁をぶち壊せ！日本でも出来る本物の DevOps ジャーニー！」の発表者の一人である牛尾氏はde:codeにも登壇していたようだし、何度かブログも読んだことがあるので全く初めてではなかったが、このセッションは非常にテンションが高かった。ここでは「文化のインストール」がキーになっていた。（1年前に人類学を学んでいた者としても）文化がそんなに簡単に習得できるものとは思えないが、それは承知の上で、アジャイル開発の文化の中でも特に"Be lazy"にフォーカスして、どのように導入するかを紹介していた。簡単に言えば、無駄なこと、必要がないことをいかにやらないかである。そのための手法として次のセッション（牛尾氏は引き続き登壇）ではVSM(Value Stream Mapping)をワークショップ形式で試してみた。VSMは各工程がどれだけの工数、リードタイムでどのような価値を生み出しているかと、工程間のつながりを示したものである。価値がはっきりしないものがあればなくす、工数とリードタイムに大きな差があれば自動化などで差をなくすことでリリースまでのLTを短くできる、というものである。私のチームもそうだったが、レビューに焦点が当たり、前工程終了からレビューまでの時間を減らすことと、指摘事項⇒修正の繰り返しを少なくすること、そして必要ない場合はレビュープロセス自体をなくすこと、などが無駄をなくすためにできることとして挙がった。VSMは普段意識したいないものを意識させるための手法であり、時間が短かったということはあるが、自分たちで考えるだけで問題がすべて明るみに出るわけではない。ここでも導入にあたってはアジャイルコーチが入っている。

DevOpsのセッションで、アジャイル（西洋）の文化として挙げられていたものの中に「"should"の破壊」というものもあり、アジャイル導入にあたっても、いつまでにこれをやらなければならない、と考えて無理をしてはいけない、といういう話だった。「アジャイルをもっとアジャイルに ～ 足りない何かが見つかる、アジャイルミステリー分析 ～」でも想定以上にバッファが消費されること自体は仕方ないと考えていて、それに対してマネジメントが支援する、というやり方だった。アジャイル開発では通常プロジェクトが予定通り進まないとき機能を削ることで納期と品質を守ろうとするが、発表された事例では比較的余裕がある（クリティカルチェーンではない）チームが助けることによってプロジェクト全体として解決する、ということだった。「人月の神話」の話を聞く限り、この方法が常に適用できるのかは疑問だが、発表事例ではうまく機能した、ということだろう。

（以下は英語版にはまだ書いていない部分）
一方、「日本型ハイブリッドアジャイルの導入と実践」は現実路線。SIを中心とする、日本のソフトウェアの産業構造を前提として、その中でアジャイルの要素をどのように取り込んでいくかという話。最初の要求・仕様の部分と最後のテストについては（ある程度の柔軟性を持たせながらも）基本的にWFにして、中間の設計・実装の部分をアジャイルにしてイテレーションを繰り返す、という方向性を示していた。この方法のメリットとして、契約内容を大きく変更せずに済むこと、スキルが高くない開発者でも開発できることを挙げていたが、正直この考え方にはあまり賛成できない。確かに、航空・宇宙や自動車など高い信頼性を要するソフトウェアでは多少利便性を犠牲にしても仕様変更を少なくして安全性を高めるという方向はありだと思うが、それ以外では既存のSIerの仕事を守るだけの後ろ向きのやり方にしか思えない。海外のエンジニアは情報工学を学んでいて優秀だと話していたが、日本のエンジニアが人件費が高くスキルが低いとしたら、それでも仕事になっているのは日本語の壁があるからだけである。（自分自身への警告も含めだが）個人として、また業界としてアジャイルに適応するか、あるいはアジャイルでは実現できないメリットを出せるかを考え、それができないのであれば別の業界に移るより仕方ないのではないかと思った。

何のために働くか

「新米スクラムマスタとQAおじさんのアジャイル珍道中」ではチーム内の、「アジャイルをもっとアジャイルに ～ 足りない何かが見つかる、アジャイルミステリー分析 ～」ではチームを超えた協力関係を築くことが成功のかぎとして挙げられていた。ここではチームメンバーは、またチーム同士は協力し合うべきであり、また（条件さえそろえば）自然と協力するようになるものである、という考えに立っているように思える。「文化の壁」の資料でも、日本は基本的にアジャイル導入が難しいが、「個人の自立」に関してだけは（個人主義が弱いため）アジャイルが導入しやすい、ということになっている。「アジャイルミステリー分析」では納期に間に合いそうもないとシグナルを出せば助けてくれるという仕組みを作った、と話していた。そうしたら怠けようとする人もいるのではないかとも思ったが、そうした懸念については触れず、むしろチームが困ったときに助けてくれたら、次に他のチームが困ったときに助けたくなる、ということだった。

一方、VSMのセッションではどうやって関係者を説得するかという問題も質問に挙がっていて、その人の価値観に合わせて「プロジェクト成功で昇進できる」「夕方5時には帰れる」などメリットを説くと答えていた。こうした相手の個人的な利益に訴えることはアジャイルやDevOpsを推進する上で障害になるとは考えていないようだ。実際海外のアジャイル開発では「楽しむ」ことが重視されているようで、「納期もそれほど気にしない」とのことだった。先に楽しむことがあって、そうすれば後から協力や規律はついてくる、ということだろうか。今回関連した話は聞かなかったが、プロジェクトが回る仕組みを作る際にインセンティブの問題も含め、マネジメント、人事・評価、「文化」、技術、個々のエンジニアのスキル、その他各方面の問題に対処しなければならないとなるとさらに対応が難しくなるのではないかと思った。

その他

「Be lazy」はともかく、アジャイル開発の「楽しむ」ことやチーム全体のアプローチが、成果主義や厳しい競争など、海外（特に米国）について聞く、少なくとも一見相容れないような側面とどのように組み合わされているのかはよくわからなかった。

Jenkins

（日本語は下を参照。）

I am now using Jenkins for the first time in a few years.

Jenkins is a CI (Continuous integration) tool well known among engineers.

When I started to use Jenkins again, I feel like thinking about what is required if I have to make a tool like Jenkins. Automated testing of various levels including unit and acceptance testing, acquisition of metrics of source code, generation of product such as executable files are what we want to do after commit to repository.

CI means automation of a series of works like them. For that purpose, the system have to call version control system, testing automation tool, metrics tools, build tools, and so on. However, depending on projects, programming languages as well as tools for various operations differ. So it is necessary to provide interface in which various tools are called and results are retrieved. Thus "separation of interface and implementation" is realized.

While setting corresponds to code base, results are generated for each build. What is needed is to obtain results of each operations in each build and display them so that users can understand easily, probably by visualization. We want to see history as well as result of each build for tests and metrics, for example.

In addition, it is necessary to manage plugins, machines and users.

As I see the actual system (of Jenkins), although I cannot understand details, my idea is not wrong as a whole. Jenkins is, in good sense, a simple system I can understand the underlying idea easily.

I want to think about the system our company develops in the same vain, but it seems to be more difficult than thinking about Jenkins.


最近何年かぶりにJenkinsを使うことになった。（Jenkinsはエンジニアの間ではよく知られたCIツールである。）

そのときなぜか自分でJenkinsのようなツールを作るとしたら何が必要か、考えてみたくなった。 リポジトリにコミットが入った後、通常行いたいこととしては、単体から受け入れまで各レベルでの自動テスト、ソースコードのメトリクス取得、成果物（実行ファイルなど）の作成などがある。

これら一連の作業を自動化するのがCIであり、そのためにはバージョン管理システム、自動テストツール、メトリクス測定ツール、ビルドツールなどを呼び出すことが必要である。とはいえ、プロジェクトによって開発言語も異なれば、各種の作業に使用するツールも異なる。だからインターフェースだけ用意しておいて様々なツールを呼び出し、結果を取得できるようにしておく。かくして「インターフェースと実装の分離」が実現される。

設定はコードベースに対応するのに対し、結果の方はビルドごとにデータが作成される。必要なのは各実行ごとに各作業の結果を取得し、わかりやすく表示してくれること。テストやメトリクスなどは今回の結果だけでなくこれまでの推移も見られるようにしたい。

あとはプラグインやマシン、ユーザなどの管理。

そんなことを考えてJenkinsを眺めてみたら、細かいところは知らない単語もいろいろ出てくるものの、大枠では外れてはいないようだ。 Jenkinsは（よい意味で）わかりやすいシステムである。

自社で開発しているシステムについて同じようなことを考えてみたいが、Jenkinsほど簡単ではなさそうだ。