Greedy algorithmと2割8割の法則 - Software Processes are Software, Too -

プロセスプログラミングを提唱したオスターワイル(Leon J. Osterweil)氏のことば
　“Software Processes are Software, Too”
　(ソフトウェアプロセスもソフトウェアである)
をヒントに、開発とマネージメントの共通点として、今回は「Greedy algorith」と「2割8割の法則」を考えてみます。開発者からマネージメントをするようになった方には経験を生かした管理を、管理をされている方には技術的な裏付けを知る機会になれば幸いです。

greedy algorithm

世の中には簡単な問題と難しい問題があり、例えば並べ替えするときに単純に2重ループするとデータ数Nが増えるとその2乗（N^2）ほど時間がかかりますが、処理を工夫して木構造にデータを並べておけばその木の高さ（logN）で処理が済みます（実装者のための計算量のはなし - O(logN)などをわかり易く説明しました -）。

これに対してナップザックにいろいろな大きさの荷物を入れるような問題は、NP困難と呼ばれる難しい問題です。すべての組み合わせを確認しないと隙間を最も少なくできないからです。そこで Greedy algorithmという手法がとられます。これは隙間の少ない（価値のある）大きなものから貪欲に詰めていく方法です。最適ではないですが、ほどほどにうまく詰める方法です。

プロジェクト管理においても最適な計画を立てることは簡単ではありません。そこで、大事な作業や後回しにすると問題になる作業から実行あるいは計画すると、ほどほどに良い計画を作ることができます。アジャイル開発のやり方はまさにこのような方法です。計画駆動な開発ならこの方法でできた計画をたたき台に、より最適な計画を作成することができるでしょう。

＃初期のスクラムガイドは優先順序だけで実行時順序を決めていたので、リスクの考慮が乏しいものでしたが、その後見直されたようですね。

閑話休題。プロジェクトの実行や計画には様々な要素があって簡単ではありません。まずはどの作業が価値があるか、すなわち重要あるいは後回しにできないかをまずは見極めてそれに基づいて計画しましょう。

もちろん、そもそものソフト性能にも利用できます。ソフトウェアの処理データが増えることで処理が遅くなるような場合に、網羅的で単純な繰り返し処理になっていないか、調査してみてください。

2割8割の法則

網羅的に実施しない場合に重要なものから実施するとどのような効果があるのでしょう。2割8割の法則はパレートの法則とも呼ばれ、度数順に要素を並べるパレート図を描くと、一般に上位2割が8割を占めているという法則です。

この法則に基づくと、アプリケーションの価値のある2割の機能を実現するだけで8割の価値があり、残りの8割の機能はあまり価値がないということになります。アジャイル開発では価値のあるものから開発し、随時リリースすることで価値の少ない8割の開発よりもリリース後の外界の変化に対応することを選んでいると考えられます。

2割8割の法則は障害の対応や改善において用いられています。分析して障害の量や質が問題になる上位2割の障害対策を行えば、より効果が得られるでしょう。

プロジェクトを進化させる

プロジェクトは日々変化します。プロジェクトもそのままではうまくいかず、常に変え続けないといけません。ソフトウェア開発ではリソースが潤沢ではない場合が多いので、孫氏の兵法に示されるようにパワーを分散せずにポイントを絞って攻めるとうまくいくでしょう。

グリーディアルゴリズムや2割8割の法則も同じようにポイントを絞る方法で、大事なことを見極め、優先順位をつけるという特徴があります。これらを生かせば、プロジェクトを変え続けてより効果的に進化させることができるでしょう。

参考：
（[#agileto2012] 『チェンジ！』の考え方 ～マネしやんと！～）

論理的に考え伝える – SEA関西「開発現場で役立つ論文の書き方のお話」 -

論理的ということは論理的な構造を持つということで、人に伝えるということは物事を論理的に整理して、伝わる構造あてはめるということだ。ソフトウェア開発現場において、伝わらない事で生じるトラブルは少なくない。それは説明の順序であったり、端的に表現できないからだったりする。私が社内外で論文の書き方を説明しているのは、論文にはトラブルを未然に防ぐ「論理的に考え伝える」構造が含まれているからである。
論理的な構造に整理する方法は数多くあり階層的に表現するものから、目的に応じて記法を変えるTOCｆE http://sakaba.cocolog-nifty.com/sakaba/toctocfe/index.html のようなものもある。しかし、ソフトウェアと同じように大きな情報を扱うには、構造化プログラミングのように1種類の構造だけでなく、クラスや関数のようにある程度の塊でさらに構造を持つ必要がある。論文においては論理的な構造を実現する方法として、パラグラフライティングが用いられる。
パラグラフライティングは「各まとまりの先頭には最も重要な文を置き， それ以後にはその文の補足説明のための文を置く」（パラグラフライティングの作法 -書き手にもメリットのある文配置ルール-）というもので、主に要旨＋詳細で段落（パラグラフ）を構成する。YES/NOをはっきりさせる英語文化を感じさせる構造である（日本の小学校では起承転結が教えられるが、これでは最後まで聞かないと結論がわからない。いかにも日本語的だ）。
パラグラフライティングの良いところは、初めに伝えたいことの方向性を示しているので、内容をミスリードしないことだ。パラグラフライティングで書かれた文章は、要旨がなくても各段落の1行目だけを読むことで概要を把握することができる。逆に文章を書くときは、各段落に書くべきことを1行ずつ書いておいて、それを膨らませば良い。
初めに伝えたいことの方向性を示というのはミスリードを防ぐ良い方法で、これは開発現場でも大いに役立つものなので、今回の講演（第74回 SEA関西プロセス分科会 「開発現場で役立つ論文の書き方のお話」）をおこなった。論文で採用されているIMRADという技術文書の構造がこのような構造を持つだけでなく、わかりやすい論文は各章の段落もこのような構造を持っており、論文の書き方を説明することで、開発現場でも役立つと考えたからだ。

追記： 今回の分科会はソフトウェアシンポジウムの投稿者を増やす目的で開催されました。

改訂版：開発現場で役立つ論文の書き方のお話 from Makoto SAKAI

Tweet

論文研修会（導入編）- 論理的思考のすすめ -

この記事は SRA Advent Calendar 2019 2日目の記事です。

私の所属する関西事業部では、社内研修会というものを実施しています。個人的には、勉強会のようなものはオープンに行う方が、新しい技術を身につけられてよいし、社内を知ることができると思っています（社内勉強会より社外の勉強会）。しかし、社内でないと話しにくい内容もあるもので、今回行う論文の書き方などがそれで、論文と言いながら事例報告の概要を書くのですが、外に出せるネタがあるとは限らないので、社員だけが知ることのできる事例をもとに書き方を学び、それを通じて論理的思考を学ぶ。なんていうのは社内だからできることです。

論文というのは技術情報を伝達する方法の一つです。古くからソフトウェア開発では「コミュニケーション」が問題とされることが多くありました。しかし、この「コミュニケーション」には2つの側面があって、一つは情報伝達、もう一つが人間関係に起因する協力的な関係が気づけるかどうかだと思います。

このうち情報伝達のトラブルは、論理的思考力を身に着けることで大きく改善します。スライド中にある

• いつのまにか話が長くなって 打ち合わせがなかなか終らない。
• お客様や上司に理解してもらえず 意見が通らない。
• 話を直接聞いているのに勘違いする。

などは、論文作成を通じて論理的思考力が身についていれば、多くの混乱を避けることができるでし
ょう。

論理的思考力を身に着けるための論文研修 from Makoto SAKAI

参加者は社外発表をきたされている人や、昇格に向けて一皮むけてほしい人たちでした。内容はそれなりに伝わったようで、納得したり、耳が痛かったりしたようです。

スライドの説明のあと、以前日科技連でお話しした論文の書き方を説明しました（9日目の記事に続く）。

Tweet

スクリプト言語入門 - シェル芸のすすめ - 第2回クラウド勉強会

かつて「社内勉強会より社外の勉強会」という記事を書きました。この中にも書いているように社内勉強会にも利点があります。

社外ではあまり受けられない内容を、実際の業務経験を踏まえつつ、必要なメンバーに説明するには社内勉強会も良い方法だと思います。

今回はbashを中心にスクリプト言語の基本を説明しました。

スクリプト言語入門20190125 from Makoto SAKAI

デブサミ関西でNode-REDとペンギンと勇気の話をしました #devsumiB

Developers Summit 2018 KANSAI（以下デブサミ関西）で発表してきました。

Node-REDを使って約3年、こんなに手になじむ感覚は、Rubyを初めて使った時以来でした。Node-REDは実装の生産性が高く、仕組みを考えて早めに作って確認するという繰り返しで開発ができます。難しいシステムの開発も、全体のデータ構造やアーキテクチャなどの難しい部分に注力できます。

今年のデブサミ関西には公募枠で事例を募集していましたので、お気に入りのNode-REDを広めるべく、ダメ元で応募しました。応募する際にはデブサミなのでかっこよくしないといけないと思って、社内のNode-RED経験者のアンケートを元にキャチーなキーワードで概要をまとめました。しかし、発表に向けてスライドを作る中で本音や伝えたいことが増えたので、書き足しました。

新技術で未来の扉を開け！ - Node-REDの環境構築と社内導入 - from Makoto SAKAI

そもそもの始まりはお客様からの依頼でした。自分たちの仕事を減らすかもしれない開発に対して、それまでの仕事に対する「お客様と同じ方向を見る」（アジャイル開発）、「適切な費用をもらう」（オープンソース）、「よい技術を取り入れる」（技術志向）という3つの考え方で積極的に協力しました。Node-REDは思った通りに実装できて、生産性はとても高かったです。

そんな概要を書いていましたが、よくよく考えると、お客様にそう言わせるほど生産性の高いNode-REDとはどんなものだろうと、不安よりも技術的な興味が先立っていました。未知の分野ではありましたが準委任契約ということもあって、ほんの少しの勇気で新しい世界に飛び込みました。

「ファーストペンギン」という言葉があります。怖がりのペンギンは仲間と寄り添うばかりで、なかなか海に飛び込みません。そのようなペンギンの中で最初に海に飛び込むペンギンは勇気のあるペンギンとして称賛されます。

ソフトウェアの世界でも新しい世界に飛び込むには勇気が必要です。未来に広がるブルーオーシャンを手に入れるには、怖がらずに飛び込むことが必要です。

しかし、勇気とは無謀な行いや蛮勇ではありません。ソクラテスは、 勇気とは、 「恐るべきものと恐るべからざるものとを 識別することなり」と言っています。我々の場合は準委任契約という強みがありました。今は書籍やユーザーグループなど、当時と比べてNode-REDの情報は豊富になり、議論や相談ができる仲間がいます。ぜひ皆さんも情報を得て勇気をもってください。

11/24(土) にソフトウェア技術者協会関西支部で「 Nodeから手が出るNode-RED(初心者向け) 」と題するハンズオンがエルおおさか (大阪府立労働センター) を開催します。
まだ募集が始まっていませんが、興味のある方はコンパスのメンバーになるか私のTwitterをフォローしてください。

標準は諸刃の剣

標準と聞くと仕事を楽にするもの、組織に必要なもの、 あるいは、 面倒臭いもの、 厳しいもの、と考える方がおられるかも知れません。これはどちらも真っ当な意見で、標準には良い面があるものの、悪い面もあります。

標準の効果

ここで参考になるのはプロセスモデリングのゴールでしょう（[#TiDD]失敗しないチケット駆動開発 - プロセスモデリングの視点から+告知 -）。標準を理解し、共通の行動を前提に改善し、必要な作業が行われているか管理し、ツールによる自動化やガイドできます。

つまり開発者を支援して、一定のレベルへの底上げや組織的な改善が可能になります。

思考停止の罠

組織活動に便利な標準ですが、思考停止に陥りがちです。厳しく管理することで標準に従うことに集中してしまい、より良いものを追求しなくなってしまいます。また、柔軟な開発ができなくなるので、 開発の負担になって生産性が低下してしまうこともあるでしょう。

より難しい問題は、技術者の成長を止めてしまうことです。実際に大規模開発でうまくやっていた人が、小規模で比較的自由な開発でプロジェクトをうまく管理できないこともあります。なぜその標準が必要なのかをキチンと理解していなかったのでしょう。

良い標準

このような問題が生じにくい標準を考えてみます。標準で全てを縛るのではなく、その重要度によって規則、推奨、参考情報に分けると良いでしょう。単純な共通化ではなく、判断条件と共に複数の選択肢を示します。

良い標準は学びになります。その標準がなぜ良いか、どのような条件で有効か、その理由が説明されているなら、標準に振り回されること無く、自ら判断して実施できるでしょう。

標準を活かすには

どんなに良い標準でも、言われるままに実施しているのでは仕事をこなしているだけです。確認が可能なら、きちんと原本を読んでください。思わぬ発見があるかも知れません。

標準はそれぞれの組織や業務に応じて決められたものですので、定められた制約を守らないといけません。反面、制約を守っていればそこに工夫の余地があります。ソフトウェア開発と同じです。

（参考）詳細設計書を後回しにした話：Win-Winプロセス(ウォータフォール編)

決定をできるだけ遅らせる -「現場で役立つシステム設計の原則」深読み -

増田さんの「現場で役立つシステム設計の原則」に関して様々な議論があり、私も立食とコース料理 -「現場で役立つシステム設計の原則」批判の一考察 -を書いたあと、様々な議論をさせていただきました。私なりの本の読み方が見えてきたのでまとめておきます。

この本はアジャイル開発（以下アジャイル）がベースになっていると思います。特にリーンソフトウェア開発のプラクティスである「 決定をできるだけ遅らせる」（リーンを考える - 無駄と必要なアソビ -） の考え方が透けて見えます。

この考え方は上流工程をもつ従来の開発方法（ウォーターフォールと呼ぶとリリースが１回とか工程間で判定会議がいるとされることもあるのでこう表現します、以下、従来法）とは大きく異なる考え方です。

従来法の考え方

従来法で上流が重視されます。これは、ベーム先生の後工程になると修正工数が指数的に増えると発表されたからです（「要求は変化する。Boehm は間違っていた、と DeMarco が暴いた。」というYourdon のブログ：An Agile Way：オルタナティブ・ブログ）。後工程になれば修正が大変だからと上流工程で頑張ることで、開発のリスクを減らそうとした訳です。

話はそれますが、ベーム先生はその後の繰り返し開発やアジャイル開発につながるスパイラルモデル（リンク先はWikipedia）を提唱されたり、後述の「アジャイルと規律」を執筆されるなどアジャイル開発に貢献もされています。IEEE Softwareの紙面でケント・ベックさんとXPについて議論されていたので、からかわれたのじゃないでしょうか。

決定をできるだけ遅らせる

話を戻して「決定をできるだけ遅らせる」というのはYAGNI(You aren't gonna need it)に通じる考え方です。従来法とは逆に、変更の可能性を考慮して、どうしても決めないといけない時（最終責任時点）まで決定遅らせるというプラクティスです。

例えば車のドアのところのデザインがかわる可能性がある場合、ドア部分の金型を削ってしまわずに少し残しておくといった対処で、後から変更が生じた際に調整できるように決定を遅らせるというプラクティスです。すべての事を決定しておかずに余裕を持たす事で、選択肢を残せます。

従来法のソフトウェア開発に置いても、決めきれない内容はペンディング、TBD、TODOなどといって後回しにしたり、手軽な方式に仮決めしておきますよね。それを時間切れだからとあきらめてするのではなく、変更の可能性を意識して選択肢を残す目的で実施するようなイメージです。こうすることで多大な手戻りのリスクを減らします。

「現場で役立つシステム設計の原則」の深読み

このような視点で読むと、仮決めする際のデフォルトが示されているように思います。オブジェクト指向はこう理解して、こう言う風に考えるとうまくいく、短いイテレーションも乗り切れるよ。という風に読めてきます。

上記は私の勝手な忖度ですが、増田さんの講演資料にある批判に対する回答を読むと、増田さん自身も決定を遅らせる考え方をもたれていることがわかります（現場で役立つシステム設計の原則）。

この５ページの「すべてのカラムが Not Null は非現実的？」に対して「実際にやっている、特に困っていない、SQL のスキル＋ IDE サポート」という回答からも、決定を遅らせるスタンスが感じられます。

批判を考える

このように考えた上で、この本に対して書かれている批判を考えると、とても良い指摘ではあるものの、「決定をできるだけ遅らせる」こととと対極にある「はじめのうちからしっかり作る」ことを勧められている様に思います。

もちろんリスクを減らす目的で決定をできるだけ遅らせているのであり、「はじめのうちからしっかり作る/設計する」方がリスクが減るのであれば、実施すべきでしょう。

kent4989さんのブログ勘と経験と読経でその方法が紹介されていました（アジャイルとデータモデル、DB進化設計のこと）。アジャイルにこだわるならイテレーションゼロで吸収する。それ以外なら前段階で供給開発、あるいは、RUPなどの反復開発手法の併用を勧められています。最近ではたなかこういちさんが、アジャイルでスタートアップも、軌道に乗ったらUPへ移行すべきときが来る、というものかもしれないと言われています。

2017/9/8追記：
アジャイルにこだわる方法としてFDD(リンク先はWikipedia)もあります。
（[#Agile] FDDはアジャイル開発、ハイブリッドアジャイルは、、
[#TiDD] 手分けするより助け合い - FDDとチケット駆動開発 - ）

2017/9/14追記：
この本の特徴の一つは決定を遅らせる際のシンプルなデフォルトを示していることです。イテレーション（スプリント）をうまく回せるか不安だった方や、ベロシティ（開発速度）が上がらなくて困っていた方には、大いに参考になるでしょう。

その方法は独特です。批判の多くは一般的な方法を主張し、その良さを指摘したものです。批判の実践はこの本に書かれたシンプルさを損ないますので、どちらを優先すべきか良く判断すべきだと思います。

もし、批判を読んで今までの開発が不十分で問題だったと思われるなら、批判は一部だけを示したものですので、より広く検討して上述の実施方法などを検討する必要があるでしょう。

アジャイルにこだわるかの判断

批判を別にしてもアジャイルにこだわるべきかどうかは考えておく必要があります。平鍋さんのブログデータモデリングなきアジャイル開発は危ういか？では、プロジェクトや製品の文脈によって変わるとされていますし、上述のたなかこういちさんのブログでも「バックオフィス側の管理業務」など業務が大きな要素であることは間違いないと思います。

一方、ベーム先生の「アジャイルと規律」ではアジャイルの５つの重要要因として、規模、重要度、 変化の度合いといった業務に関わる要員のほか、人、文化が挙げられています。

人に依る違い

設計に関して渡辺さんが「システム設計と創造性」の中で“まずは「システムが扱う現実の全体をぼやーっと理解する」ことを目指せばよい”とされていて、私もそうしています。

しかし、ふと思い出すと小学生のことです。私は作文の時間の半分以上をあーでもない、こーでもないと書く内容を考えていました。成績は悪くはなかったのですが、私よりもできる人の中には、作文の時間にすぐに書き出す人もいました。設計でも同じ様に人によって作りながらの方がうまくいく人がいるかも知れません。

そう思うと、書籍アジャイルサムライに

誰もがこの働き方を気に入るわけじゃない

— アジャイルサムライbot (@agile_s_jp_bot) 2017年10月2日

と書かれていたことが設計にも言えるのではないかと思います。

おわりに

増田さんの本に関しては、上記のような視点でとても興味深く読ませていただきました。できれば、続編あるいは改訂版のような形で、アジャイルとリファクタリングによる進化のさせ方について、もっと書いていただければと思っています。

なお、個人的なアジャイル開発に関する考えは、[#Agile] アジャイル開発の課題と対策 その1に書いています。現場でスクラムやXPの様なタイムボックス型管理をしているアジャイル開発はしていませんが、いわゆるモダンアジャイルを実践しているつもりです。

2017/9/8追記：

決定を遅らせるってのは、ファウラーはアーキテクチャの中心的な役割としている。アジャイルだからというより、OOにおけるソフトウェア設計ってそういうものなのでは？という理解。https://t.co/uJnLvoJUwK

— 松下正嗣 (@masatsugumatsus) 2017年10月7日

アジャイルマニュフェストはオブジェクト指向の有名人が集まって決めたので、なるほどと思いました、サブタイトルからもオブジェクト指向からの説明の方がしっくりくるかも知れません（私には書けませんが）。

これに関連して「アジャイルプロセスでは、本質的なデザインやアーキテクチャに関する意思決定をできるだけ遅らせることができます。」というマーチン・ファウラー氏の言葉を見つけてニワトリとタマゴの関係だと思いました。

[#Node-RED] ７〜８分でわかるファンクションノード

Visual IoTツール Node-REDには、データセットや基本的な制御構造がありますので、簡単なプログラムならコーディングなし（設定だけ）でプログラムを書くことができます。

しかし、少し複雑な処理になるとファンクションノードが便利です。ファンクションノードはjavascriptでコーディングできますので、複雑な処理をフローにまとめることができ、シンプルなわかり易いフローが書けます。

１．基本

まずは基本的な内容から。

1.1 名前をつけよう

ノードには日本語で名前を付けることができます。処理内容を表す名前を付けておくとフローが読み易くなります。「XXに変換する」「msg.cnt++」などわかり易い名前を付けてください。

1.2 入力は最大一つ、出力は複数可能

ファンクションノードの入り口は一つだけです。デフォルトの出力は一つですが、下部にある出力数を変更して増やすことができます。出力が複数場合は戻り値を配列で返します。出力しない出口にはnullをセットします。条件によってどれか一つに値を出力するだけなら、スイッチノードに渡した方が、修正が楽な場合もあるでしょう。
（追記：バージョン0.17以降では端子に名前をつけるとマウスオーバーで表示できますので、入出力などをわかり易く書いておくと良いでしょう。）

1.3 javascriptでコーディング

内蔵エディタはjavascript構文を理解してエラーやワーニングを表示してくれます。Node-REDが動作するNode.jsのバージョンの文法で記述します。msgオブジェクトを受け取って処理し、リターンバリューがmsgオブジェクトになります。

２．あらかじめ定義されたオブジェクト

msgオブジェクト以外のあらかじめ定義されたオブジェクトを説明します。

2.1 グローバルオブジェクト

プログラム全体で利用可能なグローバル変数が使えます。
global.get(‘オブジェクト名’)で取得し、 global.set(‘オブジェクト名’,値)で値を設定します。現在は永続化されないので、再起動で初期化されます。

2.2 フローオブジェクト

タブ内で有効なフロー変数もあります。
flow.get(‘オブジェクト名’)で取得し、flow.set(‘オブジェクト名’)で値を設定します。
永続化されないので、再起動で初期化されます。

2.3 node.send()

一つの出口に複数返す場合や、無名関数内で終了する場合は、returnでなく、 node.send(msgオブジェクト)を用います。returnは最後の一度死活変えませんし、無名関数内のreturnは全体の戻りではないからです。

2.4 require は setting.js で

ファンクションノード内で requireできません。requireが必要な場合は、ユーザーディレクトリ（ ホームディレクトリ/.node-red）のsetting.jsのfunctionGlobalContextにrequireを追加します。Node-REDを再起動すると、設定したオブジェクトを global.get(‘オブジェクト名’) で取得できます。もちろん、必要に応じてユーザーディレクトリで、モジュールをnpmインストールする必要があります。

３．オブジェクトの管理

簡単に見えるNode-REDプログラミングですが、意外とハマるのがオブジェクトの管理です。

3.1 msg.payloadは基本

標準的な出力はmsg.payloadですが、破壊されることも多いです。payload以外のプロパティを使えば多くの場合は大丈夫です。しかし、新しいmsgオブジェクトが生成される場合は、フロー変数やグローバル変数を使います。

3.2 新しいmsgオブジェクトで返す

受け取ったmsgオブジェクトを渡したくない場合は、「return {payload: 値};」とすると新しいオブジェクトのmsg.payloadとして値を返すことができます。ただし、後続の処理で、受け取ったmsgオブジェクトの値を渡せないので注意してください。特にhttp inが出力するmsgオブジェクトには、http responseに必要な情報が含まれますので注意してください。

3.3 コピーされるオブジェクト

「return [msg, msg];」のようにmsgオブジェクトを複数同時に返すと、オブジェクトッがコピーされ、異なるオブジェクトが渡されます。また、一つの出口から複数のノードに繋いだ場合もコピーされます。大量データを扱う場合には注意してください。新しいmsgオブジェクトを生成するか、node.send()で出力すると参照が渡されます（参照を渡すと想定外に内容が破壊されてしまうことがありますので注意してください）。

４．おわりに

簡単に始められるNode-REDプログラミングですが、ドキュメントをきちんと読んだり、色々試さないとわからないことがあります。ここに挙げた内容がわかっていれば、少し複雑な処理もスラスラと書けると思います。

詳しくは、公式ドキュメント（英語）の確認や、実際に動かすなどしてください。それでも困った時は、ユーザー会、slackやメーリングリストなど（英語）で聞いてみると良いと思います。

アジャイルジャパン大阪サテライト2017の感想

SS2017のポストイベントがなくなったので、 急遽スタッフとして参加しました。

（１）キーノート：シンアジャイル（Joshua Kerievsky）

モダンアジャイルについての説明。タイトルはAgileJapan2017のタイトルにあわせて変更されたようです（シン・ゴジラをまねた？）。

個人的にアジャイル開発のタイムボックス管理は、作業タイミングを固定化するので超短期開発にはフィットしないと思っていました。Kerievsky氏は早くからタイムボックスを守るよりも顧客のメリットを考えようと言われていたそうです（そのとおり！）。

提案する新しい4つの原則は従来のアジャイルマニュフェストに対応しながらも、顧客やソフトウェアの安全性に配慮したものでした。

講演概要
http://www.agilejapan.org/session.html#session01

Agile 2016の基調講演: モダンアジャイル
https://www.infoq.com/jp/news/2016/08/agile2016-modern-agile

チェンジビジョン/英和システム 平鍋さんの説明
https://anagileway.wordpress.com/2016/10/07/modern-agile-jp/

（２）ヴァル研究所 新井さんの講演

アジャイルを社内に広げる際の話。みんなが積極的になるように色々と工夫された中で、権限(部長)があるので、一部の活動が社内評価と連動するようにした。と言われていたので懇親会で質問させていただきました。

質問は、社内の仕組みと連動すると、義務感ややらされ感が出ると思うが、どのようにバランスをとられているか？

答えは、社員には積極的なできる人と、受身の人と両方いて受身の人も働いてもらわないといけない。ルールを決めても相手によって変えている。とのこと。

つまり、ルールはがちがちにせず、運用時に人を見て、たぶんチームによっても変えているのでしょう。エンジニアは、ついつい一貫性が気になりますが、個人個人を良く見ると言うことが重要だと思いました。

ちなみに、「上から見てなので、みんながどう思っているかはわからないですけどね。」と謙虚に言われていたのが印象的でした。

（３）コニカミノルタの久保さんによるエモイ話

「楽しさ」に導かれたアジャイル開発　～老舗メーカーでの実践～ from Akira Kubo

人はなぜ生きているのか？それは人生を楽しむためである。

なぜ苦しみがあるのか？それは、いつかより人生を楽しめるからである。

いい人である必要は無い。人の顔色ばかり見る必要は無い。わかってあげるだけでいい。

そう、生きているだけで素晴らしい。

そう思いました。

Node-REDから見えた未来 － 変わるもの、変わらないもの － SS2017 WG13

ソフトウェアシンポジウム(SS2017)では、前回紹介した論文発表のほか、ワーキンググループにも参加しました。

ワーキンググループでは各グループのテーマに沿って、参加者がそれぞれのポジションを発表して議論します。私が参加したのはWG13「ソフトウェア開発の現状と今後の発展に向けたディスカッション」で「Node-REDから見えた未来 - 変わるもの、変わらないもの -」を発表しました。

Node-REDから見えた未来 - 変わるもの、変わらないもの - from Makoto SAKAI

Node-REDは高機能なノード（モジュール）がたくさんあり、それらを組み合わせて高機能なシステムを効率的に開発できます。また、簡単にデバッグできるほか、デプロイが一瞬で、開発から確認の繰り返しを素早く実行できます。

このような環境を使っていると、面倒臭いことがなくなり、ソフトウェア開発に重要な作業を中心に実施する様になります。この重要なことはみなさん合意できますよね。という発表でした。

しかし、Node-REDのデモのインパクトが大きかったのか、Node-REDに対する質問で持ち時間が終わってしまいました。Node-REDを知ってもらえたので、良かったことにしておきます。