ソフトウェアプロセス(1)
あなたの会社のソフトウェアプロセス
この会社のソフトウェア・プロセスはどんなものか、と聞かれた。
何が言いたいのかよくわからんので月曜日にドキュメントを持って来いと言って終了したが、多分会社のソフトウェア制作手順をまとめたドキュメントを指している気がする。ベトナムでは必要ですと（ベトナム語で）力説していたが、なんだろね。
要求、分析、設計、製造、テストの5つの作業があり、その中のABCDのチェック項目がどうのと言っていた。プロジェクトによってはABCDのうちAとDしかやらないのもあれば、ABCD全部をやるのもあるが、ソフトウェア制作会社が必ず持つべき基本的なルールなんだそうな。
やばい、知らんぞ。プロジェクトごとに決めるんだと思ってた。
・・あるのは常識なのか？
一応の予定
個人的にはCMMIのレベル3くらいを5年後くらいにとれると最高だよなぁとは考えていて、1年目は完全にベトナムという国、あるいはベトナム人という人物達を見定める時間にあてるので、工程管理も人員管理も全て私の脳内だけで処理してしまおうかとは思っていた。
その後実務の過程で勤怠やら、組織やら、得意/不得意業務、オフショア開発における問題に、ベトナム人の性格もわかってくるだろう。
それから一連の流れをドキュメント化して、品質管理手順を文書でまとめて、さあ資格をとりましょかという話にしたかったので、そんなに焦らんでくれよと思ってはいる。
もし彼の言っているソフトウェアプロセスと、私の考えている一連のドキュメントが同一であれば、社員もいない内からガチガチに整備するのは構わんが、多分一番苦しむのは私と君だぞ、という話にはなるだろう。
ちなみにもし相手側のスキルやら何やらを全て無視して、私がベトナムでやるべきだと考えているのは以下の項目全て。
これはソフトウェアプロセスとやらより範囲が広いんじゃないかなとは思うが、たとえそうだとしてもこの辺決まらないとソフトウェアプロセスも決められないんじゃないかな。
- アジャイルで開発（最も重要なのはSmall Release）
- プロジェクト管理はスパイラルモデルを提案するが、相手先の管理手法によっては不可なのでリリースポイントを増やす事を提案
- ドキュメントの言語は相手先に合わせる。日本が相手であれば、英語ドキュメントを書いておしまいとはしない
- 上記制約は納品物以外の設計資料からは除外する
- 日本とベトナム双方に法人をたて、双方に最低一人ずつブリッジSEがいる環境で行う
- 受注プロジェクト規模は最低20人月から
- テストチーム、デザインチーム、開発チームは分ける。開発チームと設計チームは分けない。テストチームは結合テスト以後のテストを担当する（品質保証）
- 1チームは4〜5人程度を理想とし、それぞれにグループリーダーがいる形態で作業を行う
- テスト環境はベトナムで仮想環境を作ってやるのみ。例えば日本の仕事であれば日本の本番環境テストは必要だが、それは全て客先が行う
- 設計はUML主体
- テストファーストは採用しないが、単体テストはテストプログラムで行う
- OSは全部Linux。一部ドキュメント用にWindows + Office
ま、無理だけどね。
一年目から理想論振りかざしても仕方ないでしょ。理想論というか、これでも最低限の項目しか出していないつもりだが、このレベルでさえ初年は無理だろうとは思っている。
システムの事がわかっていて経営陣に食い込んでいるのは私しかいない。
ベトナムとベトナム人SEを理解していきながら、無理強いをしない程度にこちらの要求を通す手順をまとめるのは、一年じゃ無理だろう。
だからこそ無計画と言われようとなんだろうと、初年度は私の経験と馬力だけで全てカバーするつもりでいた。
客先への営業用プレゼンは一部作ってあるし、多少プレゼン用資料にも沿って動きはするが、それは表面上であって私とベトナム人SEの間にはより流動的な関係があるレベルでいいだろうと。
とは思うが
それは私側から見た意見であり、雇われているベトナム人SEからすれば、情報が出てこなければ不安になるのも当然だろうと理解はする。
ということで月曜日に再度話をしてみることにした。
君の言いたいことはどういう事で、こちらが話すべき事はなんなのか、今まで通訳さんがいなくて話せなかった事をたくさん話そうと思う。
ベトナムの一流大学で学び、その後シンガポール系専門学校で学び、Microsoft Developerでもある人間だ。
私の知らない有意義な情報を多く持っているだろうし、その情報を私の実務経験というフィルタを通して最適化することで、ベトナムと日本の化学反応を起こせるかもしれんしな。
彼の言うソフトウェアプロセスというものが具体的にわかってきたら、また続きを記すとしよう。
