2017年5月31日水曜日

ソフトウェア開発のマネージメントは航空会社の運営:課題管理における「バージョンはフライトで、チケットは乗客だ」という私のバージョンに対する考え方について

あらまし

自分たちのソフトウェア出荷物に特定の名前を付ける場合に、バージョン番号を付けることは一般に広く行われています。「あのバージョンではXXX機能が加わった」とか「このバージョンではYYY機能が加わった」とか「そのバージョンではZZZ機能が壊れている」とか、その類の話です。今日は、私のバージョンに対する考え方について述べたいと思います。

前提とか状況とか

ソフトウェア出荷物を得なければならないプロジェクトで私が用いている前提は概ね以下のとおりです。

  • 人間が計画するものは必ず遅れを呼ぶ。
  • 将来の予期は難しい。
  • 特定のバージョンの出荷を遅らせても、劇的な状況改善に至ることはない。
ソフトウェアを出荷するということは、それまで内部で進めてきた活動が外部に現れ、それが何らかの価値を産むということです。当然ながら出荷しない限り価値は産みません。なので、企業を経営する立場からすると、ソフトウェアを早く出荷したい気持ちになります。

その対岸にいるかもしれないソフトウェア開発者から見ると、特定機能や要求への対応など複数の未解決項目があり、それらの状況は出荷に値しないと見ているかもしれません。ですから、出来るだけ出荷を延期したいかもしれません。

ソフトウェア開発のマネージメントは航空会社の運営

唐突ですが、私はソフトウェア開発のマネージメントは航空会社の運営に似ているなと常々考えていました。


例えば、あなたが上の図に示したVersion 1.0.0に向かって開発を進めているプロジェクトの開発者だったとしましょう。あなたは「DEF機能の追加」が全く間に合わず、ついつい「これはVersion 1.0.0の出荷を見合わせよう」と考え始めます。こうなるとそれに続くVersion 1.5.0もVersion 2.0.0も後ろにずれ込んでいくことになるかもしれません。

こうなると全てが後ろにずれ込んで、計画も何も無いような気持ちになってしまいますし、実際に外から見るとそんな風にダラダラ進んでいるように見えてしまうようです。

でも、出荷はフライトと同じだと少しだけ考え方を変えてみます。例えば、300人が搭乗する航空機の出発の際に、特定の乗客が乗り遅れようとしているからといって、3時間も6時間も出発が遅れることはありません。そうすると、全体の利益が損なわれてしまうからです。

これはちょうどソフトウェア開発における出荷の状況にも言えます。ある150個の仕事をこなした後に出荷すると決めたバージョンに対して、特定のある1つの仕事が間に合わなかったからといって、たとえそれがどんなに重要な仕事だったとしても、他の149個の仕事の成果を巻き添えにして出荷を(フライトに例えると出発を)遅らせるのは、もしかしたら行き過ぎかもしれません。

このバージョン(フライト)に搭載するはずだったチケット(=解決済みの課題)は、次のバージョン以降に延期されたけど、確実にプロジェクトは進んでいるよね?

こんな風に考えると、気持ちも少し楽になってきます。確かに約束した重要な機能は約束したバージョンに搭載されなかったかもしれませんが、それは次のバージョンで確実に搭載されるように配慮します。既に他の149個の仕事は完了しているのですから、搭載の遅れた1個の仕事に注力すれば、次に行うべき他の仕事よりも完了する確率は高いでしょう。

最後に

ソフトウェア開発の場合、とても乱暴に言って遅れることは問題ではありません。それよりもむしろ、進んでいないように見える、あるいは進んでいないことが一番の問題です。ソフトウェア開発のマネージメントに際して、事前に計画した内容の通りに進まないといけないといった厳しい外部制約を与えると、局所的には最適化されるのかもしれませんが、全体の動きは鈍くなる可能性があるので、私は航空会社のように全体の利益に基づいて柔軟に計画を変更することは重要だと考えるようになりました。

2017年4月30日日曜日

今すぐ出来る!HTML5なウェブサイト実現ワークショップ「#HelloHTML5」を開催します。

はじめに

近年、ウェブサイトのHTML5化が盛んに行われています。 様々なデバイスがウェブに接続されるようになり、端末の画面サイズに応じた表現なども必須になってきました。 このセミナーでは、「今すぐ出来る!HTML5なウェブサイト実現セミナー」と題して、HTML5を活用したウェブサイトの実現をワークショップ形式でお届けします。

お勧めする人

  • ウェブサーバーを立ち上げたけど、魅力的なコンテンツの実現に技術的な課題を感じている方。
  • サイトをHTML5化したいけど、どこから手を付けてよいかわからない方。
  • 組み込みシステムのエンジニアリングが専門で、ウェブ技術の調査までなかなか手が回らない方。
  • その他、とにかく現状のウェブが不満でどうにかしたい方。
  • そもそも億劫でなかなかウェブの実現が進まない方。

参加登録

2017年3月26日日曜日

MicroShellをArduinoにも対応させ、Version 0.0.2として公開しました!

小規模組み込みシステムのシリアル・コンソール・インターフェースとして便利に使えるミドルウェアMicroShellをArduinoにも対応させ、Version 0.0.2として公開しました。
https://www.cubeatsystems.com/microshell/download.html からダウンロードできます。



2017年2月28日火曜日

熱血!アセンブラ入門に感化されてARM Cortex-M0で動作する小さなオペレーティング・システムUOS-LPC800のパッケージを更新しました!

ARM Cortex-M0で動作する小さなオペレーティング・システムUOS-LPC800のパッケージを更新しました。今回はとても地味にコンパイル・オプションの更新を行っただけのパッケージです。


今回の更新は完全に「熱血!アセンブラ入門」に感化されたもので、今回のパッケージを展開してLPCXpressoでコンパイルすればアセンブラまで確認できるというものになっています。


ビルドすると.hexなどの他に.asmが出力されるようにしました。


中身を見るとソースコードとアセンブラを同時に確認できます。
熱血!アセンブラ入門と同時に活用できる便利なパッケージです。


ダウンロードは以下からどうぞ。
http://cubeatsystems.com/uos-lpc800/download.html

2017年1月31日火曜日

ARM Cortex-M0でもラクラク使えるNT-Shellよりもコンパクトな端末入出力ミドルウェアMicroShellライブラリを開発しました (NXP LPC824用サンプルプロジェクト付き)

あらまし

昨年のこと、NXP LPC824を使ったサウンドモジュールMicroSoundModuleを開発していました。このサウンドモジュールは、コマンドを受け取って色々な再生を行うもので、当初はこのコマンド処理部分の実装にNT-Shellを用いる計画でした。しかし、最小10KBのROM、最小1KBのRAMを要求するNT-ShellはNXP LPC824の小さなリソースに対して厳しいものです。仮に入ったとしてもアプリケーション側に大きな制約を課すことになります。

よくよく見まわしてみると、様々な面白そうなマイクロコントローラがNXP LPC824と同クラスで存在します。ARM Cortex-M0のような小さなマイコンを使ったシステムにおいて、NT-Shellほどの機能は要らない、でも、きっちり入力は出来るようにしたい、といったニーズはありそうです。

そこで、NXP LPC824のような小さなサイズのマイコンにも導入可能な端末入出力ミドルウェアを開発することにしました。名付けてMicroShellです。



使い方

使い方はmicroshell_initという関数にハンドラの実体へのポインタと、ブロッキング型のシリアル送受信関数のポインタを渡すだけという至って単純なもの。このコードだけできっちり動作する入力系が得られます。とても簡単ですね。



内部構造

内部構造は、以下の図に示すようにcoreとutilの二つから成り立っています。本当に最小限の構成にしたい場合にはcore側のmicroshellを用い、この場合には1行の入力処理が得られます。これに加えてコマンドのパースなどを行いたい場合には、util側のmscmdを用います。



ダウンロード

ダウンロードは専用サイトからできます。

2016年12月30日金曜日

塩漬けになっている「Micro Sound Module」をなんとかしようと思い立つ

試作してから塩漬けになっているMicro Sound Moduleですが、年末年始のちょっとした時間で取り組もうかと考えています。そもそも、塩漬けにしすぎて何をどこまでやったのか忘れてしまった。


元々、アートインスタレーションで使えるような小さなモジュールにしたかったので、仕様から様々なこだわりを切り捨てて作りました。LPC824を選択したのも、「このくらいのマイコンを選べばアレコレやろうとしても欲張れないだろう」という斜め上(下?)の動機があったりします。

ということで、ちょっと成果物を眺めてから色々と取り組んでみようと思います。

2016年11月30日水曜日

リアルタイムOS教材について思う事(をちょっとだけ書いてみる)

■あらまし

学生の頃からリアルタイム・システムに興味があって様々な書籍を読んでいた自分ですが、エンジニア・ライフを約一周ほど楽しんで、そろそろ思うことあってリアルタイムOS教材についても触れなければならないなと考え始めました。というのも、世の中に溢れる教材の中には、初学者に与えるべきでない間違った例が数あまたあり、それらが実開発の現場で様々な問題を生んでいるからです。今日はその中からひとつだけ取り上げてショート・ブレイクとして書いてみます。

■良くない例:タスク・スリープで排他処理

世の中には不思議な例を取り上げてリアルタイムOSの機能を紹介する例を見かけます。その代表例がタスク・スリープで排他処理やシステムの状態を管理する例です。

この例を取り上げる教材の多くは、リアルタイムOSの機能を紹介したいようでもあるのですが、よくよく読んでみると、結局のところどれも「こういうときはこうするのだ」と実際のアプリケーションについて触れています。しかし、このような設計で実システムを実現されてはひとたまりもありません。

リアルタイムOSの使い方として間違ったアイデア、「タスク・スリープで排他処理やシステムの状態を管理」が何を言っているのか図示してみます。


タスクAとタスクBは、それぞれグローバル変数であるint valueを操作します。もうグローバル変数が出てくる時点で完全に失格なのですが、問題はそこではありません。この典型的な間違ったアイデアは、よく以下のような方法で紹介されています。

①システム起動直後、タスクAは動作し、タスクBは寝ています。
②タスクAはint valueを操作し、タスクBを起こして自分は寝ます。
③起床したタスクBはint valueを操作後、タスクAを起こして自分は寝ます。

例えば、この設計には以下の疑問がつきまといます。

A. タスクAとタスクBが非同期で双方動作している瞬間について考慮されていない。
B. タスクAがタスクBを知っている。タスクBがタスクAを知っている。つまり循環参照関係にある。
C. やっている内容から考えると、そもそも単一タスクで良い。(説明に必然性が全く無い)
D. その他。

上の例、int valueと書いてあるものは物理デバイスであることもあります。となると、なおさら問題は複雑になります。というのも、物理デバイスは動作に時間がかかります。状態遷移中の物理デバイスの状態を適切に扱う場合、上記の例では対処できません。

■例えばどうすれば良いのか?

リアルタイムOSを使うのは、抽象化レベルを上げつつ、キビキビとした動作を実現できるからです。上記の例で言うと、int value(物理デバイスかもしれない)は、操作対象ですが、これはあるタスク内部で操作される操作対象と見ることができます。つまり、タスクAやタスクBから操作される新たなタスクCのようなものが内部で操作する対象とすることができます。


そして、タスクAやタスクBからメッセージ通信でタスクCに操作を依頼する形式を取ります。
「ちょっと待って!さっきの例で出来ていたタスクAとタスクBの同期ができないじゃない!」と言われるかもしれませんが、タスクCは単一スレッド上でメッセージ受信処理を行っているので操作は競合しません。

加えて、タスクCのAPIを工夫しておけば、操作自体も抽象化された表現で扱うことが可能になります。
  • アームを上に上げろ!
  • アームを下に下げろ!
  • 緊急停止!
上記のような操作を抽象的に表現したAPIにするだけで、グンとシステムで操作する内容がわかりやすくなってきます。そして、実装の詳細はタスクCに隠ぺいされるというメリットも生まれます。タスクAとタスクBが循環参照状態になる事もありません。

■ということで・・・

リアルタイムOSの教材でタスクのスリープを使って状態をコントロールするような例を見かけたら、「この教材は怪しいな」と疑って内容をレビューしてみて下さい。