2015年9月7日月曜日

ハードウェア開発に対しても新しい風が吹いて欲しいと願う

おはようございました。
ここ数年私事でバタバタが続いており、もう暫くはゆっくりできそうもありません。
不定期ですが、このブログ自体が只の駄文集なのでご容赦ください


先日、技術士会の情報工学関連の講演がありまして、そこで株式会社チェンジビジョンの社長である平鍋健児氏が“アジャイル開発とスクラム”という題目で講演をしてくださいました。

これ、分かる人には分かるのですが、一番肝心な要素はあくまでも経営側の要素が大きい(握っている)のですよね。
私も実運用事に経営側の問題でで苦労をさせられました。

おや?
『おまえはガチの電気電子野郎で、ソフトは関係無いだろ?』
って思っているならば、その考え方を変えることをお勧めします。
アジャイルやスクラムはソフトウェアシステム開発の話だから電気に関係の無い話ではないか?
と仰る方も居られるかも知れません。
しかし、昨今の複雑化するシステムをより強固に作り上げるには、
設計・開発手法≒手の内をどれだけ持っているのか?
がとても大きな重要要素になり、
また手の内を多くして万事に備える事は勝負の決定打になる事が多々あります。
他人の褌で相撲を執るような変な感じがしますが、すでに概念だけは共有財産化されていますから、使わない手は無いです。
この手の開発手法はどの分野であろうとも(例え、建設や土建、機械や化学、例え経営法法論であっても)応用がききます。


アジャイル自体は開発手法として結構昔からあります。
私も少し前に勤めていた会社には面白いソフトウェアの技術者がいまして、その方からヒントを貰いました。
具体的な方法論はソフトに関わってから学び始め、ネットがここまで一般化して流行る少し前(大凡10年ほど前)から私はこれをハードウェア開発や機構部品の開発に応用できないものか?と常々考え、試行錯誤をしてきました。
それで幾らかのハードウェアやアルゴリズムの実装対象にするシステム開発において、幾らかの知見を習得しました。

この手法は面白いです。
今迄の開発手法とは全く異なるので、職場として適用可能かどうか?の判断が必要ですが、上手く嵌ると開発に掛かる時間も資金も半分ぐらいは減るのです。

ただ、この手法を成功させるには幾つかの高めな敷居があります。

  • プロジェクト全体が見渡せるぐらいの技量を持つ技術者がいる事
  • 機能の要素分解ができる技術者がいる事
  • 手作り試作に関する敷居(時間も資金も)が低い事
  • 要素のテスト方法について自ら開発できる能力がある事
  • 技術的な能力が高くなくても良いので、技術的な良し悪し判断力に長けている人がいる事

そしてこれが成功の決め手

  • 折衝や管理ができる非常に優秀な能力者がいる事

何だ、ただのマネージメントじゃないか…と、思われた方はそれが正解です。
開発の複雑化や短期化、毎日のように変わる要求に対しての柔軟性確保などを一挙に解決しようとした方法です。
犠牲になるのは、責任の所在や担当の明確性、支払い条件の明確性が曖昧になる事などです。
これ、会社組織としては混沌の状態=デスマーチしかもいきなり末期)に見えてしまいかねません
ですので、
  • 折衝や管理ができる非常に優秀な能力者がいる事
が最も重要な条件になります。大事な事なので2回言っておきました。


では、具体例はあるのかよ?という突っ込みにお答えして、私が行った流用した手法を実行するのは至って簡単です。


  1. 大雑把な構成要素を客先と話ながら練り上げる
  2. あったら良いなという機能、もしくは必要となるであろう機能を推測する
  3. 大雑把な仕様をある程度の自己判断で決めてしまい、それを開発・検証しやすい複数の機能ブロックごとに分け
  4. 過去の実績を元に最大限に許される納期と予算を推測する
  5. 最悪の落とし処を決めておき、そこは譲らないように確定する
  6. いくつかのモデルケースを考え、納期と機能の絞込みを行う
  7. 重要な要素とそれ以外にわけ、順序付けをする
  8. 重要な要素は手作りで早急に機能検証と大きなバグ出しと対策を行う
  9. 実装の外枠を構築し、最重要要素以外に関しての要素はある程度動く程度で構築してしまう(このとき、追加工しやすいように配慮した設計・試作を行うこと)
  10. 客先にテスト機を提供して、実装した実物を見ながら要求や要望の細かい修正を行う
  11. 時間の許す限り当初予定していた機能の作りこみと実装を行い、結合検証を行う。
  12. さらに時間があれば優先度の低い機能の追加や次回以降のアイデア検討を進めてゆき、次回の開発時間短縮の糧にする
とまぁ、こんな感じです。
注意しなければならないのは、主たる最重要機能以外の順序は動的に変化します。
例えば電源であれば電源のコア部分=電源を供給するという機能以外、インターフェイスや電源の動作回路方式、保護機能や保護手法などは動的に変わる事を前提として組む必要があります。
後で動作回路方式まで変わられるととんでもない事になるので、事前に当たりを付けるためにも手作りで最小限の機能を早急に組み上げ、駄目出しの事前検証をするわけです。
このとき、積極的な消去法にて、回路方式を決定します。
多少駄目な部分はあっても、技術的に解決ができると踏むのであれば個人判断で先に進めます。
もし、個人で技術的解決手段を持ち合わせない場合は、その方法の選択をしてはいけません。
もれなくデスマーチ確定です。


え?実際は最初の中間成果物設計=基板設計だけでほとんど終わるって?
それはあなたの設計・開発に対する情熱(能力ともいう)が無いからです。
どんな回路でも頼まれたら大雑把に組み上げるぐらいの実力が無いのであれば、あなたは能力が不足しています。
会社は勉強する場ではありません。成果を出す場です、身銭を切ってでも勉強をしなさい。(鬼)


この手のやり方で最も効果的なのは、実装された現物を顧客が見たとき、相手が出すであろう仕様変更や追加の仕様をこちらが催促し、先に収束を誘導して無駄な設計時間の削減と検証する時間を大きく稼ぐ事にあります。
しかし、この手のやり方ではある水準以上の設計能力が無ければ確実に失敗をし、時間経過ごとに繰り返し変わってゆく仕様に対して確実に溺れます


トレーサーと言われる程度の設計をした事しかない人間には、この方法は少々ハードルが高いでしょう。
0から作れる能力があるか、もしくは、ある程度の技術的資料にあふれている状態であり、なおかつその資料のどこに何が書いてあるのかが分かっており、判断して切り取って組み上げる能力が最低限必要です。
前者は設計を担当する個人の能力で限界がありますが、後者は所謂マニュアル化である程度は補えます。
しかし、技術を正しく蓄積したマニュアルは早々ありません。おそらく切った張った程度の事でもよいので、自ら作らねばならないでしょう。
機能ごとに幾らかのデザインパターンを用意しておき、それを常日頃から更新するという形を採るのが正しいように思われます。
(あぁ…汎用性が低い以外はソフトウェアのデザインパターンとそのまんま同じだなぁ~と思う今日この頃)

ここで紹介した私の方法は実力が無い場合や、相手との意思疎通に幾らかの障壁があった場合、間違いなく破綻する方法です。
この手のやり方を進める場合は、相手の動きの推測と、市場動向の推測、そして客先企業自体の動きを常に注視しながら頭の中で何手か先を読み、事前に行動し続ける必要があります。
そのためには先ず相手との共感が必要不可欠ですから、相手の設計に関する側面だけでもいいので深く分かりあえる必要があります。
技術的・社会的・企業的にリスクが大きいのであれば、素直に旧来の設計で進めましょう。
所謂ウォーターフォール・モデルのような進め方というのは、設計に実力が無い状態であっても被害を軽減しながら物事を進めさせる方法のひとつです。
実力が無いのであれば、顧客と責任分解点を明確化した上で交渉を行い、ある程度殻に閉じこもって守られた状態で仕事を進める事をお勧めします。



この方法論は所謂コミュ障であっても成立はしますが、コミュ障である場合は顧客が記述したソフトウェアのコードから考え方を推察できる能力や、顧客が過去に作った回路基板から顧客の考え方を推察できる能力が必要です。
ココまで来るには相当な鍛錬が必要ですから少々骨が折れるでしょう。所謂オタクの領域にならねば困難です。
完全なるオタクになるか、相手と旨い物食いながら技術ネタで盛り上がるかは、あなたの判断次第です。
この方法論は相手の意図を組み上げ、早く目的地に誘導する事が大前提ですから、どの方法も採られないのであれば、この方法論は諦めましょう。

それにこの手の手法は経営側から見た場合には成果や報酬が混沌としており、方法論を進めるには少々厳しいものがあります。
企業は慈善事業体ではありません。母体を維持する程度には利益が必要です。
先ずは上から見難い成果物の判別点を上手く顧客と折衝し、金銭的問題をどう解決するか?そこが重要であるように感じられます。


当時の私のように、上司からのパワハラ目的で完全放置プレイになっており、破綻する事を望まれているのであれば全く問題ありませんが、一般人なのであれば、先ずは脳内シミュレーションや方法論の同時並行、または土台作りから行う事をお勧めします。
捨てられていたはずなのに破綻しなかった。寧ろ成果が上がりすぎて客が喜んでしまったので、私に対してもっと風当たりが酷くなったのはいつもの事でしたとさ…


ではでは、今日はココまで。
またの機会に会える事を楽しみにしています。




0 件のコメント:

コメントを投稿

ご意見や要望はこちらへどうぞ。