俺のロボット設計指針シリーズ
「候補とするアーキテクチャを2つ以上つくる」
フリーランスの仕事を始めて、30代後半になってきて、全体設計やチームをコーディネートする仕事も期待されるようになってきた。今でもコーディング等の作業をがっつりやりますけどね。
図面というのはすごい力を持っていて、僕は機械系出身なので機械図面の持つパワーについては詳しいつもり。でもこの仕事を始めてUML等のソフトウェアでも「図面」の力を強く感じる。長くコーディングしてきた自分にとって簡単であることも、若い技術者には難しい。でも僕の思いついた構造や振る舞いを「図面」にして伝えることで、若い人に「気づき」を与えられる。
システムの構造を記述する時はUMLかSysMLで図面を書くけど、大雑把なスケッチの段階で複数、アーキテクチャ候補を挙げるようにしている。一つしか用意しないと、その特徴、メリット・デメリットを把握しづらい。無理やりにでも別のアイディアを出す。
アーキテクチャの評価軸はたくさんある。システムの提供する機能や性能の優劣はもちろん大事な要素だと思う。でも一番大事なのはコストが問題ではないか。ただコストに関わる要素が多元的で、そこがこの仕事の面白いところ。
研究開発の段階だと一番大事なのは人。人が使う時間が大事になる。高価な要素部品でも導入した方が結果的にコスト削減できたりする。人は高価だ。他にも評価の要素として、事業の継続性、事業価値の生成、開発速度などがある。そのうち詳しく書こう。
複数のアーキテクチャを用意するのは、広告デザイナーが顧客にポスターデザイン候補を「松竹梅」みたいに与えるような効果もある。顧客側も自分自身も、選択肢があると返って決断が容易になる効果があると思う。人は面白い。
工期の問題で複数提案書を作成するのが難しい事もあるだろう。ソフトウェア中心のプロジェクトだと、設計からメンバーの開発環境整備のためのスケルトンコード生成やモックの用意まで請け負ったりする。この場合は開発初期に仕事が集中する。とはいえ、仕事をする上では便利なルールだったりする。
「候補とするアーキテクチャを2つ以上つくる」
Quote
Yuki Suga/編み物ラグビー好きフリーランスロボット屋プログラマー
@ysuga
俺のロボット設計指針シリーズ
「下位のサブシステムに状態設定APIを導入しない」
下位のサブシステムに「制御モード」のような状態を気軽に導入してはならない。上位のサブシステムが利用する際に
- 1. モードの設定
- 2. 処理の実行
のような流れでタスクを行う処理は見直して
- 1. x.com/ysuga/status/2…