近況報告と2012年に向けて

あけましておめでとうございます。ご無沙汰しております。

心機一転、はてなブログにて、近況報告と2012年の抱負を書きました。今後は、はてなブログに一本化していきますので、今後ともよろしくお願いします。

近況報告と2012年に向けて

皆様、あけましておめでとうございます。

ブログを書くのは随分と久しぶりです。昨年は震災の少し前に書いたエントリ以降、更新が止まってしまっています。理由は3つ。

1. 震災やその他理由による気分的なもの
2. Facebookに慣れて長い文章が書けなくなった
3. 仕事環境が変化しパブリックに発信できることが少なくなってきた

特に3つ目の理由が大きく、その結果、「岡島は今何してるんだろう？」って思われている方も多いかもしれません。そこで本日は、近況報告を兼ね、私が現在仕事で取り組んでいることを、2012年の抱負と併せ書かせていただきます。

今私たちが取り組んでいる業務の内容を一言で言えば、「組込み業界向け受託開発および製品ソリューションビジネス」であり、今年度より、特に自動車「業界」向けソフトウェアに特化しています。ことさらに、「業界」とカッコで括ったのは、自動車に組み込まれるソフト（ET系）だけでなく、自動車関連のソフトを開発しているエンジニア向けのツール（IT系）も対象となっているからです。

製品を中心としたソリューションビジネスにも取り組んでいますが、現時点での収益構造は人月商売（比較的長いスパンでの小規模な開発・コンサル業務がメイン）依存です。昨今SIerの人月商売について様々な意見・論が出てきていますが、私としては、コストパフォーマンスが出ないと契約が継続できない厳しい環境の中で、提案型で付加価値の高い開発やコンサルサービスを提供し続けているという自負心もあり、現時点での最適解として堂々と人月商売に取り組んでおります。

あと数年で、受託開発サービスでビジネスをゆるやかに伸長させつつ要員を育成し、さらに、そこで得た利益とノウハウから製品ソリューションに投資を行い、マイルドに人月商売の比率を下げ、環境の変化に強い組織を作るのが私のミッションです。（ということで、リーンスタートアップに注目しています）

技術的には、機能安全（ISO26262）やAUTOSARなど重厚長大なテーマを扱う必要が多く、個人ですべてカバーするには難しいと感じており、知見を持ったエンジニアチームの育成と、組込み領域における絶対的な経験値不足のカバーは、2012年も大きな課題となります。これらは簡単には解決できませんが、今取り組まないと先もありません。そのような課題意識の中で、組込み技術とモデリング・開発プロセスに対する経験をブーストできるETロボコンへのチャレンジは、今年も続けます。

私個人としては、昨年8月より事業部門の長を拝命して以降、事業の計画作りや日々の管理業務を、慣れないながらも周りのサポートを得ながら、よちよち歩きで進んでいる状態です。有限期間・特定目的で成果を出すプロジェクト・現場のリーダーと、複数年度・複数プロジェクトを意思決定にて束ねていく組織のリーダーとの違いを実感し、まだまだ成長が必要と感じる日々です。

ここ数年、自分の知識や経験が通用しないように思え自信が揺らいでしまったことも多々ありますし、同業や異業の友人・知人の転職や起業が相次ぐ中、私も40歳という区切りの年を迎え、自身のキャリアについて色々考えたこともあります。

しかし、事業を預かるという経験は得難いものでありチャンスです。このチャレンジで経験を積み成果を出し、人間としても成長を果たしたいという思いが強くなってきています。この気持ちを行動に変え、充実した2012年にすべく活動していきます。

ということで、本年もよろしくお願いします。

議事録で鍛えられた思い出

議事録のエントリに想定外のブックマークを頂きびっくりしております。なんというか、ありがとうございます。
別に目新しいことを書いてるつもりはありませんし、フォーマットなどは私のオリジナルですらありません。実のところはある仕事を通じて身に付けたやり方なのです。

仕事はハードで体重が一割減るくらい苦労しましたが、結局成果はあがらずいろんな方にご迷惑おかけしました。しかし個人的には、「目的を意識して主体的に課題を見つけ行動することが仕事の本質である」ということが腹に落ちた意義深いプロジェクトでもあります。あの仕事がなかったら今の自分はないな、と本気で思ってるくらい。

その過程で重要というか象徴的な役割を果たしたのが議事録でした。目的意識が足りない、結論が不明瞭、課題が見えないなどと書きなおしを何度も命じられ、仕上げるのに1日かけたこともあります。正直、苦痛でした。でも、どんなに苦労しても議事録は成果物じゃないんですよね。だから時間をかけすぎては駄目。極論言えば議事録書くことは仕事じゃない。

このように「たかが議事録」なのですが、ちゃんと書けるように苦労と工夫を重ねていると、「会議に参加する目的・課題意識を持つこと」や「自分の役割だけでなく、プロジェクトの全体状況を俯瞰して把握すること」、「文章は読む人の立場になって書くこと」など、社会人に必要な意識とスキルは着実に向上していきます。

私は議事録を書くことを通じて、お客様から鍛えていただきました。そんな思いがあるから、今でも若い人を鍛えるに議事録を書かせるのが効果的だと考えていて、いろいろ口出しというかフィードバックをしたくなるのです。

議事録を書くときに意識すべきこと

開発現場であってもそうでなくても議事録を書く機会は多いのですが、意外に役にたつ議事録を書くのは難しいものです。ということで、以下自著『プロジェクトを成功させる現場リーダーの技術』より議事録の書き方をまるっと引用。キーワードは「目的・課題・アクション！」です。

会議は避けられない

一口に会議といっても、あらかじめ計画されている定例的なものから、突発的に発生する小さなプロジェクト内ミーティングにいたるまで色々ですが、プロジェクトがさまざまな人との協調作業であり、プロジェクトの生み出す価値がたくさんの利害関係者の合意によって成り立つ以上、会議は必要かつ重要な活動です。実際、大規模プロジェクトでは、プロジェクトの計画段階でコミュニケーション計画として会議体が定義されます。世の中無駄な会議が多すぎると嘆かれながらも、実際問題として、プロジェクトは会議によって進んでいるというのも事実です。
現場リーダーをやるからには、これらの会議を避けて通ることはできません。むしろ積極的な関与が必要となってきます。現場リーダーとして議事を進行する場合もあるでしょうし、そうでない場合でも責任のある発言が求められます。このように何かとプレッシャーのかかる会議ですが、議事録を活用することでよりスムースな運営を行うことが可能です。

議事録の目的

まず参考までに、首相官邸の高度情報通信ネットワーク社会推進戦略本部による、「ＩＴ戦略本部」の議事録を見てみましょう。基本的なフォーマットは以下のようになっています。

1. 日時：会議の開催された日程を１５分単位まで細かく。
2. 場所：開催場所について部屋まで細かく。
3. 出席者：各出席者の肩書きまで細かく。
4. 会議の模様：会議の出席者の発言内容や会議の段取りについて、詳細に記録。例えば、「担当大臣が有識者を紹介した。」や、総理大臣の挨拶について、出だしの挨拶から含めてもれなく紹介

いきなり言ってしまいますが、これでは０点の議事録です。ビジネスの現場でこのような議事録を書いてはいけません。これは、政府が国民に向けて行っている「サービスの一部」であるから許されることだと考えてください。
まず、日時や場所・出席者に関しては良いでしょう。これらの情報は忘れなければ問題ありません。出席者の肩書きは、間違いなく記述するよう気をつけましょう。
問題は、内容である「会議の模様」です。たしかに、発言についてもれなく記述はされていますが、いったい何のために、つまりどんな目的で、IT戦略会議を開催したのか、その意図が分かりません。内容を詳細に読んで、総理大臣や担当大臣の発言を追っかける必要があります。実際に私も呼んでみましたが半分も読まないうちに断念し、結局、目的と結論はわかりませんでした。IT戦略会議の議事録は、単なる発言集であって議事録とは呼べません。「朝早くからお集まりいただき云々」などといった挨拶の内容まで詳細に議事録として公開することに何の意味があるのでしょうか。
意義のある議事録を書くためにはポイントがいくつかあります。まずは、読み手を意識しなくてはいけません。会議の種類や参加者によって議事録の目的も多少は変わりますが、特にお客様やプロジェクトマネージャなどの重要な関係者が読む場合は、手短に、しかも正確に書く必要があります。お客様は暇ではないのです。
次に、ストーリーが見えること、しかもその会議中の流れだけでなく、プロジェクト全体を通じたストーリーが見えなくてはいけません。議事録を追うだけで、プロジェクトがどのような歩みをしてきたのか、簡単に追跡できるのが理想です。
最後に、それほど時間をかけずに書けること。会議が終わってから1週間後に議事録が出てくるのでは遅すぎるでしょう。また、議事録を書くために本来の作業ができなくなるのは本末転倒です。

議事録も「目的・課題・アクション」

では、このようなポイントを踏まえた議事録を書くにはどのようにすれば良いでしょうか。答えはおなじみ「目的・課題・アクション」です。プロジェクト自体を目的・課題・アクションで進行する以上、プロジェクトの記録である議事録も、この枠組みに沿って記述するのは理にかなっています。
議事録には、次の内容を必ず記入するようにします。

1. 日時
2. 場所
3. 出席者
4. 目的
5. 結論
6. アクション
7. 議論の内容
8. 次回予定

１番から３番に関しては問題ないでしょう。「首相官邸方式」で良いです。ただし、出席者を書く順番や、肩書きの書き方などについては組織の文化に合わせてください。基本的に「お客様から、偉い人から、肩書きは間違わないように」書けば間違いありません。
それよりも大事なのは、目的と結論です。どのような目的でこの会議を開いたのか、正しく簡潔に書く必要があります。そして、その目的に対してどのような結論が出たのか、これも簡潔に書きましょう。注意点として、目的と結論は読み手の立場から見て分かり易いように記述する必要があります。いきなり各論に入らずに、本質的な内容を書くよう心がけてください。
アクションも目的や結論同様に重要です。目的から課題を導き出し、適切にアクションを設定したのであれば、結論から次回の予定にストーリーがスムースにつながり、プロジェクト全体のストーリーも見えやすくなるはずです。もちろん、前節での定義に従い、アクションには担当と期限を明示してください。
各論や、議論の内容、重要な発言に関しては、補足に近い形で「議論の内容」に書きます。これが、首相官邸方式の「会議の模様」に相当する部分です。ただし、発言についても要約して書くようにしてください。議事録全体のボリュームが大きくなりすぎないよう気を払うことで、議事録を書く時間を短縮することができます。

議事録ドリブンな会議とは

次に、より積極的に議事録を生かすテクニックとして、「議事録ドリブンな会議」を提案しましょう。ちなみに、「ドリブン」とは駆動する、という意味で、議事録を中心にした会議運営術を意味しています。
ここまでの説明でお気づきかとは思いますが、「目的・課題・アクション」軸に沿った議事録を書くのは、実は簡単ではありません。かなり真剣に書く必要があります。
これはなぜでしょう？逆説的な言い方をすれば、それは会議自体がこの軸に沿っていないからなのです。実際問題、目的すら良く分からない会議が開催されることすらあります。このような会議に参加してしまった場合に、自分は関係ないや、と放っておくのもよいですが、あなたのプロジェクトに影響を与える会議の場合はそうもいきません。
以降、現場リーダーのあなたが仕切っている・仕切ることができる・仕切る責任がある「ホーム」会議と、あなたが仕切っていない・仕切れない・なぜか呼ばれてしまった（迷走気味の）「アウェイ」会議に分けて、議事録ドリブン会議の運営方法を「目的・課題・アクション」軸に沿って、それぞれ説明してみましょう。
特に迷走するアウェイ会議の場合は、議事録が書けません。それを、「議事録が書けない会議は困る」とばかりに、型にはめるのが議事録ドリブンな会議運営なのです。

目的を確認する … ホームの場合

定例のプロジェクト進捗会議の場合、まずは前回の議事録を使って、今回の目的について確認します。前回議事録の次回予定が、そのまま今回の目的になるはずです。また、前回から今回の間に新たな議題が発生している場合は、その件についても目的に加えて、事前に合意しておきます。
ホーム会議はあなたが進行を行いますので、この段階で目的をきっちりと確認することができますし、多少の問題提起による脱線もありでしょう。

目的に食い下がる … アウェイの場合

まずは、目的について食い下がってください。悲しいほど目的意識のない会議の場合がありますが、このような会議は結論が出ることは期待できません。あきらめずに、最低限の目的の共有と合意をして、会議の道筋を作ってあげる必要があります。ここでのポイントは、あまり話を広げすぎないことです、参加者の大半が理解でき、議論ができる範囲の現実的な目的設定が良いでしょう。今後も開催が必要な会議の場合は、会議の後の議事録を含めたフォローでストーリーを組み立てなおす必要があるかもしれません。
ただし、ここで目立ちすぎると余計な反感を買ったりして、いろいろと面倒なことになる可能性もあります。そういう意味からも、話は広げすぎずに抑えておくことも必要です。熱くなる気持ちを押さえ、冷静に淡々と話しを進めます。

課題を共有する … ホームの場合

進捗会議の重要な目的の一つとして、課題の共有が挙げられます。現在、プロジェクトはどのような位置にいて、どのような課題があるのか。それに対してそれぞれどのような活動を行っているのか、複数チームで構成されるプロジェクトの場合、特にこの課題共有は貴重な時間となります。
それぞれの課題がプロジェクトチーム全体にどのような影響を与えるのか、顧客満足志向の視点に立って、情報を共有します。

課題を掘り起こす … アウェイの場合

そもそも、課題が見えない場合が多くなります。目的がよくわからない以上、自然とそのようになってしまいます。何か会議らしいことをしているのだけど、何故か現実的な感じがしない場合は、課題がまだ見えていないことが多いのです。進捗会の場合であれば、プロジェクト固有の問題点などについて言及されずに、一般論に終始したぼんやりとした話が多く、単にやったことの羅列を報告しだした場合は要注意です。このような場合は、どのようなプロジェクト固有の課題があるのか、そしてそれがプロジェクトの価値にどのようなインパクトを与えるのか、そのあたりを切り口に、まずは「課題を重視する姿勢」を意識してもらうように働きかけましょう。

次のアクションを決める … ホームの場合

会議の締めはアクション決めです。ここまで順調に進んでいるのであれば、自ずと、誰（あるいはどのチーム）が、どの課題について担当するのか、明らかになっているはずです。担当と期限を決め、次回の開催についての決め事を行って会議をクローズします。順調に進んだ会議であれば、議事録を書くのにそれほど時間はかからないはずです。想定していたストーリーにそって議事が進行している場合は、その内容を議事録という形で外部記憶化しておく感覚で進めることができます。

今のアクションを確認する … アウェイの場合

おそらく、迷走するアウェイ会議の建て直しは一回ではできません。根気よく付き合っていく必要があるでしょう。できれば関わりたくないところですが、そうはいきません。このような状況では、いったん立ち止まるのが良いでしょう。次のアクションを急いで決めるのではなく、今何ができるのか、どのようなことを行う必要があるのか、「今のアクション」を決めるよう提案してみましょう。
ただし、ここで「議事録ドリブンでいきましょう」などといって、明示的に型にはめてしまってもうまくいきません。議事録ドリブンとはいっても、それは進め方を表す表現の問題であって、会議は議事録に書くために行うものではありません。

誰に議事録を書かせるか

議事録を重視する以上、議事録係は重要な役割となります。あなたのチームのメンバーのうち、最も期待するメンバーに書かせてください。質の高い議事録を書くのは難しい作業なので、とてもためになります。議事録で鍛えた能力は、あらゆるビジネス文書に応用することができます。
もちろん、あなたがまだ本当の議事録を書いたことがないのであれば、まずはあなたから始める必要があります。

改定版である『チームビルディング』には具体例など内容が追加されてたりしますので、興味ある方は読んでみてください。

『ファミコンの驚くべき発想力』〜制限から生まれる工夫

ここ最近では一番面白かった。
僕はファミコン世代の人間だけど、実はゲームはするより、作るほうがおもしろかった。小学校当時PC6001で一番最初に作ったのは確かじゃんけんゲーム。その後数年かけてアドベンチャーゲームとか、RPGとか、シューティングとか対戦格闘とか一通り作った（全部BASICだったけど）。

ファミコンの驚くべき発想力　?限界を突破する技術に学べ? (PCポケットカルチャー)

この本の良いところは、古き良きファミコン時代のノスタルジーを喚起するだけでなく、コンピュータの基礎が学べるところ。CPUとかメモリとか、レジスタとか。シフト演算で乗算と除算を行うと軽い、など組込み開発でも通じるテクニックとか。

ファミコンというハードのすごいところは、本書にもある通り「遊べる性能」とコストとのバランスだと思う。あと、ROMカートリッジを採用したことによる拡張性の高さ。だからあれほど長い間遊ばれることになった。（そういえば、当時のコナミのゲームの拡張音源は素晴らしかった！）

そして、制限の中で闘ったプログラマの工夫の一部が技術的に垣間見れるのも面白い。ドルアーガの塔の迷路は実はランダム（ステージ数をランダムのシードにしている）で、容量圧縮のためだったとか、最終フロアは偶然あの形になったとか、ドラクエのストーリー進行は7ビットで復活の呪文に保存されている、とか。オールドゲーマーの自分にとっても新鮮な情報も。

気楽によめつつ技術的な内容も充実しているので、ゲームマニアじゃなくても読む価値あり。ファミコン時代の古い話だけでなく、オブジェクト指向やガーベージコレクションなど、「現代プログラミング」の功罪についても若干触れており、フレームワークや用意されたAPIなどのプラットフォーム前提で開発することが現代の開発者にとっては考えさせられる。

2011年の一文字は「幸」

新年あけましておめでとうございます。今年は前厄ということで、昨日お祓いに行ってきました。早いもので40歳になっちゃう年なのです。
いまさら昨年を振り返ると、アウトプットの乏しい1年でした。業界というか人様のために役にたつ成果を残せませんでした。理由はいろいろあるのですが、あえて一言でいえば様々な迷いの中で自分を見失っていた気がします。
ということで今年は原点回帰を目指し「幸」という一文字を抱負にします。「幸」は私の名前（の一部）であり、生まれながらに背負っている文字です。40年近く前、両親が私に込めた祈りの文字。その意味をもう一度考え、仕事やプライベートでお会いする人全ての幸せ＋に寄与できるよう、よりアクティブに行動します。
本年もよろしくお願いします。

組込みプレスVol20

本日発売の組込みプレスVol20の特集2「ICTから学べ〜これからの組込み開発者に求められるスキル＆マインド」に、永和システムマネジメントのメンバーが執筆しています。

組込みプレス Vol.20

「第2章　コンポーネント指向による要求分析/ 設計の実際〜UML/DFDの活用」と「第3章　組込み開発でテスト駆動開発は有効か」がそれです。いずれも現場で主導的な立場で動きつつ、バリバリ開発をしているメンバーによる実践的な内容が特徴となっております。
まず第2章。コンポーネント指向は組込み開発でも取り入れられつつあります。筆者の藤井さんはそれを現場で実践し、UMLだけでなくDFDを組み合わせたモデリングをしています。実情に合わせた工夫をしているのがユニークで実戦的です。
第3章の筆者森さんは、アジャイルの肝となるテスト駆動による開発が、組込みでも使えるのかどうか、テストツールやカバレッジツールの説明を交えながら解説しています。
また、今回の特集のもう一つの特徴は「コラボ」です。第1章では、自動車業界におけるTier1サプライヤである三井金属アクトさんによる「MBDを品質確保とコスト削減に利用する」という取り組み。第4章は全社的に要求開発に取り組まれている大阪NDSさんによる、「組込み分野における要求開発」という取り組み。いずれも弊社とのご縁から、今回の特集に協力していただいております。
第1章・第4章とも、「これからの組込み開発者に求められるスキル＆マインド」という大きなテーマにフィットするように、それぞれの業務における実体験を抽象化し書いていただきました。

組込み開発者に求められるスキルは年々高まり、必要となる知識もIT関係だけでも広がる一方である。機能が複雑になればなるほど、コアロジックや特定分野の制御技術だけでなく、ネットワーク機能やユーザインターフェースといったレイヤの機能開発も避けられない。ひと言でいうなら、組込みデバイスとPCの境界がますますあいまいになり、それぞれの応用分野におけるオーバーラップが大きくなっている。
このような大規模開発では、専門分野ごとにモジュールやコンポーネントの分離、分業が進んでいるが、製品やシステムの設計者、マネージャは全体を把握する必要がある。現場の開発者も、プロジェクトの規模によっては、自分がカバーしなければならない領域が得意分野や専門分野とは限らない。
この特集では、ICTというアプリケーション開発やシステムインテグレート（SI）という視点から、組込み開発にも応用できるプラクティス、開発スキームはないだろうかということを掘り下げる。

以上は特集の扉ページからの引用ですが、あらためて第1章から第4章まで読んでみると、随分幅広いテーマになったものだと感じます。エンジニアには当然スキルが必要ですが、同様に「もっとよいものを、もっとよいやり方で作りたい」というマインドも大切です。具体的なスキルについては第1章から第3章が、マインド面については主に第4章がカバーします。現場で実際に開発をされているエンジニアから、マネージャ層まで、幅広く読んでいただける内容になっていると思いますので、是非一度手に取ってみてください。