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

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

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

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

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


Node-RED: joinノードでタイムアウト処理

Node-REDアドベントカレンダーからの転載です(SRA Advent Calendar 2018からもリンクしています)。

はじめに

Node-REDで通信をする際のタイムアウト処理は、ユーザディレクトリ(~/.node-red)のsetting.jsで変更することができます。例えば、httpリクエストのタイムアウトは、httpRequestTimeoutで変更できます。

しかし、全体の処理時間に制限がある場合など、呼び出し先などによって変更したい場合は対応できません。オーソドックスな方法はファンクションノードで頑張ることかもしれませんが、それではデバッグノードで簡単にデバッグするというNode-REDらしい開発ができません。そこで、標準ノードであるjoinノードを使って、呼び出しの際のタイムアウトを処理する方法を考えてみました。

joinノード

joinノードはsplitノードと組み合わされることが多く、配列などをsplitノードで分割し、それぞれを非同期に処理した後にjoinノードでまとめるという使い方をされます。実はjoinノードは単体でも利用可能で、複数のmsgオブジェクトをタイムアウト時間内にまとめて出力することができます。これを利用するわけです。

具体的には、httpリクエストの直前でmsgオブジェクトをリクエスト処理用とタイムアウト処理用に作成して利用します。joinノードでは、まとめる単位ごとに共通のidが必要で、これにはmsg._msgidを使っています。また、総数のcount、それぞれのmsgオブジェクトを識別するindexが必要です。

joinノードでは結合対象のプロパティ以外には破壊的ですので、結合対象のプロパティに保存しておきたいデータをコピーしておきます。

フロー

実際のフローが下記になります。テスト用サーバーがあるので複雑に見えますが、主要な処理は上部の7つほどのノードだけです。

Timeout_flow

ポイントは、joinの前に必要なプロパティをセットすることです。また、タイムアウトの際にはチェック用のメッセージが流れた後でhttpのレスポンスが返ってきますのでこれを捨てる必要があることです。

上部のcatchノードはタイムアウトの際に例外が発生するのでつけていますが、この辺はお好みで変更してください。

注意点

更新処理の場合、クライアント側でタイムアウトしてもサーバで処理が行われる可能性がありますので注意してください。

コード
元記事の下のほうになるコードをインポート(読み込み)して使ってください。

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


大切なことはスタートレックから学んだ(総集編)

SRAアドベントカレンダーからのまとめです。

エンジニアの誇り

スタートレックとは宇宙大作戦から始まるSFテレビドラマシリーズです(wikipediaU.S.S. Kyushu)。複数の番組があり、制作された時代によって背景にあるテーマ(価値観)が異なっていて様々な刺激を感じます。

バブル崩壊後に公開されたスタートレック:ヴォイジャーは、バブル期のイケイケどんどんから新たな歩みを一歩ずつ進めていこうとする言葉がありました。

「栄光を築くのは戦士かもしれないけど、社会を築くのはエンジニアよ」

         スタートレック:ヴォイジャーの トレス中尉の言葉

戦士のところを企業戦士と読み替えてみてください。企業において営業や経営層は、売り上げに責任を持つことから、評価が高いかもしれませんが、実際にシステムを開発するのはエンジニアです。

利用者に喜ばれるシステムを作ることで信頼を勝ち取り、企業活動を通じて社会に貢献することで、その存続を担うのはエンジニアの仕事です。

開発が遅れたり、トラブルが生じる方が会社の利益になることもあるでしょうけど、「社会を築く」という誇りがより良いシステムの開発に我々を向かわせるのだと思います。

新しい技術への挑戦

多くの刺激を受けたのは、バブル期の「新スタートレック」というシリーズです。科学技術の発展でお金があれば何でもできるような社会風土の中で、人間や家庭に対して問いかける場面が多くあります。

「生まれつきの親なんて一人もいませんよ。みんな苦労しながら学ぶんです。」

            by カウンセラートロイ@新スタートレック4-4

もっと早く聞きたかった言葉です。うまくいかないと、何かにつけて自分はダメだ、向いていないと思ってしまいがちです。しかし、全知全能なのは神様だけで、人間は完ぺきではありません。うまくいかなければ、勉強すればよいのです。

技術者は、新しい技術に常に立ち向かわなければなりません。経験のある環境でもバージョンアップでトラブルに合うこともあるでしょう。

常に学ぶことを忘れない。エンジニアに求められていることです。

プロジェクト

スタートレックのすべてのシリーズに男女間の話が出てきます。坂本龍馬が世の中の情勢を男女間の話に例えたように、プロジェクトを男女間の話に例えると学びも得ることができます。

「あんな恋は二度と無い」
「そうよ」
「意外なセリフ」
「また恋はする。でも同じ恋は二度とないわ。いつもちがうの」
「恋って難しいね」
「そういうものよ」

                  新スタートレックより

恋をプロジェクトに置き換えてみてください。プロジェクトは常に新しい何かを作る仕事ですから、同じプロジェクトは2度とありません。だから、いつも難しいのでしょう。

理念の大切さ

スタートレックは未知の宇宙を航海するドラマです。未知の文明に遭遇した際に影響を与えてしまわないことが、重要な理念になっています。

そのほかにも惑星連邦憲法があって、裁判を行う際には重要な役目を果たします。しかし、未来においても裁判で不条理な主張をする人間がいます。そこで、ピカードが言った一言。

「憲法の基本理念を勝手に覆す事はできない」

           ピカード@新スタートレック シーズン4 第21話

アジャイル開発が話題になりだした頃、クレド(信条)が話題になりました。会社や組織が同じ方向を向くためには必要なものです。

SRAにもクレドのようなものがありますが、聞く機会も少ないので暗記している人はあまりいないでしょう。とはいっても、その中に「プロフェッショナル集団である」という言葉があることだけは、多くの人が知っています。そのことが技術志向の会社であることにつながっています。

もちろん、SRAにもそうではないと思う人はいるでしょうが、その理念は勝手に覆すことはできないのです。

組織の考え方

スタートレックは宇宙ステーションが舞台のDS9を除いて、戦闘能力を持つ宇宙船のお話です。登場人物はピラミッド構造の組織に属し、上長の命令は絶対です。

しかし、惑星連邦の理念に反する場合や緊急事態では、命令に反することも行われます。今回は、そんな場面でのピカード艦長の言葉を紹介しましょう。

「私は命令に従っただけです」という言葉でどれだけほと多くの過ちが正当化されてきたと思う。自分の考えを持たず、ただ命令に従うだけの士官なら連邦には要らない。

                ジャン・リュック・ピカード@新スタートレック

このような上長の懐の深さが、組織を健全に保つのだと思います。

SRAでも上長に反論するような気骨のある人間を喜ぶ人が少なからずいて、オープンで風通しの良い環境を保っているのだと思います。気骨のある人は、ぜひSRAにお越しください。

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

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]インジェクトノードで定期処理 - ポーリングとバッチのヒント -