カテゴリー : Software Engineering

競争とスピードが激しい分野こそ、開発者の思いを全面に出し、意思決定を

ソーシャルの「カリスマ」開発者が大企業から出てこない理由 :日本経済新聞.

責任と権限にも問題がある。個人の場合、サービスの評判は個人の評判に直結する。大企業では、サービス担当のプロデューサーや開発者の意見だけで進められることはない。必然的にサービスに対する思い入れは分散していくことになる。社内での議論の中で、誰が開発しているかがあいまいになってしまうこともありえる。そもそもサービスにかける想いがなければユーザーに伝わらない。

この部分、一文一文が、ぐさぐさっと身に沁みる。ソーシャルに限った話ではない。大企業でも、誰でも、サービスに対する思い入れを発信できるように、誇れるように、うし、ちょっとしたところから試してみよう。

  • 各開発物・サービスに担当者の「思い入れ」「狙い」を宣言してもらう
  • 社内ユーザにその思いに対するフィードバックを必ずもらう。必ず開発者チーム・メンバーを表に出す
  • 最終的には、担当者の思いを定期的に公開する。ここに大きな壁があるけど、そもそもそのために早くサービス自体を公開できるようにすること。。

ソフトウエアアーキテクトになった

The eLearning Series: Systems Engineering for Software Intensive Systems
5月下旬から先週まで、このCMUの遠隔講座を受けてました。
Principles of Software Architectureという、ソフトウエアアーキテクトを
養成するプログラム。
このページを見る限り、16個の講義を受けることくらいしか分からないなあ。
実際は毎週の宿題と、実技のグループワークがあり、
この講座で学んだソフトウエアアーキテクチャ作成アプローチを
実践して、仕様書作成とCMUの講師に遠隔プレゼンをして、終わり。
これが実際のところかなりハード。アメリカの大学院の授業だから
宿題が多い。週に最低6時間、グループワークの最後のほうは
15時間くらいは費やしていただろうか。。。
もちろん通常業務はあるので、このために週末の1日はつぶれてました。
内容は、大まかに言えば上流設計のプロセス。
アーキテクチャの段階で、パターン・戦略の適用、評価、再構築を
繰り返すことで、品質が高く、リスクの小さい(あるいは、リスクを明確にした)
アーキテクチャを作るというもの。
および、そのドキュメント化。UMLのようなツールを利用する。
実践を通してこんなに身になった講座は初めて。
さすがCMUの授業。あーんど、自分も良く頑張ったものだ。
ただ、このアーキテクトの能力を生かせる環境が我が社にあるかどうか。
これが最大の難関だったりする。。。
いちおう、事業本部のトップも注目してくれているだけに、
せっかくだから「アーキテクト」を名乗って、何らかの役には立てたいものです。
ちなみに、ソフトウエアアーキテクチャ、ソフトウエア開発プロセスに
関する書籍は最近非常に増えてます。
今回の講座も、NASA, Boeing, サムソンが採用しているらしい。
UMLやコード自動分析・作成のためのツールも、
まだ研究も始まって歴史が浅い(5-10年)とのこと。
CMUの人に「研究やってみない?」って言われたけど、うーん、どうしようかなー。