無料ブログはココログ

標準は諸刃の剣

標準と聞くと仕事を楽にするもの、組織に必要なもの、 あるいは、 面倒臭いもの、 厳しいもの、と考える方がおられるかも知れません。これはどちらも真っ当な意見で、標準には良い面があるものの、悪い面もあります。

標準の効果

ここで参考になるのはプロセスモデリングのゴールでしょう([#TiDD]失敗しないチケット駆動開発 - プロセスモデリングの視点から+告知 -)。標準を理解し、共通の行動を前提に改善し、必要な作業が行われているか管理し、ツールによる自動化やガイドできます。

つまり開発者を支援して、一定のレベルへの底上げや組織的な改善が可能になります。

思考停止の罠

組織活動に便利な標準ですが、思考停止に陥りがちです。厳しく管理することで標準に従うことに集中してしまい、より良いものを追求しなくなってしまいます。また、柔軟な開発ができなくなるので、 開発の負担になって生産性が低下してしまうこともあるでしょう。

より難しい問題は、技術者の成長を止めてしまうことです。実際に大規模開発でうまくやっていた人が、小規模で比較的自由な開発でプロジェクトをうまく管理できないこともあります。なぜその標準が必要なのかをキチンと理解していなかったのでしょう。

良い標準

このような問題が生じにくい標準を考えてみます。標準で全てを縛るのではなく、その重要度によって規則、推奨、参考情報に分けると良いでしょう。単純な共通化ではなく、判断条件と共に複数の選択肢を示します。

良い標準は学びになります。その標準がなぜ良いか、どのような条件で有効か、その理由が説明されているなら、標準に振り回されること無く、自ら判断して実施できるでしょう。

標準を活かすには

どんなに良い標準でも、言われるままに実施しているのでは仕事をこなしているだけです。確認が可能なら、きちんと原本を読んでください。思わぬ発見があるかも知れません。

標準はそれぞれの組織や業務に応じて決められたものですので、定められた制約を守らないといけません。反面、制約を守っていればそこに工夫の余地があります。ソフトウェア開発と同じです。

(参考)詳細設計書を後回しにした話:Win-Winプロセス(ウォータフォール編)

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

決定をできるだけ遅らせる -「現場で役立つシステム設計の原則」深読み -

増田さんの「現場で役立つシステム設計の原則」に関して様々な議論があり、私も立食とコース料理 -「現場で役立つシステム設計の原則」批判の一考察 -を書いたあと、様々な議論をさせていただきました。私なりの本の読み方が見えてきたのでまとめておきます。

この本はアジャイル開発(以下アジャイル)がベースになっていると思います。特にリーンソフトウェア開発のプラクティスである「 決定をできるだけ遅らせる」(リーンを考える - 無駄と必要なアソビ -) の考え方が透けて見えます。

この考え方は上流工程をもつ従来の開発方法(ウォーターフォールと呼ぶとリリースが1回とか工程間で判定会議がいるとされることもあるのでこう表現します、以下、従来法)とは大きく異なる考え方です。

従来法の考え方

従来法で上流が重視されます。これは、ベーム先生の後工程になると修正工数が指数的に増えると発表されたからです(「要求は変化する。Boehm は間違っていた、と DeMarco が暴いた。」というYourdon のブログ:An Agile Way:オルタナティブ・ブログ)。後工程になれば修正が大変だからと上流工程で頑張ることで、開発のリスクを減らそうとした訳です。

話はそれますが、ベーム先生はその後の繰り返し開発やアジャイル開発につながるスパイラルモデル(リンク先はWikipedia)を提唱されたり、後述の「アジャイルと規律」を執筆されるなどアジャイル開発に貢献もされています。IEEE Softwareの紙面でケント・ベックさんとXPについて議論されていたので、からかわれたのじゃないでしょうか。

決定をできるだけ遅らせる

話を戻して「決定をできるだけ遅らせる」というのはYAGNI(You aren't gonna need it)に通じる考え方です。従来法とは逆に、変更の可能性を考慮して、どうしても決めないといけない時(最終責任時点)まで決定遅らせるというプラクティスです。

例えば車のドアのところのデザインがかわる可能性がある場合、ドア部分の金型を削ってしまわずに少し残しておくといった対処で、後から変更が生じた際に調整できるように決定を遅らせるというプラクティスです。すべての事を決定しておかずに余裕を持たす事で、選択肢を残せます。

従来法のソフトウェア開発に置いても、決めきれない内容はペンディング、TBD、TODOなどといって後回しにしたり、手軽な方式に仮決めしておきますよね。それを時間切れだからとあきらめてするのではなく、変更の可能性を意識して選択肢を残す目的で実施するようなイメージです。こうすることで多大な手戻りのリスクを減らします。

「現場で役立つシステム設計の原則」の深読み

このような視点で読むと、仮決めする際のデフォルトが示されているように思います。オブジェクト指向はこう理解して、こう言う風に考えるとうまくいく、短いイテレーションも乗り切れるよ。という風に読めてきます。

上記は私の勝手な忖度ですが、増田さんの講演資料にある批判に対する回答を読むと、増田さん自身も決定を遅らせる考え方をもたれていることがわかります(現場で役立つシステム設計の原則)。

この5ページの「すべてのカラムが Not Null は非現実的?」に対して「実際にやっている、特に困っていない、SQL のスキル+ IDE サポート」という回答からも、決定を遅らせるスタンスが感じられます。

批判を考える

このように考えた上で、この本に対して書かれている批判を考えると、とても良い指摘ではあるものの、「決定をできるだけ遅らせる」こととと対極にある「はじめのうちからしっかり作る」ことを勧められている様に思います。

もちろんリスクを減らす目的で決定をできるだけ遅らせているのであり、「はじめのうちからしっかり作る/設計する」方がリスクが減るのであれば、実施すべきでしょう。

kent4989さんのブログ勘と経験と読経でその方法が紹介されていました(アジャイルとデータモデル、DB進化設計のこと)。アジャイルにこだわるならイテレーションゼロで吸収する。それ以外なら前段階で供給開発、あるいは、RUPなどの反復開発手法の併用を勧められています。最近ではたなかこういちさんが、アジャイルでスタートアップも、軌道に乗ったらUPへ移行すべきときが来る、というものかもしれないと言われています。

2017/9/8追記
アジャイルにこだわる方法としてFDD(リンク先はWikipedia)もあります。
[#Agile] FDDはアジャイル開発、ハイブリッドアジャイルは、、
[#TiDD] 手分けするより助け合い - FDDとチケット駆動開発 -

2017/9/14追記
この本の特徴の一つは決定を遅らせる際のシンプルなデフォルトを示していることです。イテレーション(スプリント)をうまく回せるか不安だった方や、ベロシティ(開発速度)が上がらなくて困っていた方には、大いに参考になるでしょう。

その方法は独特です。批判の多くは一般的な方法を主張し、その良さを指摘したものです。批判の実践はこの本に書かれたシンプルさを損ないますので、どちらを優先すべきか良く判断すべきだと思います。

もし、批判を読んで今までの開発が不十分で問題だったと思われるなら、批判は一部だけを示したものですので、より広く検討して上述の実施方法などを検討する必要があるでしょう。

アジャイルにこだわるかの判断

批判を別にしてもアジャイルにこだわるべきかどうかは考えておく必要があります。平鍋さんのブログデータモデリングなきアジャイル開発は危ういか?では、プロジェクトや製品の文脈によって変わるとされていますし、上述のたなかこういちさんのブログでも「バックオフィス側の管理業務」など業務が大きな要素であることは間違いないと思います。

一方、ベーム先生の「アジャイルと規律」ではアジャイルの5つの重要要因として、規模、重要度、 変化の度合いといった業務に関わる要員のほか、人、文化が挙げられています。

人に依る違い

設計に関して渡辺さんが「システム設計と創造性」の中で“まずは「システムが扱う現実の全体をぼやーっと理解する」ことを目指せばよい”とされていて、私もそうしています。

しかし、ふと思い出すと小学生のことです。私は作文の時間の半分以上をあーでもない、こーでもないと書く内容を考えていました。成績は悪くはなかったのですが、私よりもできる人の中には、作文の時間にすぐに書き出す人もいました。設計でも同じ様に人によって作りながらの方がうまくいく人がいるかも知れません。

そう思うと、書籍アジャイルサムライに

と書かれていたことが設計にも言えるのではないかと思います。

おわりに

増田さんの本に関しては、上記のような視点でとても興味深く読ませていただきました。できれば、続編あるいは改訂版のような形で、アジャイルとリファクタリングによる進化のさせ方について、もっと書いていただければと思っています。

なお、個人的なアジャイル開発に関する考えは、[#Agile] アジャイル開発の課題と対策 その1に書いています。現場でスクラムやXPの様なタイムボックス型管理をしているアジャイル開発はしていませんが、いわゆるモダンアジャイルを実践しているつもりです。

2017/9/8追記

アジャイルマニュフェストはオブジェクト指向の有名人が集まって決めたので、なるほどと思いました、サブタイトルからもオブジェクト指向からの説明の方がしっくりくるかも知れません(私には書けませんが)。

これに関連して「アジャイルプロセスでは、本質的なデザインやアーキテクチャに関する意思決定をできるだけ遅らせることができます。」というマーチン・ファウラー氏の言葉を見つけてニワトリとタマゴの関係だと思いました。

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


[#Node-RED] 7〜8分でわかるファンクションノード

Photo

Visual IoTツール Node-REDには、データセットや基本的な制御構造がありますので、簡単なプログラムならコーディングなし(設定だけ)でプログラムを書くことができます。

しかし、少し複雑な処理になるとファンクションノードが便利です。ファンクションノードはjavascriptでコーディングできますので、複雑な処理をフローにまとめることができ、シンプルなわかり易いフローが書けます。

1.基本

まずは基本的な内容から。

1.1 名前をつけよう

ノードには日本語で名前を付けることができます。処理内容を表す名前を付けておくとフローが読み易くなります。「XXに変換する」「msg.cnt++」などわかり易い名前を付けてください。

1.2 入力は最大一つ、出力は複数可能

ファンクションノードの入り口は一つだけです。デフォルトの出力は一つですが、下部にある出力数を変更して増やすことができます。出力が複数場合は戻り値を配列で返します。出力しない出口にはnullをセットします。条件によってどれか一つに値を出力するだけなら、スイッチノードに渡した方が、修正が楽な場合もあるでしょう。
(追記:バージョン0.17以降では端子に名前をつけるとマウスオーバーで表示できますので、入出力などをわかり易く書いておくと良いでしょう。)

1.3 javascriptでコーディング

内蔵エディタはjavascript構文を理解してエラーやワーニングを表示してくれます。Node-REDが動作するNode.jsのバージョンの文法で記述します。msgオブジェクトを受け取って処理し、リターンバリューがmsgオブジェクトになります。

2.あらかじめ定義されたオブジェクト

msgオブジェクト以外のあらかじめ定義されたオブジェクトを説明します。

2.1 グローバルオブジェクト

プログラム全体で利用可能なグローバル変数が使えます。
global.get(‘オブジェクト名’)で取得し、 global.set(‘オブジェクト名’,値)で値を設定します。現在は永続化されないので、再起動で初期化されます。

2.2 フローオブジェクト

タブ内で有効なフロー変数もあります。
flow.get(‘オブジェクト名’)で取得し、flow.set(‘オブジェクト名’)で値を設定します。
永続化されないので、再起動で初期化されます。

2.3 node.send()

一つの出口に複数返す場合や、無名関数内で終了する場合は、returnでなく、 node.send(msgオブジェクト)を用います。returnは最後の一度死活変えませんし、無名関数内のreturnは全体の戻りではないからです。

2.4 require は setting.js で

ファンクションノード内で requireできません。requireが必要な場合は、ユーザーディレクトリ( ホームディレクトリ/.node-red)のsetting.jsのfunctionGlobalContextにrequireを追加します。Node-REDを再起動すると、設定したオブジェクトを global.get(‘オブジェクト名’) で取得できます。もちろん、必要に応じてユーザーディレクトリで、モジュールをnpmインストールする必要があります。

3.オブジェクトの管理

簡単に見えるNode-REDプログラミングですが、意外とハマるのがオブジェクトの管理です。

3.1 msg.payloadは基本

標準的な出力はmsg.payloadですが、破壊されることも多いです。payload以外のプロパティを使えば多くの場合は大丈夫です。しかし、新しいmsgオブジェクトが生成される場合は、フロー変数やグローバル変数を使います。

3.2 新しいmsgオブジェクトで返す

受け取ったmsgオブジェクトを渡したくない場合は、「return {payload: 値};」とすると新しいオブジェクトのmsg.payloadとして値を返すことができます。ただし、後続の処理で、受け取ったmsgオブジェクトの値を渡せないので注意してください。特にhttp inが出力するmsgオブジェクトには、http responseに必要な情報が含まれますので注意してください。

3.3 コピーされるオブジェクト

「return [msg, msg];」のようにmsgオブジェクトを複数同時に返すと、オブジェクトッがコピーされ、異なるオブジェクトが渡されます。また、一つの出口から複数のノードに繋いだ場合もコピーされます。大量データを扱う場合には注意してください。新しいmsgオブジェクトを生成するか、node.send()で出力すると参照が渡されます(参照を渡すと想定外に内容が破壊されてしまうことがありますので注意してください)。

4.おわりに

簡単に始められるNode-REDプログラミングですが、ドキュメントをきちんと読んだり、色々試さないとわからないことがあります。ここに挙げた内容がわかっていれば、少し複雑な処理もスラスラと書けると思います。

詳しくは、公式ドキュメント(英語)の確認や、実際に動かすなどしてください。それでも困った時は、ユーザー会slackやメーリングリストなど(英語)で聞いてみると良いと思います。

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

アジャイルジャパン大阪サテライト2017の感想

SS2017のポストイベントがなくなったので、 急遽スタッフとして参加しました。


(1)キーノート:シンアジャイル(Joshua Kerievsky)

モダンアジャイルについての説明。タイトルはAgileJapan2017のタイトルにあわせて変更されたようです(シン・ゴジラをまねた?)。

個人的にアジャイル開発のタイムボックス管理は、作業タイミングを固定化するので超短期開発にはフィットしないと思っていました。Kerievsky氏は早くからタイムボックスを守るよりも顧客のメリットを考えようと言われていたそうです(そのとおり!)。

提案する新しい4つの原則は従来のアジャイルマニュフェストに対応しながらも、顧客やソフトウェアの安全性に配慮したものでした。

講演概要
http://www.agilejapan.org/session.html#session01

Agile 2016の基調講演: モダンアジャイル
https://www.infoq.com/jp/news/2016/08/agile2016-modern-agile

チェンジビジョン/英和システム 平鍋さんの説明
https://anagileway.wordpress.com/2016/10/07/modern-agile-jp/


(2)ヴァル研究所 新井さんの講演

アジャイルを社内に広げる際の話。みんなが積極的になるように色々と工夫された中で、権限(部長)があるので、一部の活動が社内評価と連動するようにした。と言われていたので懇親会で質問させていただきました。

質問は、社内の仕組みと連動すると、義務感ややらされ感が出ると思うが、どのようにバランスをとられているか?

答えは、社員には積極的なできる人と、受身の人と両方いて受身の人も働いてもらわないといけない。ルールを決めても相手によって変えている。とのこと。

つまり、ルールはがちがちにせず、運用時に人を見て、たぶんチームによっても変えているのでしょう。エンジニアは、ついつい一貫性が気になりますが、個人個人を良く見ると言うことが重要だと思いました。

ちなみに、「上から見てなので、みんながどう思っているかはわからないですけどね。」と謙虚に言われていたのが印象的でした。


(3)コニカミノルタの久保さんによるエモイ話

人はなぜ生きているのか?それは人生を楽しむためである。

なぜ苦しみがあるのか?それは、いつかより人生を楽しめるからである。

いい人である必要は無い。人の顔色ばかり見る必要は無い。わかってあげるだけでいい。

そう、生きているだけで素晴らしい。

そう思いました。

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

Node-REDから見えた未来 - 変わるもの、変わらないもの - SS2017 WG13

ソフトウェアシンポジウム(SS2017)では、前回紹介した論文発表のほか、ワーキンググループにも参加しました。

ワーキンググループでは各グループのテーマに沿って、参加者がそれぞれのポジションを発表して議論します。私が参加したのはWG13「ソフトウェア開発の現状と今後の発展に向けたディスカッション」で「Node-REDから見えた未来 - 変わるもの、変わらないもの -」を発表しました。

Node-REDは高機能なノード(モジュール)がたくさんあり、それらを組み合わせて高機能なシステムを効率的に開発できます。また、簡単にデバッグできるほか、デプロイが一瞬で、開発から確認の繰り返しを素早く実行できます。

このような環境を使っていると、面倒臭いことがなくなり、ソフトウェア開発に重要な作業を中心に実施する様になります。この重要なことはみなさん合意できますよね。という発表でした。

しかし、Node-REDのデモのインパクトが大きかったのか、Node-REDに対する質問で持ち時間が終わってしまいました。Node-REDを知ってもらえたので、良かったことにしておきます。

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

Visual開発ツールNode-REDの導入によるプロセスの変化と考慮点 - SS2017 -

ソフトウェアシンポジウム2017(SS2017)で経験論文の発表をしてきました。経験論文とは研究論文の様に新規性はないものの、事例報告の様に経験を報告するものですが、問題設定や結果・考察を整理してより有効性や信憑性を高めて論文にまとめたものです。

今回はVisual IoTツールと呼ばれているNode-REDのアンケート結果を報告しました。ソフトウェア開発にツールは欠かせませんが、その導入報告はあまりありません。上流のツールであれば、コンサルタントに依頼することもできるかも知れませんが、下流のツールは小さい規模から始めることが多く、導入経験は他の人にも役に立つと思ったからです。

発表ではNode-REDの基本、長所・短所の説明と共にデモもしました。基本的な Hello World のノードを入れ替えてPathをセットするだけで、そのビジネスロジック(文字列の代入)をそのままWebサービスにできる様子をお見せしました。

このようにNode-REDは確認しながら開発するので短期間に品質の高いソフトウェアを作ることができ、アンケートにもある様に非同期処理が簡単に扱えます。その反面、ある程度の規模になれば、データやアーキテクチャなどの設計をきちんとしておかないと複雑になってしまいます。

そういった知識を持ち、ふさわしいプロセスで開発しないとうまくいかないことがアンケートからわかりました。まとめると

  • ツールの知識やノウハウを共有 する
  • 特性を活かした設計を行う
  • 実装を繰り返して常に確認する
  • 主体的にプロセスを変更し、品質 を上流から作りこむ

となり、これは、モダンアジャイル

  • 人々を尊重する
  • 安全な状態を前提とする
  • 素早い実験と学習
  • 価値を継続的に届ける

の基本理念と対応していて、Node-REDの良い導入が開発のアジリティ(機敏さ)を高めると考えられます。詳しくは以下の論文を読んでください。
(実は最終原稿の段階でモダンアジャイルの基本理念と対応していることに気付いたので追加しました)

Node-REDから見えた未来 - 変わるもの、変わらないもの - SS2017 WG13 につづく

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

複合主キーの扱い方

緊急開催:複合主キーは必須なのか?<第55回IT勉強宴会Light> に参加しました(主催者まとめ)。

議論の発端は渡辺幸三さんの「単独主キー専用環境」と賢くつきあうためにという記事。

乱暴に説明すると「データベースではきちんと複合キーを使うべきだ。OOPだからといってカスケードキーでいい加減に作るから、あとでわからなくなって保守ができなくなるんだ。ばかやろう!」ということ。

ここにはいくつか議論をしないといけないことがあります。一部追記したスライドを元に説明しましょう(追記部分は灰色の小さい文字になっています)。


RDBだから複合キーを使わずにできてしまう

渡辺さんのブログを読んでいると、RDBなのになぜ複合キーを使わないのか、という気持ちが透けて見えます。でも、実は多機能なRDBだから複合キーを使わずにできてしまうのではないでしょうか?

複合主キーを持てないKVSや連想配列があります。これらを使うとき、シーケンスの管理が
難しいこともあり、「キー1_キー2」のようにして開発しています。

このことから考えると、RDBなのに複合主キーを使わないのではなく、RDBだからサロゲートキーを作りやすいので、複合キーを使わない開発が簡単にできてしまうのだと思います。

つまり、単独主キーで開発を安易に行うことが問題です。

本来、複合主キーで表現されるデータをどう扱うかは、モデリングの問題ではなく実装の問題です。

複合主キーを使わないのは実装の都合なので、そこにある危険性を周知することが重要だと思います。

(もちろん、、モデリングしているのはあたり前としてです)


オブジェクト指向だから単一主キーとは限らない

渡辺さんのブログでは「OOP好きからは『テーブルに別途ユニーク制約を置くなり、クラスの中に制約のためのロジックを盛り込むなりすればよいだけではないか』と反論されそうだが、」と書かれていますが、それは時代に流されている人ではないでしょうか?

オブジェクト指向システム分析―上流CASEのためのモデル化手法には「オブジェクトのそれぞれのインスタンスを唯一に識別する1以上の属性の集まりは,そのオブジェクトに対する識別子です。」と複合主キーを認めています。

ソフトウェアを開発する場合、様々な視点で特徴や制約をモデリングしないとシステムの詳細は表現できないと思います。複雑な要素を如何に矛盾なく、いかにわかり易く統合していくかが設計者の腕の見せ所では無いでしょうか。


保守性の考慮

もちろん、実装の都合でモデルと異なる方法をとったり、モデル自体を実装に最適化することもあるでしょう。しかし、その場合は注意深く開発する必要があるでしょう。

渡辺さんのブログには「複合主キーを扱えない」という環境自体の特性ゆえの問題が書かれています。

  • エンティティのまとまりやそれに適用される複雑な制約が、開発者自身によって見い出されない
  • 使いづらく保守しにくい業務システム開発が生まれる
  • 単独主キーだけを用いた設計スタイルに逃げ込んでも、問題が見えにくくなるだけで事態はさらに悪化する

つまり、きちんとモデリングされず、保守しにくいシステムが作られ、どんどん深みにはまってしまいます。

このように考えると、複合主キーを使ったモデルそのままに実装できるならDBを見ればわかるかも知れませんが、モデルと異なる実装ならモデルからどのように実装に持ち込んだかわかる様にしておかないといけないと思います(もちろん、モデリングしている前提です)。


おわりに

渡辺さんの主張をより単純化すると「バグを出すなバカやろう」だと思います。

なぜ、バグが出るか、それは「複合主キー環境でないから」ではないと思います。たぶん、複合主キーが使えても同じようなDB設計をするのではないでしょうか?

もし、きちんとモデリングができるなら、本来必要な制約を理解し、わかり易く制約を実装し、必要ならドキュメントも作成するでしょう。

「もともとDB設計というものは高度な専門職」とは思いません。もし、そうなら、ソフトウェア開発のインタフェース設計、システムチューニング、保守、運用、すべて高度な専門職です。

エンジニアリングは一定の努力で誰もが習得できる専門知識です。きちんと勉強して、危険性を理解すれば良いと思います。

問題はすでにできてしまったお客様のシステムをどうするかです。危険性を考慮せずに勝手な思い込みで作られたやっつけシステムは、問題が起きた際は大変だと思います。作り直したくても予算も期間も無いからです。

担当される方のために祈らずにおられません。

彼らをお赦しください。自分が何をしているのか知らないのです(ルカによる福音書/ 23章 34節、日本聖書協会)

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


考えろ、理解しろ、整理しろ

渡辺幸三さんのブログ:設計者の発言を読んでいて感じたこと。

日々の仕事をする中で口うるさいと思われても、年長者の務めなのできっかけを見つけては指導している。色々と言っているが、だいたい以下の3つに集約できるだろう。

考えろ

指示されたままに仕事をしたり、いつも通りで良いと思っていないだろうか。

渡辺さんの「論理削除」ではなく「無効化」をスタンプ属性や更新履歴テーブルの無駄っぽさを読んでいると、習慣ではなく考えて仕事をすることの重要性を感じる。

より良い方向を考えても、全体との調和の問題で実施できないかもしれない。しかし、きちんと考えてシステムを作り上げることはとても重要だ。次の仕事に活かせるからだ。

なぜかを理解しろ

学部の恩師の言葉で忘れられないのが「職人になるな勉強を続けなさい」という言葉(社内勉強会より社外の勉強会)。知っているだけではなく、きちんと理解していなければ技術者とは言えない。

人に聞いてわかったつもりで仕事に使い、うまくいったらそれでおしまい。それは技術者でも職人でもない。ただの人工(にんく)に過ぎない。

ものごとの原理は何なのか、その人はどうやって情報を知ったのか、広い目で深く理解していれば、自己流ではないより良い方法が選択できるだろう。

整理しろ

世の中のできる人を見ていると、常に考えて仕事をし、より深く理解しているだけでなく、情報を整理してコンパクトに理解している(できる人を観察して勝負する

得た知識はそのままにしておけば忘れてしまうし、量が増えれば大変になる。知識を活かしてステップアップするには、これまでの知識との関連を整理しておく必要がある。

体系化できていればすべてを覚えておく必要はない。どの資料に書いてあるかを知っていれば、いつでも確認できるからだ。経験のインデックスを作るのだ。

おわりに

世の中には新しい情報があふれているが、実は似たような議論を繰り返していることも多い。

渡辺さんの議論も、コードクローン(リンク先は阪大井上研)は全て悪か、より良いバランスはあるのか、と言う議論に見えなくもない(普及しているオープンソースには一定のコードクローンが存在するらしい)。このようにマッピングできるのは、ものごとを考え、理解し、整理しているからである。

ここに挙げた内容は技術者にとって基本的なことであるが、実践は難しい。自分のことはともかく、若者の可能性を信じて意見するのが年長者の務めだと思っている。

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


在庫推移監視方式にみるDOAのアプローチ #benkyoenkai

生産管理再入門-MRPを超えて <第43回IT勉強宴会> に参加しました。

メインの話題は在庫推移監視方式(Stock Projection Monitoring)で、その基本と事例の紹介でした。在庫推移監視方式はMRP(所要量計算)方式がバッチで処理するところを、手作業を前提とする事でリアルタイム処理する方式です。

在庫推移監視方式について

在庫推移監視方式は(1)新たな発注などの入出庫予定の変動があった際に、MRPは、(2)所要量の計算、(3)受払予定の再編成、(4)在庫推移の再計算、(5)推移以上の対応までバッチ行います。

しかし、実際は在庫を見たいだけなのに、(1)の入出庫予定の変動があるたびにバッチを実行しているユーザが多いそうです。そこで在庫推移監視方式は(2)と(3)だけをリアルタイムで行うことで、在庫の状況を確認できる様にしています。

在庫推移監視方式の事例

事例では、受注と発注の担当者を同じ組織にすることで、MRPがルールで行うことを人間によって調整できる様にしています。これによって、ムダに生産や在庫することが無い様に稼働を調整しているそうです。

在庫管理のポイントは、DB設計、方式設計、組織設計、工程負荷だそうですが、 在庫推移監視方式にあわせて組織設計までされたようです。

お話で興味深かったのは、在庫推移監視方式を知って実践したのではなく、実践してからそれが在庫推移監視方式であることに気付いたそうです。GoF本が出た時に「前からやっていた」という人がおられましたが、良いパターンは誰もがたどり着くものなのでしょうね。

そしてそのパターンを見いだして命名された渡辺幸三さんは、生産管理というドメインを極めたスパーエンジニアなのでしょうね。

在庫推移監視方式は方式設計?

在庫推移監視方式は方式設計ではないかということです。ドメイン分析の様に見えながら、実はリアルタイム処理かバッチかという方式まで決めています。

同じような感じは、ライブモデリングの時にもしました。データモデリングのようなのですが、理由を問われると「こんな有力画面を考えているんですよ」と答えられていました。

データモデリングと言いながら、画面設計もある程度できていたのです。DOAは常に実装と繋がっているのだと思います。

DOAのアプローチ

渡辺幸三さんは、ドメイン知識はDDDがいうような汎用的な方法では獲得が難しく、ドメイン専門家にならないといけない、といった主旨のお話をされていました。今回の在庫推移監視方式は専門的な経験があるからこそ、できる事なのでしょう。

DOAのアプローチはどちらかというと業務分析に始まるトップダウンアプローチです。でも、実装がどうなるかを意識していないと動くシステムは作れません。

たぶん、DOAはその溝を業務固有のデザインパターンでつないでいるのだと思います。今回は在庫推移監視方式というパターンでしたが、それ以外にも多くのパターンがあり、その獲得がドメイン専門家になるという事であると思いました。

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


クリティカルチェーンの定義から小規模プロジェクトの難しさを考える

小規模開発の難しさは独特です。これまでも問題点の指摘と解決法が提案されてきました。

改善に書けられる工数が少ない

プロセス改善ブームの前、多くのヨレプロジェクトが予算の2倍を消費していた頃は、会社の存続を左右する大規模開発に比べて被害が少ないので、小規模プロジェクトはあまり関心を持たれませんでした。やがて、大規模プロジェクトが統計的な手法でうまくいくようになると、小規模プロジェクトの被害が無視できなくなりました。

しかし、小規模プロジェクトでは改善の工数を大きく割く事が困難で、標準プロセスを管理する独立したSEPG(Software Engineering Process Group)を作る事も困難です。そこで行われたのは、大規模システムで行われている管理手法の簡素化です。標準プロセスをシンプルにすることと、自律的な改善活動でした(VSEセンター:資料ダウンロード)。

外乱による変動が大きい

しかし、小規模プロジェクトの難しさは、改善の工数が少ないだけではありません。規模が小さいので外乱による影響を受け易いのです。

環境、実現方法、業務ドメインの未知の問題が発覚すると、プロジェクトはその対応に追われます。脆弱性対応など、外乱による問題は規模に関係なく同じように理解と対応が求められますので、知識と経験の蓄積が必要とされます。

増員が難しい

このような問題を認識しても、まだ小規模プロジェクトの難しさの本質を表現できずにいました。先日、CCPM(リンク先はWikipedia)におけるクリティカル・チェーンの定義を見ていて、増員できない事が問題を難しくする事に気付きました。

大規模プロジェクトでは、クリティカルパス法やPERT法のように「作業員を雇用することが容易」という前提を置く事が可能です。しかし、小規模プロジェクトでは

  • 増員によるコスト増加の比率が高い
  • 教育コストの比率が高い
  • 一人分の初心者向け作業を切り出すことが困難

といった理由から、増員が困難です。このことで、「作業工程上の従属関係」だけでなく、クリティカルチェーンの様に「必要リソースが限られているために発生する従属関係」の考慮が必要になります。

リソース制限による難しさ

例えば並行して実行可能な2、3、4人日の作業A、B、C、があった場合、3人で実行すれば最短の4日で完了できますが、メンバーが2人なら最短で5日かかります。これを4.5日でとりあえず動かして欲しいと言われたなら、どのような対応ができるか考えてみましょう。

増員:トレーニングに1日かかるなら、指導1日もかかるので、3、4、4日となって4日で終わらせる事ができる反面、2人日の追加工数が必要です。このようにうまく配員できるかどうかという問題もあります。

手伝い:半日分の作業をもう一人に手伝ってもらえるなら、何とかなりそうです。しかし作業に専門性があるなら、その理解に必要な時間分は、はみ出てしまいます。

共通化:まだまだ上流なら、作業や構造の共通化で何とかなるかもしれません。でも、すでにきちんと設計されていたなら、難しいでしょう。

作業をショートカット:テストを端折ってでもリリースして欲しい。というお話を聞く事もありますが、障害対応に必要な作業で他の作業ができなくなりますので、一番危険な方法です。

後回し:保守用ドキュメントはリリース後に回すなど、作業内容を精査してリリースに必要な作業だけを実施します。リリースの目的が他のモジュールとの結合テストなら、有効な方法かも知れません。

以上の方法を考えると後回しが有効だと思われますが、開発標準に抵触する可能性がありますし、全体の作業内容を良く理解していないと混乱を生じる可能性があります。

残業というバッファ

クリティカルチェーンの正攻法はCCPMのように、あらかじめバッファを確保する事、他の作業からリソースを回す事です。本当に使える開発プロセスで書かれているように、大規模プロジェクトでは理想見積もりの1.5〜2倍の予算を確保してスケジュールがきめられるので、バッファをとれるかもしれません。

しかし、小規模プロジェクトの場合は、発注側が詳細な作業内容を把握しています。このため、理想見積もりを基準に予算が確保され、スケジュールを決められる傾向があります。

そこで小規模プロジェクトでは、残業時間がバッファになりがちです。スケジュールが厳しいからと、あらかじめ残業が見込まれてしまうと、さらに打つ手が限られてしまいます。

小規模プロジェクトの難しさ

そこで、いざとなれば開発標準をよく理解して、顧客との合意が可能な範囲で作業の最適化を行い、優先度の低い作業や手戻りの可能性のある作業を後に回すといった柔軟さが求められる事になります(Win-Winプロセス(ウォータフォール編)追記)。

このような方策は作業のショートカットと紙一重です。作業間の関係を理解した上で、独自のプロセスを構築する。そのようなアクロバティックな難しさが小規模プロジェクトには存在します。

クリティカルチェーンの定義から小規模プロジェクトの難しさを考えてみました。小規模開発では、改善工数の制約や外乱の影響を受け易いほか増員が困難で、クリティカルチェーンの特性であるリソースの制約があります。そこに予算とスケジュールの制約が加わるので、独特の難しさが生じているのだと思います。

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

より以前の記事一覧