無料ブログはココログ

Node-REDで世界が変わる!

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

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

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

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

サービスを早く提供する

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

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

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

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

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

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

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

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

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

より小さく、より大きく

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

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

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

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

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

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

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

おわりに

このようにソフトウェアの世界の変化に対応できる仕組みや環境が、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経験者のアンケートを元にキャチーなキーワードで概要をまとめました。しかし、発表に向けてスライドを作る中で本音や伝えたいことが増えたので、書き足しました。

そもそもの始まりはお客様からの依頼でした。自分たちの仕事を減らすかもしれない開発に対して、それまでの仕事に対する「お客様と同じ方向を見る」(アジャイル開発)、「適切な費用をもらう」(オープンソース)、「よい技術を取り入れる」(技術志向)という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には学ぶべき所が色々あります。特に今回取り上げたリサーチは、チケット駆動開発の参考になる点がたくさんあります。

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

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

このエントリーをはてなブックマークに追加


効率的な開発を考えたらモダンアジャイルになった話 - Node-RED UG大阪 - #noderedjp

Node-RED UG Osaka 勉強会 Vol.2で発表してきました。色々トラブってご迷惑をおかけしました。説明が不十分だったので、説明をまとめておきます。

Node-REDは高度なソフトウェアを簡単に開発できるので、プログラミングの敷居を下げてくれます。しかし、少し大きなソフトウェアを開発し出す時には、それなりに考えて開発しないと、保守が難しく、効率が悪く、品質が低く、生産性が上がらなくなってしまいます。

具体的には、タブとリンク、サブフロー、カスタムノード、通信などで分割する。1対多の接続を避ける。msgオブジェクト、グローバルオブジェクトなどをデータモデリングする。常に動作を確認しながらインクリメンタル(漸増的)に開発し、機能テスト・非機能テストを工夫する。上流から仕様の確認に用いる。といった工夫が必要です。

アンケートから垣間見える内容を考察すると

  • ツールの知識やノウハウを共有すること
  • 特性を活かした設計で品質を作りこむこと
  • 実装を繰り返して常に確認すること
  • 上流から利用すること

という4点に集約されます。 情報共有や教育が重要であるだけでなく, 既存のプロセスをそのまま適用するのではなく, 積極的に変更することがプロセス改善につながります。

これらは、 従来のアジャイル開発のエッセンスを焼き直したモダンアジャイルの指導理念とも共通するものです。より良いソフトウェア開発が効率的な開発に繋がるのでしょう。

開発ノウハウや経験により得られた知識は、ドキュメントや書籍からだけではなかなか得られません。経験者の集まりであるユーザ会の今後に期待しています。

このエントリーをはてなブックマークに追加


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

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

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

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

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

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

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

1.大志を抱く

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

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

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

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

3.ゴールのためならなんでもする

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

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

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

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

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

おわりに

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

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

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

このエントリーをはてなブックマークに追加

プロのためのNode-RED再入門

社内勉強会より社外の勉強会と考えていますが、業務に合わせたテーマとしてNode-REDの社内勉強会を実施しました。私の部門ではそれなりに経験者がいますので、新しいバージョンのNode-REDを踏まえて、入門より少し上の話をしました。

Node-REDはノードと言われるモジュールを繋ぐだけで、高機能なソフトウェアを簡単に作ることができます。しかし、規模が大きくなると見た目もまさにスパゲティ状態になり、デバッグや保守が難しくなります。

そのような問題は、今回説明した構造化、設計、テストの基本的な知識があるだけで改善できます。 CC Attribution-NonCommercial License(CC BY-NC)で公開しています。ぜひ、この資料をご活用ください。

このエントリーをはてなブックマークに追加


[#Node-RED]インジェクトノードで定期処理 - ポーリングとバッチのヒント -

SRA Advent Calendar 2017 9日目からの転載です)

今回はインジェクトノードによる定期処理とそのヒントを説明します。

1. インジェクトノード

インジェクトノードというのはNode-REDの最初のサンプルでほぼ間違いなく使われるノードです。左の四角い所を押すと現在時刻や文字列、JSONオブジェクトなど設定したデータがmsg.payloadにセットされて送信されます。

20171209_153945_3

インジェクトノードは多機能で、起動時にメッセージを送信して初期処理を実現できますし、「繰り返し」の設定で定期的にメッセージを送信してポーリング処理やバッチ処理を実現することもできます。「繰り返し」をセットすると、インジェクトノードに丸矢印が表示されます

2.ポーリング処理とバッチ処理

ポーリング処理というのはデータ取得の方法です。センサーや通信装置などからデータが送られ無い場合、プログラムの側からデータを取りに行く必要がありますので、求められる時間間隔でポーリングし(取りにいき)ます。

バッチ処理というのは必ずしも定期処理ではなく、まとめ処理を実行するという意味です。UNIX系のcron処理やジョブスケジューラやタスクスケジューラなどと組み合わせて定期処理を実現されることも多いので、ここではバッチ処理と呼びます。

フロントエンドで受信したデータを蓄積し、バックエンドのバッチ処理で定期的にまとめて処理します。こうすることで同時処理を避けることができ、CPUやメモリなどのリソースを効率よく利用することができます。

3. インジェクトノードによる定期処理

インジェクトノードの「繰り返し」では、以下の3種類(と「なし」)を設定できます。

3.1 指定した時間間隔

サーバやセンサから定期的にデータを取得したり、DBにあるデータを定期的に処理する場合に用います。秒、分、時間で指定できます。

20171209_135528_3

3.2 指定した時間間隔、日時

曜日と時間帯を1時間単位に指定し、分単位で定期的に処理ができます。cronで実行されるので、あまり精度は期待できません。

20171209_135713_3

3.3 指定した日時

曜日と時刻を分単位に指定し、定期的に処理ができます。cronで実行されるので、あまり精度は期待できません。

 

20171209_135747_3

4. ヒント

4.1 より短い間隔で実行する

例えば0.5秒ごとに実行したい場合は、インジェクトノードを1秒間間隔で指定し、出力を二股に分けて一方をディレイノードで500ミリ秒遅延させます。こうすると、メッセージが0.5秒ごとに送られる様になります。

20171209_153616_3

片側に1ms、もう一方に501msのディレイを入れると一旦両方のディレイノードが実行されるので、 より精度が上がるでしょう。ただし、精度はそれなりですので、あまり細かくしたり、後続の処理が重かったりすると、うまく動かないので注意してください。

4.2 重複に注意

繰り返しの時間感覚よりも処理時間がかかると処理が重複しますので、注意してください。処理が重複すると、同じデータを2回処理してしまったり、メモリなどのリソースが不足する可能性があります。

4.3 別の方式も検討する

バッチ処理の場合、ディレイノードでキューイングする方法も検討してください。この場合、実行中のデータは保存されないので気をつけてください(バッチ処理でも蓄積する際に永続化しないなら同じです)。このほかにも、クラウドのサービスなどでもキューイングできるでしょう。

5. まとめ

インジェクトノードによる定期処理とそのヒントを説明しました。IoT開発ツールとして以前から繰り返し実行ができましたが、最近はノードに繰り返しの表示が出る様になって、より使いやすくなりました。

Node-REDの面白いところは、シンプルな機能を組み合わせて色々なことが簡単にできる所だと思います。ぜひ、みなさんもインジェクトノードを使って色々と工夫してください。

# おまけ
標準のインジェクトノードでも工夫次第で様々な処理が可能ですが、bigtimerノードならより直感的な設定ができるようです。

このエントリーをはてなブックマークに追加


暗黙知は帳簿と運用に眠る - 業務理解に向けて - #benkyoenkai

年忘れLT宴会<第60回IT勉強宴会>に参加しました。最も刺激を受けたのは杉本さんのLTでした。

暗黙知

同じお客様の開発を何度かすると「なるほど」と過去のことが理解できることがあります。与えられた仕様(要件)を満たすソフトウェアを開発する中で、その背景にある暗黙知が得られた瞬間です。

もちろん、最初の開発でもある程度は暗黙知を得ることはできます。仕様についてそれはなぜかを質問することです。納得できる詳しい説明や、これまでそうしてきたからなど、色々な回答が得られます。

しかし、暗黙知の全体像に関しては、開発を一通り終えて、実際の運用がうまく回り出して一通りの業務を近いするまで、なかなか得られません。

帳簿は暗黙知の中心

杉本さんのLTで紹介された開発では、帳簿(DB)が業務システムの中心で、運用で対応する部分も含めて業務システム開発します。そのような開発に於いては、業務分析やデータモデリングを追求することで、業務を明確にして暗黙知をシステムに取り込んでいくのでしょう。

それはソフトウェアのプログラミングだけでなく、帳簿(DB)はもちろんのこと、運用を含めた暗黙知を明確にしないと教務システムはうまく開発できないという示唆だと思いました。

おわりに

SRA Advent Calendar 2017に「効率的なモデリングをマネージメントする」(ここにも転載:その1その2その3)という記事を書きました。これに運用はほとんど考慮されていません。

これまで、いわゆる業務系とは異なる開発をしていながらも、IT勉強宴会で色々勉強をさせていただいてきましたが、どこかモヤモヤするものがありました。それが運用であったことに気付くことができたのは、今回の大きな収穫でした。

IoT関係で運用と言うと、UIがらみを除くとクラウドのアーキテクチャ設計とその運用設計がそれに当たります。クラウドでは新しいサービスが続々と出てきますので、それが開発を一通り経験しないとわからない理由だったのかと腑落ちした次第です

LT中のアジャイルウォーターフォールに関しては、主語が大きくて気になりますが、それを上回る刺激を受けました。ありがとうございました。

このエントリーをはてなブックマークに追加

効率的なモデリングをマネージメントする その3 - 開発標準を素直に実施しない -

SRA Advent Calendar 2017 23日目からの転載です)

はじめに

まじめにやっているのにうまくいかない。標準なんだからその通りにやればいいじゃないか。そう思われるかも知れません。

しかし開発標準で守らないといけないことには幅があり、それなりの自由度があります。きちんと理解した上で適切にモデリングすれば、効率的なモデリングが可能になります。

開発標準

開発標準は成功したプロジェクトを参考に、良いプロセスの実施が容易な様に、実施すべき各作業とその確認方法を定めたものです。開発者を支援して、一定のレベルへの底上げや組織的な改善を可能にします(その反面、さまざまな罠もあります。標準は諸刃の剣)。

モデリングをする際にも、ある時はガイドやノウハウ集として使えますが、時には収集したデータの正常範囲を定めるなど、モデリングや実装の作業を制限します。

開発標準を良く読む

大切なのは開発標準を良く読むことです。開発標準には以下のようなことが書かれていると思います。

  • 全体の構成と考え方(ガイド)
  • 守らないといけないルール(制約)
  • 一般的な方法(ガイド)

ガイドに当たる部分はうまくいったプロジェクトで行われた一般的な開発の方法や作業が書かれています。制約に当たる部分は守らないといけないルールで、作業だけでなく何らかのメトリクス(尺度)が定められているでしょう。作業のエビデンス(照査)となるデータの収集が必要です。レビューやテストの項目数や時間など一定の量が必要になり、作業が制約を受けるでしょう。

開発標準には多くの役立つことや勉強になることが書かれていますが、必要なことが全て書かれている訳ではありません。書かれていることに従って、それだけをコツコツ実施しても、必ずしもうまくいくとは限りません。

リスクが工数に見合うだけ低減するなら、下記のようなモデリング作業の変更が必要になります(同程度でも実施します)。

 
増やす
 
      必要なモデリングを追加します。多くの場合、設計作業の追加はあまり禁止されていません。  
 
前倒し
 
     よりリスクが低減するなら後工程の作業を前倒しします。一部詳細化したり、プロトタイピングの実施など、本格的な実装でなければ許容されるでしょう。  
 
分解
 
       モデリング作業を分解し、調査、整理、考えるといった作業を前倒しします。会議内で(モブ)モデリングしても良いでしょう。  

大切なのは、予め計画してステークホルダーと合意を得ておくことです。また、開発中であっても必要が生じたら、面倒がらずに計画を変更することも重要です。
前回の「効率的なモデリングをマネージメントする その2 - モデリングの戦略 -」を参考にしてください。

逆らっても徒労に終わることが多い

若気の至りで開発標準に抗議したこともありますが、逆らっても徒労に終わることが多いです。開発標準は必要な作業の抜けを防ぐ目的で組織として決めたものです。個別のプロジェクトに対してテーラリング以外の変更を要求しても、許容する権限が担当者にありません。

逆に制約だけを守れば、意外と自由度があるものです。ガイドを読んでしっかり活用することで得られることも多いでしょう。

とはいえ、どのような標準も使っていれば時代遅れになるもので、改善案は提案してください。パイロットプロジェクトで確認することも必要ですので、改訂には複数年かかるでしょう。

開発標準のフィールドで走り回れ

多くの競技にはコートのような活動領域が決められていて、競技者はその範囲を有効に使いながら、敵を攻略します。

開発標準は縦にだけ動けるサッカーゲームの様に、典型的ないわば「型」を示したものです。定められたフィールドからはみ出さない程度に、右に左にゴールに向けて戦略的に攻撃ください。

おわりに

効率的なモデリングをマネージメントする方法を3回に分けて説明しました。以前はうまく開発できていた人が、プロジェクトが変わると急にトラブルに巻き込まれる。そんな姿を見たくありません。

開発標準と改善活動はフィットするプロジェクトにはとても効果的です。しかし、それぞれの作業がなぜ必要なのかをきちんと理解しなければ、典型的なプロジェクト以外に応用がききません。

何が制約であり、なぜそのようにするかを理解すれば、開発標準を味方につけられます。そして、自由なフィールドを手に入れて様々な実施方法ととることができます。

釣りは「ぼーっ」としていては釣果が出ないそうです。常に「ああかな」「こうかな」と状況を見極めて必要な行動が必要だそうです。ソフトウェア開発でもいつもリスクを見極めてダイナミックに適切な対応をとることが、リスクと戦う効率的な方法だと思います。


「だから、あなたがたは気をつけていなさい。」マルコによる福音書/ 13章 23節(日本聖書協会 新共同訳)

このエントリーをはてなブックマークに追加

«効率的なモデリングをマネージメントする その2 - モデリングの戦略 -