無料ブログはココログ

映画「沈黙」 - ダメな自分を受け入れてたくましく生きる -

映画「沈黙 - サイレンス -」を見ました。遠藤周作さんの告解(赦しの秘跡、いわゆる懺悔)共言える原作を読んでいたので、過激なシーンがないかと少しドキドキしていましたが、良い感じで遠藤周作さんの思いが表現されていました。

ソフトウェア業界ではメンタル面で問題を抱える人が増えています。その根底には主人公のロドリゴの苦しみに繋がる問題があると思いました。

ストーリー

徳川の時代になって禁教令が出た頃、音信不通になった神父を追って日本に宣教に来た神父ロドリゴ、踏み絵を踏んでマニラに逃げ延びたキチジローを案内として神父ガルベと共に日本に忍び込み、隠れながら宣教活動をします。

しかし、キリシタンに対する弾圧は激しさを増し、最後には捕まってしまい、棄教を迫られます。ロドリゴは神に祈りますが神の声は聞こえず、棄教しないと他の人間が殺されていまいます。

踏み絵を踏む事を迫られてついに棄教しようとした時、ロドリゴは神の声を聞きます。

遠藤周作さんに必要だったもの

実話を元に描かれたロドリゴは、宣教師としては失格でしょう。この姿は自ら「ぐうたら」と称する遠藤周作さんの人生の写像の様です。教会からフランスに留学させてもらったものの、結核で帰国。しかも、フランスでは婚約者のいる女性と恋仲になるなど、自慢できない過去がありました。

そんな遠藤周作さんが求めたのは、ダメな自分をゆるして、次に進む力を与えてくれる優しい神様でした(注参照)。そのような信仰が遠藤周作さんに世界から賞賛される作品を生ませました。

これは自己肯定感と言われているものです。

次に進むための自己肯定感

信仰に関係なく、人には自己肯定感が必要です。もし自己肯定感が無いなら、理想の自分とのギャップに苦しむことになります。

その結果、自分の責任ではないと犯人探しをして責任転嫁や言い訳をするか、自分はダメだと自己嫌悪から落ち込む事になります。何れにしても現状を受け入れていないので次に進む事ができません。

プロジェクトをより危険な状態にしてしまう

自己肯定感は個人の問題ですが、その影響でプロジェクトの問題をさらに悪化させ、より危険な状況にしてしまいがちです。

責任転嫁をする人は自分は悪くないと思っていますので、批判しかしません。他の人にたしなめられても受け入れる事ができす、かたくなな姿勢で問題解決に向けた行動を取ろうとしません。

逆に落ち込む人は、迷惑をかけるとか、怒られるからと、問題を報告しないでもう少し自力で何とかしようとしがちです。でも、そもそも問題の原因があまり理解できていないことで問題が顕在化したのですから、問題は大きくなるばかりです。

自分は一人じゃない

「沈黙」の神様は最後の最後にならないと声を聞かせてくれませんでした。しかし、プロジェクトは会社という組織活動ですので、一人ではありません。

わからない事は聞けば良いですし、困った時は相談すれば良いはずです。それができないのは、自分や現実を肯定できないからです。

(もちろん、逃げ出さざるを得ない時もあるでしょうが、そのような状況なら、一人で努力するだけ無駄です)

より良い未来をめざす!

現実を受け入れた後の未来は、理想どおりではないかも知れません。しかし、合理的で、自分一人で悩むよりもより良い未来です。

人の助けを借りても負い目を感じる必要はありません。今度は他の人を助ければ良いのです。そうすれば、幸せの輪がどんどん広がります。責任逃れをしている自分、情けないほどにダメな自分を認めれば、人に優しく、社会に貢献できるのです。

ダメな自分を受け入れてたくましく生きましょう。映画「沈黙」を見て、その思いを強くしました。


遠藤周作さんまでのキリスト教は、明治時代の内村鑑三を初めとする厳しいキリスト教でした。キリスト者として生きる事が神の証であり、悪い事をせずに清く生きる事が求められました。

しかし、現実には戦時中に「父と子と聖霊と天皇陛下万歳!」と言わなければ、教会を存続できませんでしたし、闇市に依存するなど法律を破らなければ生きていけない時代だったようです。

そのように誰もが罪の十字架を背負っている時代を踏まえて、遠藤周作さんは傍にいる神の愛と赦しを信仰の中心としました。より愛を重視する考え方は世界的にも注目され、「沈黙」は多くの国で翻訳されて読まれることになりました。

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


「深層学習の概要とドメインモデル」に参加してエモーションチップを考える

もっとも印象的だったのは、以下の言葉です。

適切に学習すれば、有限個のニューロンで任意の連続関数を近似できる
(universal approximation)

いつもお世話になっているIT勉強宴会で深層学習(ディープラーニング)のお話を聞いてきました(幹事の佐野さんが深層学習の概要とドメインモデル<第53回IT勉強宴会>に詳しくまとめられています)。ここでは、個人的な感想をまとめます。

ニューロンは判断するもの

深層学習の基本であるニューラルネットはは多層のニューロンから構成されます。このニューロンというのは「脳神経系における情報伝達を模した数学モデル」で、しきい値を超えると発火する、いわば入力に対する判断機構です。

ニューロンは20世紀からある技術で、ソフトウェア障害の有無などの判断をする論文などもありました。しかし、他の統計的手法がよく使われているのは、ご存じの通りです。

多層化による能力向上

その後、技術の発展や計算機能力の向上などでニューラルネットを多層化できる様になりました。ここで出てきたのが、初めに挙げた言葉です。

ニューロンを組み合わせれば何でも判断できる。そんな夢が広がりました。しかし、現実は厳しく、精度があまり上がりませんでした。

フレームワークの発展

近年の深層学習の話題を見ているとスゴいものばかりで、なぜだろうと思っていました。それらは、ニューラルネットの層に意味を持たせたり、途中で分岐したりと、より人間の脳に近づく事で精度が上がったそうです。

SF好きの私などは、より人間の脳に近づけばいつか人間の様に意識を持つのかと期待してしまいます。しかし、そこで障壁となるのが最初の言葉です。あくまで近似なのです。

機械学習あるいはデータ少尉の限界

新スタートレック(TNG)に出てくるデータ少尉を見ていると、機械学習の限界を感じさせます。人間と共に宇宙船の士官として働き、頭脳明晰、記憶や情報検索にすぐれ、技術を組み合わせた新しい提案や、過去の音楽家の味付けをして演奏する事が可能です。

しかし、友人がいても、悲しみや喜び、愛情を感じる事はありません。大切な人を失っても「何かが抜けたような」認識を持つだけです。仲間を作ったり、敵と戦うなど、本能的な能力が必要なのでしょう。

実はデータ少尉には兄がいてエモーションチップによる感情を持っています。しかし、性格が悪く失敗した様です。

おわりに

深層学習の発展によって人間の能力を超えるものが作られるかも知れません。しかし、それは人間が求めるゴールを実現するためのもので、ゴールを設定して深層学習の構造を作るのは人間です。

深層学習が話題になり出した頃、データを大量に突っ込めば答えを出してくれる様に勘違いしていました。でも、そんなうまい話は無く、良いものにするには人間の力が必要です。

エモーションチップが実現できるかどうかはわかりませんが、システムを作るのは常に人間です(今のところ)。ソフトウェアに関わるものとして、深層学習を野次馬的に眺めたり、変に恐れたりせず、ふさわしい場面があれば、ぜひ利用したいと思いました。

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

AAC & aptX 対応 Bluetooth イヤホン MDR-EX31BN - ZenPad 3s 10(Z500M) -

ZenPad 3s 10(Z500M)を買いました。液晶や重量は良いのですが、カメラとスピーカは普通の品質で、iPhone / iPad の方が良いと思います。

カメラは何ともなりませんが、音はヘッドホンやイヤホンで改善する事ができます。そこで、 Bluetooth イヤホン MDR-EX31BNを買いました(正確には以前のアダプタを飼い犬がかじって壊したので、aptX対応のものに変えました。涙)。

Bluetooth イヤホンの条件

iPhone 7の影響でBluetooth イヤホンの新機種がたくさん出ています。イヤホンケーブルやヘッドホンと一体化したものが多いですが、私の条件には合いません。

一つはヘッドホンにつなげられる様に、レシーバ部分が独立している事です。最近は少なくなりました。

もう一つは対応コーデックが、iPhoneのAACのほかAndroidで多い aptXがサポートされている事です。最近は入門機と称して SBCのみに対応しているものが増えましたが、音が劣化してしまうSBCにはもどれません。音の違いは私にもわかります。

SONY MDR-EX31BN

そこで見つけたのが SONY MDR-EX31BN(公式)です。このイヤホンはノイズキャンセリング機能を内蔵しているので、アダプタが少し大きく、価格も高めですが、上記2つの条件を満たしています。

ノイズキャンセリングをうまくするためか、SONY製にしては珍しく音に全く癖がなく、聞いていても負担がありません。もうしこし滑らかで、ドンシャリ的なパンチがあっても良いと思うほどです。

その分、ノイズキャンセリングは良い感じです。かつて使っていたノイズキャンセリングヘッドホンは、スイッチを入れると変な圧迫感がありましたが、違和感無く、電車などの騒音を消してくれます。仕事中に声をかけられても気付かないほどです。

ヘッドホンもつなげますし、イヤホン部分が壊れても交換可能です(ただし、マイクが無いのでノイズキャンセリングは効かなくなります)。

おわりに

私の考える条件は、誰にでも当てはまるものではありません。差し替えができなくても良いなら、他にも選択肢があるかも知れません。

でも、対応しているコーデックだけは、ぜひ確認してください。iPhoneはAAC、Android(ZenPad)は aptXです。

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


HDMIアダプタ USB-RGB3/H - Androidタブレット ZenPad 3s 10(Z500M) -

ZenPad 3s 10(Z500M)を買いました。ZenPad 3s 10 はマイクロHDMIがありません。しかし、使い出すとプレゼンぐらいはしたいものです。調べてみました。

Miracast と相性問題

最近のAndroid端末には MiracastというWiFiの帯域でワイヤレス表示する機能があり、 ZenPad 3s 10 の設定->もっと見る->PlayToから使えます。 ネットで調べていると、シャープAQUOSと接続できたらしいです。

そこで、評価の高い Lengee WD01を買いました。ZenPhone で動いたそうなので、これなら行けるだろうと、、。しかし、メニューは出るものの接続できませんでした。

念のためWindows 10のキーボードPCとつないでみると、音は途切れるものの画像はきちんと表示されました。音の途切れは、PCが5Ghzをサポートしていないので帯域が足りなかったのでしょう。不良品ではなく、相性の問題だった様です。

このような相性がある事や帯域不足の可能性を考えて、ワイヤレスをあきらめる事にしました。

ディスプレイアダプタ USB-RGB3/H +USBアダプタでバッチリ

次に目をつけたのがDisplayLink社のチップを使ったアダプタです。中でもIOデータ機器のPC用アダプタは、保証が無いもののAndroidでも使えると書かれています。

DisplayLink社のチップは「ぼくらは「USB-RGB」を誤解していたかもしれない (1/4) - ITmedia PC USER」にある様に、単純なバス変換ではなく、ロスレス圧縮する事でボトルネックを無くしています。

DVI-I/アナログ対応などの機種もあるのですが、音声も利用できるのでHDMI専用のUSB-RGB3/Hを買いました。つないでみると、AMAZON ビデオ、abema TV、youtubeなどの動画を見る事ができました。もちろん音声もバッチリです。ただし、 著作権保護が無いのでTverや民放系サービスは動画を見る事ができません。

なお、接続にはUSBのメスからUSB-Cに変換するアダプタを使いました。

USB-RGB3/H の注意点

前述の著作権保護の仕組みが無いほか、気をつけたい点があります。

本体の液晶が3:2ですので、HDMIの16:9の画面の左右に黒い帯が表示されます。その中に16:9の動画を表示すると、本体と同じ様に上下に黒い帯が表示されます。つまり、上下左右に黒い額縁がつきます。TVでズームして見ると良いかもしれませんが、プレゼンで動画を使う時は気をつけたい所です。

また、アダプタは短めのタバコの箱並に大きいですし、ケーブルも無骨な太さです。 iPhone/iPad用のHDMIアダプタと違って、常に持ち歩くのは辛いです。

まとめ

長々と書きましたが、著作権保護が無いなどの問題はありますが、 USB-RGB3/HならHDMI出力ができました。

動画が表示できたので、次はイヤホンです。

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


Androidタブレット ASUS ZenPad 3s 10(Z500M) - ケース、USB Type-C -

ZenPad 3s 10(Z500M)を買いました。最初の難関はケースとUSBの形状でした。

USB Type-C

はじめに戸惑ったのはコネクタがUSB Type-Cだったことです。新しい規格がでる度に新しいケーブルがついてきます。でも、持ち歩くには少し不便です。

そこで、Micro USB のケーブルに指す USB Type-C 変換アダプタを買いました。iPhone/iPadと違って単純な構造ですので300円しませんでした。充電用抵抗の入ったものがありましたが、他の用途にも使うので特に書かれていないものにしました。 今のところ、特に問題なく使えています。

これまで、iPhone用にMicro USBケーブルにLightning コネクタを挿して持ち歩いていました。しかし、取り外しをすると無くしそうなので、100円ショップで買った小銭入れに一緒に入れて持ち歩く様にしています。

手帳型ケースは重かった

持ち歩くのに不安なのでケースを探しました。オーソドックスな手帳型を探すと、どれも200g前後でとても重そうでした。そこで、アマゾンで最も軽い100gと書かれた
もの
を選びました。

しかし、実測すると199g!たぶん他のケースと間違えたのでしょうけど、430gの本体が1.5倍の重量に、、悲し過ぎます(通報とコメントしておきましたが、まだ残骸が残っています。同じように見えるものは1000円ぐらいからあります。orz)。

マグネット付きなので閉じると電源が切れて、平置きを含めて3段階に置けるので便利だったのですが、あまりに重いのでクリアケースと100円ショップのソフトケースを買いました(ダイソーのケースは裸での利用を想定しているようで縦がきつかったです。他店のものを使いました)。

評判の悪いホームボタン

クリアケースは100gないので2割程度重くなるだけで済みました。ソフトケースは手に持たないですが、ケースに入れても手帳型のケースよりはるかに軽くなりました。喜んで持ち歩いていると、なぜかバッテリーが0%!

そこで、気付いたのがホームボタンです。指紋認証機能のためかほんの少し出っ張っています。ネットで散々に書かれていましたが、その理由がわかりました。カバンの中でソフトケースに入れていても、押されてしまうのでしょう(手帳型はマグネットで電源が切れていたので問題がありませんでした)。

そこで、 細長いドーナツ状の外反母趾用パッドを本体に貼ってみました。うまくいったのですが、あまりにダサイ。黒く塗ったり小さく切ったりしましたが、人前で使うには抵抗がありました。

スリープケースの加工

そこで目をつけたのが、コペンハーゲンの100円ショップと話題になったフライングタイガーのスリープケース(800円)です。これは合成皮革性の縦長の封筒状のケースで、上部にバンドがついています。

このスリープケースはクリアケースのままではバンドが止まらず、留め具も堅いので、あまりお勧めできないのですが、加工して利用するのに最適でした。

ホームボタンはバンド幅よりも小さく、ケースの上端よりも下にあるので、本体側にボタン用の穴をあけて、バンドで上から塞ぐ様にしました。ケースの厚み分だけ、ホームボタンの上に空間ができます。

Case_2

バンドは使いませんのでケースの上端でカットし、瞬間接着剤でケースに張り付けました。穴の上部が細いので、バンドで補強する形です。これなら、見た目もスッキリです。

なお、スリープケースは通販で売っていないようです。入手が困難な場合はソフトケースを本体サイズに合わせて加工して遊びをなくし、内側に外反母趾用パッドを貼ると良いかも知れません。

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


Androidタブレット ASUS ZenPad 3s 10(Z500M) - 1st インプレッション -

ずっとiPhoneを使っていますので、何かと都合が良いのでiPad miniを使っていました。

便利に使っていたのですが、修理をしたものの、動画を長時間見ると再度壊れてしまいました。 Lightning コネクタの部品が半田だけで固定されているという 設計上の問題ではないかと思います。

ちょうどAndroidの最近のバージョンを知らないことが気になっていましたので、お勉強も兼ねて ASUS ZenPad 3s 10(Z500M)(公式サイト)を買いました。旧モデルなら安い機種もあったのですが、電子書籍に向いた解像度であることと新しいOSであることで選びました。Androidタブレットとしては高価格帯ですが、ちょうどiPad Air2対抗の価格と仕様になっています。

サイズは縦(長辺)が0.5mm大きいことと、ホームボタンとカメラレンズが突出している事を除くと、ほぼ同じか小さくなっています。実際に触ってみると思ったよりも小さく、結構軽く感じます。クリアケースを付けても521gでした。

Weight

そして、期待していた電子書籍を確認すると、画面が広くて読み易いほか、iPad mini 2の様に液晶がギラギラしていません。落ち着いた表示で見易く感じました。

iPadの方が良い点もありますが、一通りのことができて液晶も見易く、なんと言ってもNode-REDが使えるのは大きな長所だと思います。購入して1ヶ月、色々と人柱になりながらも環境が整ってきましたので、順にまとめていきたいと思います。

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


メンバーに良い成績を付ける - リーダーのベンチマーク -

リーダーがメンバーに良い成績を付けることができたなら、仕事をしている証です。ゆるい評価を与えるのであれば簡単ですが、適切な評価ができないならリーダー失格です。

リーダーの仕事は、 プロジェクトに与えられたリソースで最大の成果を出す事です。メンバーそれぞれの能力や性格を見極めて、場を用意して、能力を活かし、不足している能力を育て、必要に応じて補ったりします。

そこにはリーダー自身のリソースも含まれますので、雑用に追いまくられてボトルネックになる事は許されませんし、(すでに得意な分野なら若い人より優先度は落ちますが)リーダー自身が成長する事も求められます。

そのような多くの努力すれば、プロジェクトは良い成果を出す事ができるでしょう。そして、メンバーに良い成績を付ける事ができます。

もし、メンバーに良い成績を付ける事ができないなら、やるべきことをやっているか、一度、振り返ってみると良いでしょう。そうなってしまったのではなく、そうしてしまったのです(リスクを考慮した段取りで成功に導く)。

リーダーの仕事は、リーダーが自分勝手に思い描くプロジェクトを実現する事ではありません。うまくいく場合もあるかも知れませんが、リーダーもメンバーもストレスの溜まる職場になるだけで、能力は発揮できないでしょう。

日本では誤解の多いサーバントリーダーシップですが、メンバーに良い成績を付けるというベンチマークを使えば、うまくいくのではないでしょうか?

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

コールバック地獄よさようなら。Node-REDで非同期処理を使いこなせ!

Javascriptは非同期イベントドリブン処理が行える効率の良い処理系ですが、いわゆるコールバック地獄という見通しが悪くなる問題があります。Node.js上のビジュアル開発環境であるNode-REDは、機能モジュールであるノードをつなぐことで簡単に非同期処理を扱う事ができます。

ここでは、順次、 並列、待ち合わせといった基本的な処理をNode-REDでどのように書くかを説明します。

非同期イベントドリブン処理のイメージ

お湯を沸かしながらTVを見ることを考えてみます。やかんにお湯を入れて火をつけてアイロンを始めますが、アイロンに集中しすぎて空焚きになる事があります。

そこで、キッチンタイマーを1分ごとにセットして、タイマーがなるごとにチェックします。すると空焚きは防げますが、TVの内容がよくわかりません。マルチタスクは難しいのです。

では、やかんを笛吹きケトルに変えてみます。お湯が沸騰すると笛の音が鳴りますので、都合の良い所で火を消します。音が鳴るまでは気にせずにTVを見ている事ができます。

このように待ち時間がかかる処理の場合に、処理が終わるまでCPUを解放するのが非同期イベントドリブン処理です。タスク(計算機で言うとスレッド、プロセス、コンテナ)を定期的に切り替え無くても良いので効率的に計算機を使えます。

コールバック地獄

Javascriptはこのように効率的な非同期イベントドリブン処理の言語です。しかし、ケトルの笛にあたるコールバックを記述する際にネストが深くなるという欠点があります。

これは、コールバック地獄と呼ばれるもので、検索してみると多くの人が苦しんでいる様子が見えます。そこで、かつては async.js などの非標準ライブラリで順次処理や並列処理の待ち合わせが行われていました。

信じる者も救われるか微妙なPromise

Node.js v0.12 から Promise が標準で使えるようになりました。Promiseは処理の待ち合わせを実現するオブジェクトです。呼ばれた関数が先にオブジェクトを渡しておいて処理終了後にに状態を変える事で、オブジェクトを受け取った呼び出し側がコールバック処理に相当する次の処理が行えます。

Promise は良くできた仕組みで、コールバック地獄を無くします。しかし、少し複雑な処理を書こうとすると、Promiseアンチパターン - くじら公園 などを参考にウンウンうなる事になります。

また、Promiseはデータを受け渡す事ができますが、下流の方の処理に必要なデータを途中の処理すべてが受け渡さないといけません。全体の構造を考えたり、作り直すだけで疲れてしまいます。

そこでNode-RED

以前、このブログでも紹介した Node-RED はNode.js上で動作しますが、様々な処理を簡単に書く事ができます。

順次処理

ノードをつなぐと順次処理になります。前のノードの処理がreturnしたメッセージオブジェクトが、次のノードの入力となります。

Nr_5

結果:

Ans: 0

前段のファンクションノードの記述

msg.payload = 0; return msg;

同一データ個別並列処理

ノードの出力を複数のノードにつなぐと並列に実行されます。もちろん非同期ですので実行順序は保証されません(以降の並列処理も同じです)。

Nr_6

結果:

Ans: 0
答: 0

前段のファンクションノードの記述(新しいオブジェクトを作っていますが、順次処理の記述と効果は同じです。このフローでは問題ありませんが、msgオブジェクトの他のデータが引き継がれないので気をつけてください)

return {payload: 0};

個別データ個別並列処理

ノードの出力の数を増やすと、それぞれのデータが並列に実行されます。

Nr_7

結果

Ans: 0 答: 1

前段のファンクションノードの記述

return  [{payload:0}, {payload:1}];

個別データ同一並列処理(node.send)

ファンクションノードで node.send ()を使うと、複数のブジェクトを非同期出力できます。それぞれのデータが並列に実行されます。

Nrsend_2

結果

Ans: 0 Ans: 1 Ans: 2 Ans: 3 Ans: 4

前段のファンクションノードの記述

for (var i = 0; i < 5; i++) {     node.send({payload: i}); }

個別データ同一並列処理(split)

string, array, objectをsplitノードに渡すと、オブジェクトを分解してnode.send()できます(stringは区切り文字を指定できます)。インジェクトノードで配列を渡しています。

Nrsplit_2

結果

Ans: 0 Ans: 1 Ans: 2 Ans: 3 Ans: 4

待ち合わせ

splitノードで並列化した場合、joinノードで待ち合わせできます。msg.payloadのデータはまとめられます。

Nr_8

結果

[ "Ans: 0", "Ans: 1", "Ans: 2", "Ans: 3", "Ans: 4" ]

おわりに

Node-REDの様々な処理をまとめました。Node-REDは順次処理が基本になっていますので、javascriptに慣れていない方でも様々な処理を簡単に記述できます。

Node-REDはIoTの基盤として知られていますが、httpやwebソケットを含めて様々なプロトコルが扱えますし、Dashboardを使えば簡易なUIであれば簡単に作成できます。ちょっとしたテスト用のサーバなら、容易に構築できます。

Node-REDはJavascriptだからと敬遠されている方もおられるかも知れませんが、ぜひ一度、触ってみてください。

おまけ:非同期あるある

Node-REDのファンクションノードでAWS-SDKなどの非同期処理を呼ぶ場合、非同期処理のコールバック関数のreturnでは次のノードにデータを渡す事ができません。このような場合は、継続するノードが順次処理であってもnode.send()でデータを送ってください。

ちなみにAWS-SDKを呼ぶオーソドックスな方法は、settings.js内でrequireしたものをfunctionGlobalContextにセットしておいてファンクションノード内で利用します。

参考:https://nodered.org/docs/configuration#node-configuration

この記事は、SRA Advent Calendar 2016 の12月24日の記事です。

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

ポケモンGOで考えるリスクマネージメント(3/3) WF、アジャイル、CCPM

ポケモンGOは様々な要素が含まれるゲームです。タマゴの獲得機会喪失をリスクとして考えましたが、リスクへの対応は簡単ではありませんでした。

ソフトウェア開発にも様々な要素があり、それぞれが関連しているほか、時間によってリスクが変化するので、対応は簡単ではありませんでした。

そこで、ソフトウェア開発ではリスクへの対応を単純化できる様に、ウォータフォール(WF)、アジャイル、CCPMといったモデルが提案されています。

しかし、そのモデルから外れ出すとプロジェクトは大きな混乱に陥ります。つまり、リスクへの対応を単純化するはずのモデルにもリスクが存在しています。

今回は、仕様(スコープ)、納期、リソースの観点で、WF、アジャイル、CCPMを定義して、そこに含まれるリスクと対策を考えてみます。

ウォータフォール

ウォータフォールモデルは、開発が進んでからの修正作業が膨大である事から、開発の早い段階で障害を取り除きます。その前提は「要求定義」という工程がある様に、要求仕様が定義、さらに言えば凍結できることです。

開発開始時には仕様のほか、サービスインの前提となる納期が固定され、リソースを状況にあわせて投入します。

しかし、仕様を凍結する事は現実には難しく、仕様がどんどん追加されて混乱します。 仕様が膨らんでも納期は基本的に変わりませんので、リソースをドンドン増やすしてしまってプロジェクトが混乱し、最終的には納期が守れなくなります(CCPMが説明される際に、WFは仕様が固定で納期とリソースが可変と説明されることがありますが、現実はもっと混沌としています)。

このようなリスクに対応するには、リリース計画を見直すことと、仕様を調整します。具体的にはリーンスタートアップでいうMVP(必要最低限機能:Minimum Viable Product))を考慮して複数回リリースにする。各リリースでは仕様を削減する方向で調整する。ということです。

また、仕様のブレを無くすにはプロトタイピングが有効です。作ってみないとわからない所のリスクを低減します。

かつて組み込みソフトウェアでは、販売時がソフトウェアの最終リリースでした。不具合を出した社員が倉庫に連れて行かれ「この商品をどうするんだ」と怒られるような事があったそうです。しかし、プログラムを後から更新できる様になり、製造業においても仕様を削減して予定通りリリースしておき、次のリリースで対応するといった施策が実施される様になっています。

参考:

アジャイル

アジャイル開発にも色々ありますが、ここでは固定期間のタイムボックスを繰り返すXPやスクラムを想定します。XPやスクラムでは、タイムボックスを最小のリリースになる様に仕様を調整して、同じチームで開発します。つまり、納期、リソースが固定で、仕様を可変にして調整します。

タイムボックスを節目として新しく計画されますので、世の中の変化やビジネスのニーズに対応する事ができます。

しかし、一定の機能が必要とされる定型業務では、繰り返し回数が増えて期待される機能の実現が遅れる可能性があります。また、タイムボックスあたりのリソースは固定ですから、繰り返し回数が増えればコストも増える事にもなります。

実現される機能で見れば、アジャイル開発にはこのような問題があります。しかし、その見方は本質的でなく、ビジネスにどれだけ貢献できたかで評価すべきだと思います。

つまり、単発的な開発だと考えているので、時間軸が延びて予算計画が狂います。ビジネスを継続的に発展させる長期的なプロジェクトと考えれば、ビジネスとして成り立たせるために必要な機能から確実に実現できるかどうかが重要でしょう。

つまりアジャイル開発のリスク対策は、本来アジャイル開発に向いたビジネスに対して、きちんと開発するということです。

参考:

【12/21追記】

普及の著しいスクラムは、組織パターンの門番と防火壁の仕組みが組み込まれています。こればスクラムの長所であるとともにリスクでもあります。

具体的には、プロダクトオーナーがボトルネックになる。SMがチーム作りに失敗するとコミュニケーションがうまくいかず情報共有に失敗する。といったことです。

対策は教育、コーチ、コンサルタントの導入などがあります。

CCPM

CCPMはサブチームや個人で取ってしまいがちなバッファに注目し、理想見積もりをベースに計画し、プロジェクト全体でバッファを取る。クリティカルチェーンにリソースを集中する。状況を可視化する。ことで効率的な開発を実現します。

バッファを取って時間軸の自由度を高める事で、個人やサブプロジェクトのバッファを無くして全体で最適化しますので、仕様とリソースは固定、 納期は可変になります。

CCPMを実施する事でプロジェクトの生産性が上がる事が知られています。しかし、バッファ削減の効率化は、必ずしも継続しません。CCPMは分散していたバッファを集中管理する事で効率化するので、一度適用すれば、習熟による生産性の向上以外は見込めなくなるからです。

にもかかわらず効率化を前提にリソースを削減して、クリティカルチェーンにリソースを補う事が難しくなり、CCPMが機能しなくなることがあるようです。

初めのうちは理想見積もりが難しいので、通常見積もりからざっくりと理想見積もり計算するかも知れません。しかし本来のやり方である、きちんと理想見積もりをした上でバッファを設定しなければ、いずれうまくいかなくなるかもしれません。

参考:

まとめ

新しい開発モデルがはやると「守破離」と言う言葉が使われます。まずは言われた通りにやってみる。ということなのでしょう。

しかし、現実はどのような開発モデルであってもリスクはあります。ここに挙げた3つのモデルも、仕様、納期、リソースのそれぞれが固定のものが可変になったり、可変のものが固定になるなど、本来のモデルを表層的にとらえただけでは理解できない問題が生じます。

ソフトウェア開発は複雑な仕事です。何かに書かれた通りに実施するのではなく、本質的な内容を理解し、想定されるリスク、そのバランスと時間による変化を考えないとうまくいきません。

ソフトウェアエンジニアリングがソフトウェア工学のテキストに書かれた事を実践するだけではない様に、リスク管理のテキストに書かれた事を実践するだけではリスクマネージメントできないと思います。

ポケモンGOのリスクに基づいてここまでの議論を進めてきました。ゲームの上手な人と下手な人がいる様に、ソフトウェア開発にも上手な人と下手な人がいます。その違いは、リスク特定、リスク分析、リスク評価からなるリスクアセスメントとリスク対応から構成されるリスクマネージメントへの理解かもしれません。

参考:

この記事は、SRA Advent Calendar 2016 の12月19日の記事です。

おまけ

ポケモンGOでは相棒ポケモンを選ぶ事ができ、歩いた距離に応じてアメをもらう事ができます。ついつい短距離でアメがもらえるポケモンを選んでしまいます。

しかし、無駄のないように相棒を選ぶなら、(1)アメをもらうのに距離が必要、(2)進化に多くのアメが必要、(3)なかなか出逢えないレアなポケモン、から選ぶと良いと思います。また、出逢う可能性を考えて必要なアメの数よりすこし少ない数まで歩くと良いでしょう。

ナップザック問題の様に距離の異なるポケモンを最適に進化させる事は困難です。グリーディアルゴリズムの様に距離の必要なものから選ぶと良いでしょう。また、ポケモンを捕まえられる可能性も考慮すると、少し少なめにすると良いことがわかります。

このようにポケモンGOとソフトウェア開発は、共通点がたくさんあります。真面目に考え過ぎて負担にならない様にしてください。ゲームなので楽しめば良いのです。仕事と同じです。

参考:

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

ポケモンGOで考えるリスクマネージメント(2/3) ソフト開発にあてはめる

前回はポケモンGOを題材にリスクマネージメントにおけるリスク対応の説明をしました(ポケモンGOで考えるリスクマネージメント(1/3) リスク対応の種類)。

リスクへの対応は問題の発生する確率と発生時の被害の積(リスクレベル)で考えられます。しかし、ポケモンGOのリスクをソフトウェア開発にあてはめると、それは簡単なものでないことがわかります。

共有(または転嫁) は難しい

ポケモンGOでタマゴの獲得機会喪失をリスクとして考えて、このリスクを家族に転嫁することを考えました。しかし、リスクを共有するには、スマホのパスワードを公開して操作してもらう必要があり、得られるメリットに相当する金品(あるいはサービス)を提供する必要があるでしょう。

ソフトウェア開発でも同じです。レベニューシェア契約(リンク先はWikipedia)など得られた収益から報酬を払う方法があります。発注側の利益は明確ですが、受注側が適切に利益を得るには計画だけでなく、より詳細な情報提供が必要ですし、運営に発言権が必要になります。

そこで、ポケモンGOで歩く事だけ依頼した様に、品質と納期へのリスク回避に対して一定のコストを払う契約が一般的に行われています。

では内製ならうまくいくかと言うと、必ずしもそうではありません。実は内製であってもゴールが共有できていなければ、担当者の価値観に応じて判断が行われる事になります。評価を気にしない社員もいますし、そもそもそれなりの職位でなければ、収益を評価にあまり反映できないでしょう。

結局、契約も大切ですが、それだけでは不十分なのです。業務を理解して、そこで生じるリスクの低減を共に考える事が必要になります。

リスクには依存関係がある

ポケモンGOのタマゴの獲得機会喪失を考えましたが、これを回避するには常に孵化装置を買う必要がありました。獲得機会を失う事がどの程度の金額に相当するかを考えて、一定のリスク低減であきらめる事になるでしょう。

このように、リスクレベルに応じた対応をすれば良いのですが、実は単純ではありません。

ポケモンGOには「しあわせタマゴ」という30分間得られるXPを2倍にするアイテムがあり、レベルアップ時にもらえたり、購入する事ができます。

Fukasouchi

進化させた時やタマゴをかえした時にもXPがもらえますので、アメが貯まったら同時に孵化装置をセットします。孵化の直前に「しあわせタマゴ」を使って一斉に孵化させ、貯めておいたアメでまとめて進化させると、多くのXPを得る事ができます。

しかし「しあわせタマゴ」を有効活用するには、孵化装置を使わずにタマゴを残しておく必要がありますので、(よほど運が良くない限り)タマゴの獲得機会を失わないとタマゴを揃える事ができません。

つまりリスクに依存関係がある場合は、いずれかのリスクの問題化による被害を 保有(または受容) する必要があります。

基本的には、それぞれのリスクレベルを計算して優先度を決めれば良いはずです。しかし、次に示す様にリスクレベルが時間によって変化するなら、単純に優先度を決める事ができません。

ソフトウェア開発でも、 スケジュール遅れを取り戻そうと残業を強いると品質の低下が生じる可能性が高まるなど、 リスクの依存関係が多く存在します。

時間によって変化するリスクレベル

ポケモンGOにおいて「タマゴを獲得できないことで時間を失うリスク」を議論してきました。ポケモン図鑑を揃えるにはタマゴをかえしてレアなポケモンを得る必要があるからです。

しかし、時間を失うようなレアなポケモンとは、図鑑に載っていないポケモンの事です。レアなポケモンをどんどん捕まえれば初めてのポケモンが減ってゆくので、たくさんのタマゴを獲得する必要があります。ソフトウェア障害の信頼度成長モデル(SRGM)のようにサチッていく(リンク先はgoo辞書)イメージです。

その一方で多くのXPを獲得してレベルを上げると、新しいアイテムが使える様になって進化したポケモンを捕まえ易くなります。実際は次のレベルに上がるのに必要なXPも多くなるのですが、新しいポケモンの減り方に比べると直線的な変化です。

参考:「ポケモンGO(Pokémon GO)」のレベルアップに対するユーザーの不満が噴出、課金なしでは難しいという声も - GIGAZINE

つまり、図鑑が埋まってくるとタマゴを得る価値が下がり、孵化させてXPを得る方が効率的になります。つまり、時間によってリスクレベルが変化して、対策の優先順序が変わるのです。

ソフトウェア開発でも同じです。関連するモジュールが多い機能は手戻りのが生じた場合の被害が大きく、開発初期では、手戻りのリスクレベルは開発が遅れてしまうリスクレベルよりも高いでしょう。しかし、開発が進んでくると手戻りのリスクレベルよりも開発が遅れてしまうリスクレベルが徐々に高くなるでしょう。

この2つのリスクレベルが入れ替わるタイミングが、いわゆる最終責任時点です。リスクレベルを下げられる様に、ギリギリまで選択肢を残します。

参考: リーンソフトウェア開発 - 決定をできるだけ遅らせる

おわりに

ポケモンGOにあてはめて、ソフトウェア開発のリスクマネージメントを考えました。ソフトウェア開発のリスクマネージメントも、決して簡単ではありませんでした。

それぞれに対応する状況の様に、請負開発や進捗管理だけでなく、そもそもリスクを考慮しなければ良い計画を立てる事ができません。

このようなリスクマネージメントの視点で考えると、ウォーターフォール型開発だけでなく、アジャイル開発やCCPM(Critical Chain Project Management)の弱点や対策が見えてきます。

次回は、その辺りを書いてみたいと思います。

この記事は、SRA Advent Calendar 2016 の12月11日の記事です。

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

«ポケモンGOで考えるリスクマネージメント(1/3) リスク対応の種類