一番伝えたいことは
システムを変えなければ何も変わらない。
システムの中でも私たち技術屋に変えられるのは開発プロセス。開発プロセスを変えていい装置を作ること。
組織構造や戦略は経営者がやること。
短期で劇的に変わる魔法のような方法はない。
長期的に次の人のために今自分ができることを常に考えていってほしい。
この積み重ねでしかいいものは作れない。
目次
・システムとは？
・いい装置ってどんな装置？
・ソフトウェアの開発プロセス
・要求を把握する、お客様が求めることは？
・設計する（仕様書の作成）
・レビュー
・コーディング
・コーディングルール
・検証
・自動テスト
・単体テスト
・製作物の管理
内容
・システムとは？
「システム」とはある結果を生み出すために特定の形で作用し合う要因の組み合わせです。
会社もシステムです。
会社 = プロセス + 組織構造 + 戦略
システムは今の結果を得るべく完璧に設計されてます。
ただ多い時もあれば少ない時もあるようにばらつきがありますが一定の範囲内に収まります。
例えばランダムに10,000人にチラシを送ったとします。
ある人たちは商品を買ってくれるし別の人たちは何も買ってくれない。
このばらつきはシステムの中に入ってます。システムはこの結果を生み出すようにできています。
結果をグラフにすると平均して12%の人とが商品を買ってくれることがわかりました。
月によって8%のときもあれば14%のときもありこの間を行ったり来たりしてます。
なのでこの結果に関して従業員を叱っても結果は変わりません。
すごく優秀と言われる人が担当しても結果はわかりません。
そういうシス テムになっているだけです。
なぜシステムの話をしたのかというと求める結果が得られてない場合はシステムを変えないといけないからです。
船を右にしか曲がらないように設計されている船をここに乗っている乗組員がどんなに頑張っても左に曲げられないのと同じです。
優秀な人と優秀なプロセスどちらが重要か？
賛否両論あるかもしれませんが、私はプロセスだと思います。
システムが 一番重要です。
この良い結果を生み出せる仕組みを作れる人がすごい人であり、
今日はこのプロセスのソフトの部分の話です。
組織構造と戦略に関しては話す機会はないので興味があれば聞きに来てください。
「プロセス」とはどのような行動をどのような順番で行うのかを定義するものです。
料理で言えばレシピです。
どういう材料をどういう順番でどういう風に処理するのかを定義したものです。
なぜプロセスが必要か？ですが、
料理で言えば誰でも美味しい料理を作れるようにするためです。
会社で言えば社長の言葉を使わせもらうとお客様が感動する、満足するような装置をきちんと作るためです。
では質問です。
お客様が感動 する、満足する商品って具体的に何だと思いますか？
簡単に短時間で多くの製品を不良品なく作れることだと思います。
新機能は短納期で品質の高いものを作ること。
簡単には
設定が少ない
品種ファイルが1つで全装置にコピーして使える。
実際は機差があって一つの品種ファイルで生産できることはまだできてません。
操作や調整が直観的にできる
最近だとオペレータがいなくても自動化が進んでます。
顧客のイメージ通りにきちんと動く。
短時間はUPHが高い。つまり1時間で生産できる量が多いこと。
エラーが少ない。
バグがない。
不良品がない
精度がいい
精度が良ければ接触不良なども起きにくい。
画像処理でゴミやクラックを見つける
装置のデ ータをホストへ送って不良品が出ないように未然に
あとは
今困っていることを解決してくれる。
この質問に正解はないのでこれからも自分なりの正解を探求していってください。
・お客様が求めることは？
・設計する（仕様書の作成）
設計は少人数で行う
全体を把握しないで設計してませんか？
あいまいな仕様書を作らない。
あいまいは反論させないための防衛手段
時間は限られているのであいまいにすれば指摘されることもない。
開発者、管理者、オペレータ、顧客の品質部門、開発部門、生産部門
関係者が合意しないと仕事が進まないのであいまいにする
具体的な記述をすると誰かが必ず指摘する。
この指摘をごまかすためにあえてあ いまいにする
本当は仕様書の方が悪いのに自分の方が悪いと思いがち。経験不足だから理解できないとか
入出力をはっきりさせる。
・製作物の管理
バージョン管理システム
Git
Subversion
Visual Souse Safe
短期間で生産性を高める方法はない。
生産性は長期的な投資によってしか向上しない。
今できることは後世のために長期投資をするしかない
短期的に生産性を変える方法はないので無駄な時間を避けることに力を注ぐ。
プロジェクトのリスク管理をすることで無駄な時間を避ける。
設計とレビュー
ソフトウェア開発で一番時間がかかるのはなんでしょうか？
答えはデバッグです。
生産を上げるにはデバッグの時間を減らすことです。
デバッグの時間はバグの数に比例します。
デバッグの時間を減らすためにはバグを減らすことです。
時間のかかるバグはモジュールとモジュールの間のインターフェースにからむやつです。
この厄介なバグは設計の中にします 。
設計中にバグを取り除こうとしている人はほとんどいません。
レビューをする価値があるぐらい実際のコードレベルで設計している人はほとんどいません。
ほとんどの人は管理者にうるさく言われるから形だけのドキュメントとレビューをやっているだけで早くコーディングに進みたいと
思ってます。そして管理者がOKを出したらこの設計を見ることはありません。
そしてコーディングの段階になって本当の設計をはじめる。
この決定はレビューされない。
レビューしたとしても作ってからのレビューなので問題があったら作り直しになる。私もそうですが作ってから問題を指摘されると
イラっとします。
私もレビューをしますが、はっきり言って詳細な部分までわかってませ ん。
経験からある程度わかる部分はありますが、完全に問題を見つけられる自信はありません。
これは検証にも言える。
形だけの
・検証
作った人が一番詳しい。
作った人がきちんとテストしないと後の工程で
作った人が少しでも不安だなぁと思ったらこの不安な点は現場で発生する。
作った人が責任を持って
後の工程で見つけられるのはポカミスぐらい。作ってない人が根本的なミスを見つけるのは難しい。
ソフトウェアのタスク
・デバッグ
・設計
・レビュー
・仕様の作成、計画、見積もり、ドキュメントの作成
伝えたいことは顧客に喜ばれる機能はどうやったら作れるか。
一番重要！
どんな機能か仕様を正確に理解する こと。
どういう目的で、どういう機能で、どのように使われて、どのように役に立つのか
その場の思いつきで軽い気持ちでこんな機能があったらいいなぁと言う場合もある。
本当に必要か？
開発しやすい設計を行う。
きちんと設計しよう。
最初の設計ですべてが決まる。
機能追加があることを前提にいかに柔軟に設計するかが我々の腕の見せ所（力量）。
道具もきちんと理解する。
正しい道具の使い方がわからなければ怪我したりいいものができない。
これは自分で磨くしかない。
製作物をきちんと管理する
バージョン管理システム
システムを変えなければ何も変わらない。
システムの中でも私たち技術屋に変えられるのは開発プロセス。開発プロセスを変えていい装置を作ること。
組織構造や戦略は経営者がやること。
短期で劇的に変わる魔法のような方法はない。
長期的に次の人のために今自分ができることを常に考えていってほしい。
この積み重ねでしかいいものは作れない。
目次
・システムとは？
・いい装置ってどんな装置？
・ソフトウェアの開発プロセス
・要求を把握する、お客様が求めることは？
・設計する（仕様書の作成）
・レビュー
・コーディング
・コーディングルール
・検証
・自動テスト
・単体テスト
・製作物の管理
内容
・システムとは？
「システム」とはある結果を生み出すために特定の形で作用し合う要因の組み合わせです。
会社もシステムです。
会社 = プロセス + 組織構造 + 戦略
システムは今の結果を得るべく完璧に設計されてます。
ただ多い時もあれば少ない時もあるようにばらつきがありますが一定の範囲内に収まります。
例えばランダムに10,000人にチラシを送ったとします。
ある人たちは商品を買ってくれるし別の人たちは何も買ってくれない。
このばらつきはシステムの中に入ってます。システムはこの結果を生み出すようにできています。
結果をグラフにすると平均して12%の人とが商品を買ってくれることがわかりました。
月によって8%のときもあれば14%のときもありこの間を行ったり来たりしてます。
なのでこの結果に関して従業員を叱っても結果は変わりません。
すごく優秀と言われる人が担当しても結果はわかりません。
そういうシス テムになっているだけです。
なぜシステムの話をしたのかというと求める結果が得られてない場合はシステムを変えないといけないからです。
船を右にしか曲がらないように設計されている船をここに乗っている乗組員がどんなに頑張っても左に曲げられないのと同じです。
優秀な人と優秀なプロセスどちらが重要か？
賛否両論あるかもしれませんが、私はプロセスだと思います。
システムが 一番重要です。
この良い結果を生み出せる仕組みを作れる人がすごい人であり、
今日はこのプロセスのソフトの部分の話です。
組織構造と戦略に関しては話す機会はないので興味があれば聞きに来てください。
「プロセス」とはどのような行動をどのような順番で行うのかを定義するものです。
料理で言えばレシピです。
どういう材料をどういう順番でどういう風に処理するのかを定義したものです。
なぜプロセスが必要か？ですが、
料理で言えば誰でも美味しい料理を作れるようにするためです。
会社で言えば社長の言葉を使わせもらうとお客様が感動する、満足するような装置をきちんと作るためです。
では質問です。
お客様が感動 する、満足する商品って具体的に何だと思いますか？
簡単に短時間で多くの製品を不良品なく作れることだと思います。
新機能は短納期で品質の高いものを作ること。
簡単には
設定が少ない
品種ファイルが1つで全装置にコピーして使える。
実際は機差があって一つの品種ファイルで生産できることはまだできてません。
操作や調整が直観的にできる
最近だとオペレータがいなくても自動化が進んでます。
顧客のイメージ通りにきちんと動く。
短時間はUPHが高い。つまり1時間で生産できる量が多いこと。
エラーが少ない。
バグがない。
不良品がない
精度がいい
精度が良ければ接触不良なども起きにくい。
画像処理でゴミやクラックを見つける
装置のデ ータをホストへ送って不良品が出ないように未然に
あとは
今困っていることを解決してくれる。
この質問に正解はないのでこれからも自分なりの正解を探求していってください。
・お客様が求めることは？
・設計する（仕様書の作成）
設計は少人数で行う
全体を把握しないで設計してませんか？
あいまいな仕様書を作らない。
あいまいは反論させないための防衛手段
時間は限られているのであいまいにすれば指摘されることもない。
開発者、管理者、オペレータ、顧客の品質部門、開発部門、生産部門
関係者が合意しないと仕事が進まないのであいまいにする
具体的な記述をすると誰かが必ず指摘する。
この指摘をごまかすためにあえてあ いまいにする
本当は仕様書の方が悪いのに自分の方が悪いと思いがち。経験不足だから理解できないとか
入出力をはっきりさせる。
・製作物の管理
バージョン管理システム
Git
Subversion
Visual Souse Safe
短期間で生産性を高める方法はない。
生産性は長期的な投資によってしか向上しない。
今できることは後世のために長期投資をするしかない
短期的に生産性を変える方法はないので無駄な時間を避けることに力を注ぐ。
プロジェクトのリスク管理をすることで無駄な時間を避ける。
設計とレビュー
ソフトウェア開発で一番時間がかかるのはなんでしょうか？
答えはデバッグです。
生産を上げるにはデバッグの時間を減らすことです。
デバッグの時間はバグの数に比例します。
デバッグの時間を減らすためにはバグを減らすことです。
時間のかかるバグはモジュールとモジュールの間のインターフェースにからむやつです。
この厄介なバグは設計の中にします 。
設計中にバグを取り除こうとしている人はほとんどいません。
レビューをする価値があるぐらい実際のコードレベルで設計している人はほとんどいません。
ほとんどの人は管理者にうるさく言われるから形だけのドキュメントとレビューをやっているだけで早くコーディングに進みたいと
思ってます。そして管理者がOKを出したらこの設計を見ることはありません。
そしてコーディングの段階になって本当の設計をはじめる。
この決定はレビューされない。
レビューしたとしても作ってからのレビューなので問題があったら作り直しになる。私もそうですが作ってから問題を指摘されると
イラっとします。
私もレビューをしますが、はっきり言って詳細な部分までわかってませ ん。
経験からある程度わかる部分はありますが、完全に問題を見つけられる自信はありません。
これは検証にも言える。
形だけの
・検証
作った人が一番詳しい。
作った人がきちんとテストしないと後の工程で
作った人が少しでも不安だなぁと思ったらこの不安な点は現場で発生する。
作った人が責任を持って
後の工程で見つけられるのはポカミスぐらい。作ってない人が根本的なミスを見つけるのは難しい。
ソフトウェアのタスク
・デバッグ
・設計
・レビュー
・仕様の作成、計画、見積もり、ドキュメントの作成
伝えたいことは顧客に喜ばれる機能はどうやったら作れるか。
一番重要！
どんな機能か仕様を正確に理解する こと。
どういう目的で、どういう機能で、どのように使われて、どのように役に立つのか
その場の思いつきで軽い気持ちでこんな機能があったらいいなぁと言う場合もある。
本当に必要か？
開発しやすい設計を行う。
きちんと設計しよう。
最初の設計ですべてが決まる。
機能追加があることを前提にいかに柔軟に設計するかが我々の腕の見せ所（力量）。
道具もきちんと理解する。
正しい道具の使い方がわからなければ怪我したりいいものができない。
これは自分で磨くしかない。
製作物をきちんと管理する
バージョン管理システム