躓いて進めないので、あきらめモード。
細かくおさらいするの面倒なのでチェックしたページのみクリッピング。
試行錯誤中。
平易で分かりやすいのがこのあたり。
だけどターゲットとしているタイプはもっと上流の人たちなので、計画とは、を説いても意味がない。
そんなことは分かっている。
みなさん頭ではわかっているはずなんだけど、どちらかというとすぐに動くタイプが多いので、それを求め（求められ）てしまう。
突っ込み所としては、「だから今のこのニッチもサッチもいかない状況があるんじゃないの ?」ってことなんだけど。
このコンテンツとてもいい。まさに現場で起きていることが書かれている。
各エントリーのポイントを引用しておく。
20年前に進化が止まった日本のIT業界 見渡せば経営に役立たないシステムだらけ 3/4
（1）「計画」と（2）「分析」に関するソフトを「上流CASE」と呼び、（3）「設計」と（4）「コード生成」に関するソフトを「下流CASE」と呼ぶ。総称して「統合CASE」と呼んでいる。
この「上流」「下流」の区分は、欧米のシステム開発では当然の考え方である。システム上流工程と言えば（1）「計画」と（2）「分析」を指し、システム下流工程と言えば（3）「設計」と（4）「コード生成」を指す。
ところが日本ではこの区分が異なっていた。日本では、（3）「設計」がシステム上流工程であり、（4）「コード生成」がシステム下流工程と呼ばれていたのだ。
実際、日本で飛ぶように売れたのは、（3）「設計」のソフトである。（1）「計画」のソフトは、全くと言っていいほど売れなかった。
これは、いかに日本のシステム開発において「計画」「分析」が軽んじられているかを意味している。欧米に比べ、ほとんどの日本の経営者は、自社のシステム開発には全くと言っていいほど関心を持たず、参画しない。つまり、「計画」が行われないままシステム開発に突入しているのに等しい。
JBpress(日本ビジネスプレス)
まさに、その通り。
国内の現場しか知らないので日本独特かどうかは分からないが、上流と呼ばれる、その内容に違和感がずっとあった。
最近は、一般的に使われる「上流」では表現できないため「超上流」なんて表現もあるくらい。明示的に「計画」や「分析」を意味する訳だから、ある意味、良かったのかもしれないが...
小規模な開発案件や機能がある程度確定しているシステム、連携するシステムの要件などが明確な場合は、RFIやRFPを作らないことが多い。だが、コンサルティング会社は、RFIやRFPを効率よく作るノウハウがあるので、この工程を勧めてくる。その場合は、相当高額なコンサルティング料を求められることがあるので、要注意だ。
総開発費用が1億円のシステムなどで、この工程を行うと、3～4割程度がRFIやRFPの策定に課金される場合がある。残りの6～7割でシステム開発やハードウエアの購入、ネットワーク構築などがあると、予算不足になり、大抵の場合、予算を追加しなければならなくなる。
JBpress(日本ビジネスプレス)
RFP はよく使っていたが、RFI という言葉を意識し始めたのは最近。プロジェクトのスケジュールを考える際に RFP と RFI は明確に区別しよう。（と思う）
開発コストを膨らませる日本文化「仕様変更」 ユーザー要件をすべて汲み取ると何が起きるのか
- プロジェクト担当者は「兼務」ではなく「専任」で
- パッケージソフトの機能に業務を合わせる
- システム開発会社を次々に替えると損をする
JBpress(日本ビジネスプレス)
この連載、ビックリするくらい僕の考えと一致している。
先日、インドを訪問した際に感心させられたのだが、インドは国を挙げて（産官学が一体となって）システム開発の基準を作っている。また、ソフト開発の実力を計る「SEI-CMM」という世界標準の基準があるが、最高レベルのレベル5を取得している世界の企業の半分以上はインドの会社である。インドのシステム開発会社は、「品質」に絶対的な自信を持っている。国が主導する基準作りは日本でもやはり必要である。
JBpress(日本ビジネスプレス)
本題から外れるが、これで合点がいった。
以前 (前職で)、インド / インド人と絡めそうなプロジェクトの話があった。
結果的にプロジェクト化には至らなかったが、依頼人のシステム開発会社が CMM のレベル 4 を取得していて、その方の会話はとてもスマートだった。
なるほどね、こんな背景があったのかっ。
こうしたメソドロジーを所有し、実践している会社はまだまだ少ない。存在を知らない会社もほとんどだ。手順書を持たずに経験と勘だけで構築しているのが実情である。
メソドロジーは、「オブジェクト指向」などの方法論とは別の視点で捉える必要がある。システムの「品質」の担保に、メソドロジーは必須なのだ。
JBpress(日本ビジネスプレス)
恥ずかしいが、この回に書かれていることは僕の経験そのもの。
可視化の際のポイントが書かれているけど、読み手の能力 = 可視化されたものを読み取れる "読解力" が必要、という点は再認識。
標準図法については、前日色々調べた。これについては、今度エントリーしたいと思う。結論だけ書くと UML でも 官公庁の EA モデリングでもなく、BPMN。
- 可視化では、それを見る側の可視能力を考慮する必要があるが、必ずしもEAやUMLでの図表（標準図法という）は、経営者などの素人には分かりやすいとはいえないものもある
- しかし、全体最適化の観点から、経営者にも標準図法の可視能力を持ってもらいたい
- 標準図法が分かりにくいのではなく、これまで慣れてきた表記法と異なるので違和感を持っているだけだ。その違和感を払拭（ふっしょく）するには、繰り返しと段階的誘導が必要だ
- それにはベンダや利用部門の協力が必要だ。日本版SOX法対処の専用ツールの採用は、経営者の認識を高める良い機会でもある
＠IT情報マネジメント
うぅ ... ん、いまいち良い記事が見つからない。
チラっと読んでおくかな。
30年前のロードマップと変わらない Apple とか。
Excel だと sum() して、書式を [h]:mm とかすればよいけど...
SQL の関数を駆使して
SELECT maketime(sum(time) / 60, sum(time) mod 60, 0) FROM Demo_table;
codeなにがし
select sec_to_time(sum(time_to_sec(ftime))) from tbl_time
MySQLユーザー会 メーリングリストアーカイブ
SELECT SEC_TO_TIME( SUM( TIME_TO_SEC(`時刻カラム` ) ) ) FROM `テーブル`;
L3 * * *
MySQL のリファレンスも参照しておく
時刻です。範囲は '-838:59:59' から '838:59:59' です。MySQL は、TIME 値を 'HH:MM:SS' フォーマットで表示しますが、文字列と数字のどちらで TIME カラムに値を指示してもよいです。
MySQL :: MySQL 5.1 リファレンスマニュアル
TIME カラムに省略された値を指定する際には注意してください。MySQLは、コロンが付いていない値は、その値の一番右の二桁が秒を表していると解釈します。(MySQLは TIME 値を、一日の内の時刻ではなく、経過時間として解釈します。)例えば、'1112' と 1112 は、'11:12:00' (11時12分過ぎ)を意味するように感じますが、MySQLはそれを '00:11:12' (11分12秒)と解釈します。同じように、'12' と 12 は'00:00:12' という意味になります。コロンが付いた TIME 値は反対に、必ず一日の内の時刻として扱われます。それは、'11:12' が '11:12:00' を表し、'00:11:12' では無いという事になります。
MySQL :: MySQL 5.1 リファレンスマニュアル
