One fact in one placeとチケット駆動開発 - Software Processes are Software, Too -

プロセスプログラミングを提唱したオスターワイル(Leon J. Osterweil)氏のことば

　　“Software Processes are Software, Too”
　(ソフトウェアプロセスもソフトウェアである)

をヒントに、開発とマネージメントの共通点として、今回は「One fact in one place」と「チケット駆動開発」を考えてみます。開発者からマネージメントをするようになった方には経験を生かした管理を、管理をされている方には技術的な裏付けを知る機会になれば幸いです。

One fact in one place

データベースの正規化で使われる言葉です。ほかのデータから算出できる推移従属のデータを除いて、データを1か所に限定することです。同じデータは1か所にしかないので、常に一貫性のあるデータ集合を求められるようにします。他のテーブルと関連付ける場合もデータベースの機能を使えば、矛盾の生じない構造を実現しつつ多くの情報を管理することができます。

チケット駆動開発

チケットで障害やタスクを管理するRedmineやTracなどを用いて、情報共有しつつ開発を進めていく方法です。これらのツールはITS(Issue Tracking System) あるいじはチケットシステムと呼ばれ、チケットを介して議論やステータスの管理ができます。プロジェクトの様々な情報をこのチケットに紐づけて管理すれば、最新の状況をチーム内で共有できます。

チケット駆動開発をうまく実践するには、チケットで情報を一元管理することです。ITS本来の使い方である障害や課題だけでなくタスクもチケットで管理し、バージョン管理ツールやWikiの情報もチケットと関連付けます。こうすることでプロジェクトの様々な情報をチケットと紐づけて管理できます。

何らかの理由で表計算ツールなど他の形式にする場合も、チケットから生成すれば情報の一貫性が保てます。とはいっても情報の粒度や目的などで自動生成できない時もあるでしょう。そのような場合も一から作成するのでなく、チケットの情報を確認しながら作成する、関連するチケット番号を記載するなどで、情報間の矛盾を減らし、正確で詳しい資料を作ることができるでしょう。

このような考え方はチケット駆動開発だけではありません。開発ドキュメントは工程間で抜け漏れなくトレースできないといけませんし、お客様への説明も一貫性がないといけません。アジャイル開発のストーリーカードとタスクカードの関係も同じでしょう。チケットシステムを利用しなくても、情報を小さな単位で整理して矛盾が生じないようにしましょう。

この記事はSRAアドベントカレンダーでも公開しています。

マルチスレッド処理と進捗管理・配員・作業分割/割り当て- Software Processes are Software, Too -

プロセスプログラミングを提唱したオスターワイル(Leon J. Osterweil)氏のことば

　“Software Processes are Software, Too”
　(ソフトウェアプロセスもソフトウェアである)

をヒントに、開発とマネージメントの共通点として、今回は「カプセル化」と「組織パターン」を考えてみます。開発者からマネージメントをするようになった方には経験を生かした管理を、管理をされている方には技術的な裏付けを知る機会になれば幸いです

マルチスレッド処理

複雑な問題を短時間で処理する方法の一つです。複数のスレッドを用いて並列処理すれば効率的です。シングルスレッドの処理をマルチスレッドで処理する場合、以下のような順になるでしょう。

1. 並列処理の準備
2. スレッド開始処理
3. スレッドの主処理
4. スレッド終了処理
5. 並列処理の後処理

これらはマルチスレッドを考慮して設計します。うまく設計できればスレッド数に応じて効率化されますが、うまく設計できないで主処理以外のオーバーヘッドが多い場合はスレッドが増えても効率化できません。特にすべてのスレッドの完了を待つ場合は最も遅い処理に全体が引きずられるでしょう。

進捗管理・配員・作業分割/割り当て

並列処理の簡単な例は進捗管理です。リーダーが各メンバーから順にヒアリングするには多くの時間が必要ですが、メンバーそれぞれが進捗を報告すれば短時間で終わるでしょう。しかし、各メンバーがバラバラな形式で好きなタイミングで報告するなら、内容の把握や確認でかえって時間がかかるかもしれません。手分けする準備として情報共有の仕組みを用意しておけば、メンバーの処理が標準化でき、その管理や集約も容易になるでしょう。

配員の場合はさらに工夫が必要です。進捗や成果物の共有環境を用意するのはもちろんのこと、メンバーが独立に同程度の品質を保てるようにします。具体的には横展開できるように先行して部分開発してサンプルを用意します。サンプルは成果物だけでなく、部分開発を踏まえたルールや手順などを用意して、サンプルをたたき台に作業を横展開できるようにします。

作業の分割にも工夫が必要です。作業量を平準化しやすいように時間のかかる作業は細かな作業に分割します。また、マイルストーンに合わせないといけない作業とそれ以外を分けておき、予定通りに進まないときに作業の空きがないように工夫します。

作業の割り当てにも工夫が必要です。作業者の得意な作業を割り当てれば一見、効率的ですが、作業には偏りがあるので、作業量がバラツキが出て手が空いてしまったり、誰かが体調を壊すとプロジェクト全体が止まってしまうことになります。このようなことを防ぐには、教育的な視点で作業を割り当てたり、処理の実装とテストで担当者を分ける、ペア/モブプログラミング（作業）などを長期的な視点で取り入れると良いでしょう。

この記事はSRAアドベントカレンダーでも公開しています。

カプセル化と組織パターン - Software Processes are Software, Too -

プロセスプログラミングを提唱したオスターワイル(Leon J. Osterweil)氏のことば

　“Software Processes are Software, Too”
　(ソフトウェアプロセスもソフトウェアである)

をヒントに、開発とマネージメントの共通点として、今回は「カプセル化」と「組織パターン」を考えてみます。開発者からマネージメントをするようになった方には経験を生かした管理を、管理をされている方には技術的な裏付けを知る機会になれば幸いです
。

カプセル化

カプセル化(リンク先はwikipedia)は情報隠蔽の手法で、オブジェクト指向にも取り入れられています。カプセル化することで外部には必要な情報のみが公開され、内部のデータや処理は守られます。オブジェクト指向において、外部からはメソッドを介してのみ情報を得ることができます。

オブジェクト間で連携するには、呼び出しとデータストア共有の2つの方法があります。呼び出しは責務を果たしてくれるオブジェクトのインタフェースを定めてその参照を知って知っていることで、オブジェクトに対して定められた方法で呼び出すことで、オブジェクト間で連携できます。データストア共有ではデータベースのようなデータストアを介する方法です。データ構造をあらかじめ決めておいて、オブジェクト間でデータの参照や更新を行います。

組織パターン

組織パターンは，開発チームをどう編成すればいいのかをパターンとして整理したものです。組織パターンはアジャイル開発のひとつであるスクラム開発にも取り入れられていて、プロダクトオーナーとスクラムマスターは、それぞれ門番、防火壁に相当します。チームへのインタフェースを限定し、外部からチームを守ります。チームをカプセル化するわけです。アジャイル開発に限らず、チームを外部から守り、必要な情報を提供できれば、チームは外部のストレスを受けないで開発に集中できます。また依頼すべき役割を担うチームを知り、適切な方法でアクセスすることでチーム間の連携ができます。

データストアによる情報共有はその方法によってメリット・デメリットがあります。

• タスクカード：壁やホワイトボードに張り出すことでチームの状況を見える化します。無意識に目に入るので常にゴールを共有できます。その反面、色分けなどで工夫しないと管理や検索が難しいので電子化されることも増えています。
• チケット：RedmineやGitHUBなどのチケット（イシュー）を使ってタスクを管理します。優先順序などそのままでは扱いにくいので、タスクカード風のUIをもつJIRAやプラグインが使われることもあります。
• 資料：チーム内で資料を共有します。いつでも再確認ができる反面、資料の質がコミュニケーションの質になります。
• ミーティング：もっともアナログな情報共有です。音声による情報共有はニュアンスなど情報量鵜が多いので、チケットや資料などの共有と併せて実施されます。人数や時間によって工数がかかります。

システム開発と同じように、どのようにチーム間あるいはチーム内で連携するかで、成否が決まります。ウォータフォールや味あるなど既存のプロセスを利用するとある程度の品質は得られますが、そのプロセスのメリット・デメリットを把握していないと効率的な開発は行えないでしょう。

この記事はSRAアドベントカレンダーでも公開しています。

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] 『チェンジ！』の考え方 ～マネしやんと！～）

「任せて、任せず」「魚を与えるのではなく"釣り"を教えよ」

松下幸之助氏の言葉です。

パナソニック新社長が「過去」を研究し続ける真意 停滞続く巨艦が松下時代から失ったものは何か
http://a.msn.com/01/ja-jp/AAMFYBp?ocid=st 

この記事によると

「仕事は部下に任せていても、経営者は常に事業を見て、必要なときには指示をする。事細かに指示せず、自主責任を求める」

とあります。事細かに指導していては成長しない。任せるべきは任せ、ここぞというときに「過ちすな。心して降りよ。」と高名の木登りのように指示をするのでしょう。

この「任せて、任せず」は結構難しいと思います。前提として以下の3つがあります。

• 任せられる人であること：わかっていない人には任せられません
• 任せた人の弱点を知っていること：どのような失敗をしそうか知らないと事細かに言ってしまいそうです
• 任せた作業のポイントがわかっていること：どのような作業かわかっていないことを丸投げしてはここぞという指示ができません

これらを満たすには、教育（育てること）がポイントだと思います。実現可能性が検討できているなら、たぶん3番目はできているのでしょうから、任せたい人を任せられる人に育てることでしょう。育てる中で2番目はわかると思います。

では、育てるにはどうすれば良いかというと、思い浮かぶのは「魚を与えるのではなく釣り方を教えよ」です。答えを教えるのでなく、答えを導く方法を教えることです。

それで良いと思っていたのですが、検索してみると

 ”魚を与えるのではなく釣り方を教えよ”じゃダメだと思う。 

https://toksato.hatenablog.com/entry/2010/03/24/123936

という記事にあたりました。「楽しさや意義という土台から、テクニックまで。『釣りとはなんぞや』を教えることが、大切」とのこと。ソフトウェア開発のいろいろな技術だけでなく、そもそも会社がどう成り立っていて周りから何を期待されているか、自分の人生においてソフトウェア開発をなぜするのか、輝いている先輩の原動力は何か、これらがわかっていないとこなすことだけになり、やがて仕事が辛くなるでしょう。

人生について教えることはむずかしいですが、モノづくりの楽しさや、人の役に立つ喜びを感じてもらうことが、任せられる人への第一歩かなぁ。などと思いました。

Tweet

Node-REDで世界が変わる！

（SRA Advent Calendar 2018 3日目の記事の複製です。）

ソフトウェアの世界は時間をかけながらではありますが、昔に比べると大きく変化しました。

その大きな要因は、ビジネス環境の変化が激しくなったことです。激しい変化に合わせてサービスを早く提供しなければならなくなりました。サービスの実装も変化に柔軟に対応するできるように、より小さな単位で開発する一方で、それらを組み合わせてより大きなシステムが構築されるようになりました。また、組み合わせる対象も、実行環境や共通部品などは一から開発するのではなく、オープンソースやクラウドなどいわゆる「有りもの」を利用するようになりました。

Node-REDはこのように変化したソフトウェアの世界に適した特徴を持つ開発環境です。Node-REDを使えば新しいサービスで、新しい世界を築くことができます。ソフトウェア技術者にとって、それはかけがえのない喜びです。

サービスを早く提供する

ビジネスのスピードが速くなるにつれて、サービスを早く提供することに対する要求は日ごとに増してきました。

特に、近年のシステムは、

• UI/UXのように使わないと良し悪しがわからない
• 複数のモジュールが関連するので、作らないと実現可能性や問題点がわからない
• クラウドやネットワークなど、運用しないと費用がわからない

といったことが多く、ビジネスに負けないためにはより早くサービスを提供する必要があります。

システムを早く提供するには、いくつかの方法がとられてきました。最初に行われたのは、高機能な言語やライブラリを用意することです。プログラムの記述を少なくして、実装時間を減らしたのです。

次に行われたのは自動化です。古くはmakeコマンドから始まるこの流れは、ビルドやデプロイ、テストの自動化に発展しました。そして、実装後の時間を短縮しました。

そしてインクリメンタルな開発が最後に行われました。システムが複雑になるにつれ、上流の工数はどんどん増え、サービス開始まで時間がかかるようになりましたが、実際に動かすと問題が生じて手戻りの生じることもありました。

そこで、小さな単位で実装を繰り返して、リリースを早めるようになりました。これは、仕様に対する問題を随時解決して大きな失敗を防ぐ、いわゆる「早めに小さく失敗する」ことにもなりました。

Node-REDにはこのようにサービスを早く提供することを可能にする仕組みがあります。

• ノードと呼ばれる高機能なモジュールをつなぐだけで、プログラミングできる（[#Node-RED] RedmineのREST API を呼ぶ）
• ビルドが不要で、デプロイボタンを押すだけで一瞬でデプロイできる（Node-REDから見えた未来 － 変わるもの、変わらないもの － SS2017 WG13）
• プログラミングインタフェースがmsgオブジェクトで標準化されているので、インクリメンタルな開発が容易（[#Node-RED] Hello World!からNode-REDを知る）

より小さく、より大きく

ビジネス環境の変化が速くなると、サービスを提供した後も柔軟に対応できるとともに、サービスを継続的に利用できることが求められるようになりました。

そこで、従来のようにモノリシックな1つのシステムではなく、小さな機能ごとに実装して組み合わせることで、システム全体を止めることなく、バージョンアップや保守できる構成がとられるようになりました。

そのような仕組みを実現するには、融通の利かないソフトウェアを中心に周辺のソフトウェアで調整する方法では難しく、それぞれのソフトウェアが柔軟であることが求められます。また、小規模システムでも動作すること、様々な機能を容易に組み合わせられることが必要です。

Node-REDには以下のような特徴があるので、小さなソフトウェアを組み合わせて柔軟なシステムを作ることができます。

• ファンクションノードではJavascript(Node.js)プログラミングが可能で、線をつなぐだけで順次処理も簡単（コールバック地獄よさようなら。Node-REDで非同期処理を使いこなせ！）
• IoTで使われるボードコンピュータRaspberry PiのLinuxに添付される（Raspbian、Raspbian Stretch with desktop and recommended software）
• http, websocket, MQTTやSNSなど多くの通信モジュールを持ち、簡単にシステム間を結合できる（[#Node-RED] Node-REDでTwitterのDMからRedmineのチケットを作成する）

有りものをうまく利用する

上にあげたような対策をとっていても、すべてを1から作っていたのでは開発規模が大きくなってしまいます。サービスを早く提供するには、オープンソースやクラウドなどいわゆる「有りもの」を利用して、効率よくシステムを構築する必要があります。

Node-REDには、モジュールやソースの交換が容易が容易な仕組みがあり、すでに多くのオープンソースのノード（モジュール）やフロー（プログラム）が流通しています。

• モジュール化、カスタムノード、組み込みパッケージマネージャ（Node-RED紹介（インストールからWebGUI作成））
• サブフロー、インポート/エクスポート（Node-REDでより大規模な開発を - モジュール化とフロー・システム間連携 -）
• オープンソース、クラウドとの連携（Node-RED Library）

おわりに

このようにソフトウェアの世界の変化に対応できる仕組みや環境が、Node-REDにはそろっています。その大きな要因であるビジネスの激しい変化に合わせて、サービスを早く提供することができるでしょう。

しかし、プロトタイプと同じように早く開発できるだけでは、品質の高いソフトウェアを開発することはできません。ある程度大きなソフトウェアを開発するには、きちんと設計をしないとうまくいきません（Node-REDで品質の高いソフトウェアを開発する）

Node-REDは(1)ノードに処理を表す名前（日本語可）をつければ手順を理解しやすくなりますし、最近のバージョンではグローバルなどコンテキストデータの構造や値を参照できますし（Version 0.19 released）、通信インタフェースを使って仕様の確認が可能です。

このようなNode-REDの特徴を生かしながら設計と確認を繰り返せば、大規模なソフトウェアの開発も可能でしょう（プロのためのNode-RED再入門）。

今までにない世界を作って、多くの人に幸せにすることはエンジニアの特権で、こんなに楽しいことはありません。あなたもNode-REDを使って、ぜひ新しい世界を切り開いてください。

デブサミ関西で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をフォローしてください。

答えだけを聞いて満足するな！

世の中にはスゴい人がたくさんいます。仕事で問題が発生して解決できないと、ついついスゴい人に聞いてしまいます。スゴい人には優しい人も多いので丁寧に教えてくれます。

世の中が複雑になるにつれ、鍵となる知識を持っているかどうかを問われることが多くなってきました。うまくgoogle先生に尋ねられるかどうかが問題解決の成否に関わることも多いでしょう。

うまく検索できない時にスゴい人や検索のうまい人に尋ねると、問題を解決できます。しかし、その人がいないと問題を解決できない人になってしまいます。

「なぜそれを知っているのですか？」「どうやって検索したのですか？」尋ねてみると良いでしょう？

意外と単純な答えが返ってくるかも知れません。

• 「XXという本に書いてたよ」（本は持っていたのにきちんと読んでいなかった）
• 「YYはZZとも言うのでそれで調べたんだよ」（一般的な表現を知らなかった）
• 「リファレンスマニュアルに載ってたよ」（古い解説記事氏か読んでなかった）

案外、できる人は普通に答えるでしょう（できる人を観察して勝負する、[#TiDD] プロフェッショナルは本物で確認する）。

私も以前、同様の質問をスゴい人に尋ねてrebuiled.fmを教えてもらい、それから聞いています。

日々の仕事をこなすだけでは成長できません。成長するにはちょっとした工夫と努力が必要だと思います。頑張るだけでも成長できません。答えだけを聞いて満足してはいけないのです。

[#TiDD] ポケモンGOにチケット駆動開発のポイントを学ぶ

ポケモンGOにリサーチというタスク駆動の要素が加わりました。ポケモンGOには飽きが来ていましたが、また楽しめる様になりました。リサーチの効果を考えると、チケット駆動開発に繋がるポイントがあると思いますので、まとめてみました。

リサーチには日々こなしていくフィールドリサーチと、タスクフォース的なスペシャルリサーチがあります。このうちフィールドリサーチがチケット駆動開発に似ています。

適度な粒度

タスクは適切な規模になる様に分割しましょう。

（ポケモンGOでは）

ポケモンGOは博士に頼まれて、図鑑の完成に向けてポケモンを捕まえるゲームです。図鑑を揃えるには、ポケストップでもらえたりショップで買えるアイテムを使ってポケモンを捕まえたり、タマゴを孵化します。

ショップでアイテムを買うにはポケコインが必要で、リアルなお金で購入するかジムで敵チームのポケモンを倒し維持します。ジムで戦ったり、維持するにはポケモンを鍛える必要があるので、ポケモンを捕まえて博士に送ってアメにしたり、相棒ポケモンにしてアメを増やして進化や強化します。

図鑑を完成させるには、このように色々な努力が必要で、ゴールがなかなか見えてきませんし、プレイしていてもゴールに近づいている実感はなかなか得られませんでした。リサーチは短期的なゴールをプレイヤーに示して、不安を感じずにプレイを進めることができます。

（実際の開発では）

ゴールはチームで共有しないといけません。また、そのゴールに至る節目としてマイルストーンが示されて、全体のロードマップや進捗を確認できなければいけません。

タスクはマイルストーンを達成するために必要な作業をチケットに分割したものです。タスクを全て実行するとマイルストーンやゴールに達成できないといけません。また、個人が短期的に努力できるほど（半日〜数日程度）に小さくなければいけません。

やらされ感が少ない

やらされ感が少ないとモチベーションを高く保つことができます。

（ポケモンGOでは）

前述の様にゴールに向けて様々なタスクを実施する必要があります。しかし、達成感を得られるのは新しいポケモンをゲットしたときやレアポケモンを進化させた時ぐらいでした。

リサーチを達成するとリワードというご褒美がもらえます。ボールや木の実などポケストップで得られるアイテムが中心ですが、ちょっとしたご褒美でも達成感が得られて嬉しいものです。

難しいリサーチほど良いリワードがもらえます。やりたくないリサーチは捨てることができますので、納得できるリサーチを実施して希望するリワードを得ることができます。

（実際の開発では）

開発中に評価されると嬉しいものです。タスクをたくさんこなしている人や難しいタスクをこなした人は打ち合わせの際などで賞賛しましょう。

また、こつこつと実践している人にも息抜きが必要です。定期的に何か嬉しいことがあると楽しく仕事ができます。おやつタイムや飲み会、お食事会などメンバーに合わせて考えてください。

大切なのは納得感です。押し付けられたと感じさせない様にみんなで議論し、自ら進んでコミットメントすることが理想です。しかし、そうも言えない場合も多いので、「しょうがないなぁ」と納得できるほどに情報共有し、ちょっとした息抜きや賞賛の場を作ることが、やる気を保ってくれるでしょう。

教育的であること

能力の高い技術者が不足しているのは、教育が考慮されていないことが一因です。新しいことに挑戦してもらうことで、成長を促しましょう。

（ポケモンGOでは）

リサーチには様々な種類があります。何でも良いから10匹捕まえる。特定の種類を捕まえる。ポケストップを回す。進化させる。強化する。ナイスボールなど小さな的にあてる。カーブボールを投げる。カーブボールでナイスボールなどを投げる。さらに連続で投げる。などです。

これらは、一通りの遊び方を理解させる効果があるほか、今後必要になる技術を徐々に学ばせます。ポケモンの種類を知ることはバトルに役立ちますし、カーブボールはスペシャルリサーチを達成する際に必須の技術です。

フィールドリサーチは選択できますので、自分の技量に合わせて徐々に高度なリサーチに挑戦できます。

（実際の開発では）

単純に効率だけを考えると、技術力の高いエンジニアに作業が集中してしまいます。しかし、その作業の中には、時間がかかるものの他の人でもできることがあるでしょう。

もし今後も増える作業なら、早めにできる人を増やすことが合理的です。その分だけ、できる人が別の作業をできるからです。

無理矢理に作業指示するのではなく、背景を説明して少しずつ成長してもらいましょう。その成長が技術者の喜びであり、チームの成長に繋がる様に。

おわりに

ゲーミフィケーションという言葉がありますが、ゲームの要素を取り込むまでもなく、ポケモンGOには学ぶべき所が色々あります。特に今回取り上げたリサーチは、チケット駆動開発の参考になる点がたくさんあります。

仕事は楽しくしたいもの。楽しければモチベーションが上がりますし、生産性も高くなります。

ご褒美に慣れると、ご褒美が無いとやる気を失う危険もあります。チームの状況に応じて、色々と工夫してください。

マリリンさんにサーバントリーダーシップのコツを学ぶ

本橋 麻里さん（以下、敬愛をこめてマリリンさん。リンク先はWikipedia）がTVで話題になっています。８年かけて、日本に女子カーリングのオリンピックメダルをもたらしました。

マリリンさんのサーバントリーダーシップ

その行動はまさにサーバントリーダーシップ（[#benkyoenkai] 古くて新しいサーバントリーダシップ）でした。

TVいわく、実力があるのにリザーブに回った。夜間に氷の状態を確認していた。５万円でも良いからと企業をまわった。

なんでもやったマリリンさんですが、技術力も超一流だそうです。なのに「私が」を追い求めないことで、大きな成果を得ることができたのでしょうか？

そこには、サーバントリーダーシップを実践する上でのコツがある様に思います。

１．大志を抱く

選手ですから自分の成長も考えていたでしょう。でもそれだけでなく、日本のカーリングを盛り上げてオリンピックのメダルを取るという大きな目標があったので、マリリンさんはサーバントリーダーシップを発揮できたのだと思います。

2．チームの能力を最大限に発揮する

自分が日本のカーリングを引っ張っていくと決めても、トップダウンのやり方ではうまくいきませんでした。「かなわないな」と思った海外チームの笑顔でした（カーリング・本橋麻里、バンクーバー五輪で「あぁ、かなわないな」と感じた瞬間 (1/2) 〈AERA〉｜AERA dot. (アエラドット) ）。

あの「もぐもぐタイム」や「そだね」はマリリンさんのめざす「笑顔のカーリング」をもらたして、チームの能力を最大限に発揮したのだと思います。

３．ゴールのためならなんでもする

とはいえ、マリリンさんはなんでもやり過ぎのような気がしませんか？（カーリング女子、本橋麻里の献身 深夜にストーンを投げ氷の感触を把握）そこには単に夢を抱くだけでなく、優先順序に基づく合理的な判断があったのだと思います。

オリンピック選手なのに格好悪いとか、チームの犠牲になっているとか、そんな考えは無いのだと思います。ゴールをとにかく達成したい。そのために必要なことを実行する。それだけだったのだと思います。

ソフトウェア開発に当てはめる

ソフトウェア開発に当てはめてみましょう。承認欲求や給料といったものも大切ですが、それを超えるチーム、組織、業界、コミュニティ、といったより大きな目線で目標を立て、チームの能力を最大限に発揮させるように、なんでもしないといけないでしょう。

そのためには、技術や情報を共有するしくみづくりや、技術力を向上させるために自分の仕事を譲ることや、逆に雑用と感じる作業を分担することもあるかもしれません。しかし、それは犠牲になるのではありません。大きな志の実現に向けて「何としてでもやり遂げる」強い気持ちで実践するのだと思います。

おわりに

マリリンさんの行動から、サーバントリーダーシップのコツを学びました。

TVで見せたマリリンさんの涙。表情も輝いていて、私には苦しみから解放されたというよりは大きな目標を達成した喜びの涙に見えました。

サーバントリーダーシップは大志を抱く人に、より大きな喜びをもたらす方法なのだと思います。