漢(オトコ)のコンピュータ道: チャットで役立つ英略語12個

2013-05 23 English tips chat

というわけで、今日は英語のチャットで頻出する略語を10個紹介しよう。外人とチャットするときにはぜひ利用して欲しい。略語を使えばタイプの手間が省けるだけでなく「ちょっと英語が上手に使えるように見える」という効果も期待出来るので一石二鳥だ。

1. ty, thx
Thank youおよびThanksの略。

わざわざこんなのまで略さなくてもいいんじゃないか？と思うかも知れないが、お礼を述べる場面はとても多いので意外と便利である。ギーク同士で話していると技術の話題に花が咲く。何か教えてもらった時はお礼を言おう。

ちなみに、thxには10xというバリエーションも存在する。

2. yw, np
You're welcomeおよびNo problemの略。

お礼を言われたら「どういたしまして」というのは万国共通である。You're welcomeといえば「あなたからのお願いはいつだって歓迎よ！」などとちょっと大げさな表現でちょっと当てつけがましいように感じる時がある。そんなときはNo problemのほうがスマートだろう。

3. lol
Laughing Out Loud

つまり（笑）と同じ。日本ではよく（笑）の略として ｗ が使われるが、これは外人には通じないので注意が必要である。

4. btw
By the way

ところで・・・と話題を変えるときに使おう。

5. atm
At the moment

銀行のATMのことではないので注意。意味は「現時点では」とか「今のところは」など。

6. fyi
For your information

ご参考まで。

7. diy
Do it yourself

自分でやりやがれコンチクショウ。

これに似た意味のものとしては、rtfmという略語がある。こちらはRead the fucking manualの略。つまりマニュアル嫁！

8. brb, bbs, bbl, afk
それぞれ

Be right back
Be back soon
Be back later
Away from keyboard

の略。

ちょっと席を立つときに利用する。例えば便所に行くときなども「ちょっくら便所いってくらあ」的な表現を用いてはならない。紳士はbrbなどと言って席を立つものである。

9. wb
Welcome back

おかえり。

10. iirc, afaik, afaict

If I recall correctly
As far as I know
As far as I can tell


「私の記憶が正しければ」とか「私が知る限りでは」的なニュアンスの言葉。ちょっと自身がないなーというときなどに利用するといいだろう。

11. imo, imho

In my opinion
In my humble opinion


「俺が思うに」とか「私的には」という感じの意味。

12. pebkac
Problem exists between keyboard and chair

直訳すると「問題はキーボードと椅子の間に存在する」という意味になるが、キーボードと椅子の間には人が座っている。つまり、問題があるのはコンピュータを使ってる人間＝ユーザという、ちょっと皮肉った表現である。使い方を間違ってるのにコンピュータやプログラムのせいにしている人に対して使う。また、誤ったオペレーションをしてしまった時にも使える表現である。

最近あったGmailの障害やDoblogの障害などはPEBKACなのではないだろうかと想像している。（テストが十分でなかったり監視を怠っていたり。）

開発現場の天国と地獄（1）：“完璧な設計”がプロジェクトを失敗に導く！？ (1/2) - ITmedia エンタープライズ

2013-05-14 project management development case

開発現場の天国と地獄（1）：“完璧な設計”がプロジェクトを失敗に導く！？ (1/2)
[佐藤大輔（オープントーン），＠IT]

共有
Googleブックマーク
Yahoo!ブックマーク
はてなブックマーク
ブログに書く
メール
プリント／アラート
プリント／PDF
この記事の関連記事をメールで受け取る
連載アラートNEW!
PR
どこまでクラウドサービスに移行すべきか？　識者が提言！！

　本連載では筆者がかかわった実際の開発プロジェクトを詳細に分析、検討し、そのうえで、ソフトウェア開発プロジェクトを成功に導く要因あるいは失敗に陥る原因などを探っていきます。連載を展開するうえで筆者は「開発プロセスと開発効率には何らかの相関関係がある」という仮説を掲げています。つまり、開発プロジェクトをスムーズに進め、最終的に成功へ導くためには、適切な開発プロセスの存在がどうしても必要なのではないか、という立場です。連載中にはさまざまなタイプのプロジェクトが登場しますが、千差万別の事例分析を通じて、この仮説の普遍性を明らかにできればと考えています。

　ところで、一般的に開発プロジェクトの失敗（あるいは効率が明らかに低かった）原因として以下のようなことが指摘されます。

最新の開発プロセスを適用しなかったから？
プロジェクトマネージャの能力が低かったから？
エンジニアが慣れていない最新の開発技術を適用したから？
結局、顧客の要求仕様が固まらなかったから？

　このような指摘の中で、最も多いのが「人」に失敗の原因がある、とするものです。では、優秀な人を集めればプロジェクトの効率は無条件に上がるのでしょうか？ 優秀な技術者を雇うにはそれ相応のコストがかかります。例えば、従来よりも人件費が10％アップすれば、プロジェクトの成功率が10％以上上がるといえるのでしょうか？ もちろん、実際の話はそれほど単純なものではありません。（エンジニアのスキルを含めた）多くの要素を検討し、効率アップにつながるものを1つ1つ丁寧に集めて初めて、プロジェクトの効率は上がるものなのだと思います。
プロジェクトの成功と失敗を考察する≫成功と失敗≪を考察する

　プロジェクトの成功と失敗を定義することはとても難しいものです。例えば、予算が超過すれば、そのプロジェクトは即、失敗プロジェクトであるといえるでしょうか？ 納期を超過したら、プロジェクトは失敗といえますか？ バグが発生し、契約の瑕疵（かし）条項を顧客が適用したときに失敗プロジェクトとなるのでしょうか？

　顧客側もソフトウェアを開発する側もともに利益を追求する企業ですから、予算が見積もりの金額を超えた場合には「失敗」といわれることが多いといえます。しかし、そうなるとプロジェクトの成功／失敗の要因は、「見積もり」や「営業活動」、「顧客の予算」に集約されてしまいます。つまり「見積もりで吹っかけておけばプロジェクトの成功率は飛躍的に高まる」という乱暴な結論になってしまいます。

　おそらく、プロジェクトマネージャの手に案件が委ねられる時点では、上記のような見積もりなど予算に関する要因はすでに決定されている場合がほとんどでしょう。故に、上記のような乱暴な結論を導くと、そもそもプロジェクトの成否はマネージャの手にはないという結論になります。

　やはり、プロジェクトの成否を問う場合には、多くの要素や結果を列挙しなければなりません。列挙した要素の分析結果が、開発会社の組織やチームにフィードバックされて初めて、開発プロジェクトの効率化を追求する要素（ノウハウ）が蓄積されていきます。本連載で扱うプロジェクト案件についても、成功か失敗かという単純で二元的な視点だけではなく、プロジェクトを構成するのは数多くの要素があり、どの要素が効率を落とし、どの要素が効率を上げているかという多面的な視点で検討していこうと思います。
プロジェクト1：「最新プロセス（Unified Process）適用事例」（注）

　プロジェクト運営に関する記述を読むと、優秀な技術者やマネージャを確保することがプロジェクト成功の決定的要因として述べられています。
（注） Unified Process（UP）については、Javaオブジェクトモデリング第1回「連載を読む前に知っておくべきこと」参照。

　このプロジェクトはおそらく、優秀な技術者を集めることがプロジェクト成功の確実な要素ではないことを物語る良い例だと考えられます。すなわち、優秀な人がいないから、ではなく、優秀な人がいたにもかかわらず予算を超過し、開発者に大きなストレスを与えるプロジェクトとなってしまったのです。このプロジェクトは後に第三者から、「新しい技術を使い過ぎて失敗したプロジェクト」だとか「まとめる人に問題があった」と評されました。しかし、実際にその現場にいた多くの開発担当者たちは、もっと別の問題を「やりにくさ」として感じていたのです。

　では何が足りなかったのでしょうか。実際に現場で起こったことを引き出してみます。
［プロジェクト概要］
名称 プロジェクト1「最新プロセス（UP）適用事例」
案件 金融会社の契約管理システム開発
言語など Java、EJB、Struts
開発環境／ツール Eclipse、Together、DB2、WebSphere、Solaris、HttpUnit、JUnit
プロジェクトの規模 6カ月以内、最大50名
結果 カットオーバー成功（納期OK）、大赤字
対予算経費率 150％
顧客満足度 ○
［問題点］
作業者の管理
×
開発プロセス（UP）
×
開発能力
◎
分析設計
◎
チーム全体のコミュニケーション
×
◎＝良（問題なし）
○＝やや良（ほぼ問題なし）
△＝やや難（やや問題あり）
×＝難（問題あり）
［コメント］
作業者のストレスは非常に大きい。徹夜と頻繁な休日出勤。平均月間労働時間350時間超。増員で乗り切ったため、予算的には大幅な赤字となった。

　以下、この開発プロジェクトを時系列で検証していきます。
（1） 開発期間6カ月程度のうち、最初の3カ月
　　　　　　 1|2 次のページへ

Copyright© 2013 ITmedia, Inc. All Rights Reserved.

共有
Googleブックマーク
Yahoo!ブックマーク
はてなブックマーク
ブログに書く
メール
プリント／アラート
プリント／PDF
この記事の関連記事をメールで受け取る
連載アラートNEW!
Special

  • PR -

システム構築のプロが語るJSカスタマイズ

グループウェアのJSカスタマイズツールで何ができる？
開発不要のツールでユーザーと技術者の可能性が広がる
サーバに変革の波！　その全貌が明らかに

各アプリケーションに「専用サーバ」を用意する新発想
世界のデータセンターが抱える諸問題を解決できるか
グローバル競争時代に企業は何をすべきか？

クラウド セキュリティ 事業継続　事例や有識者に学ぶ
複雑化する情報システム、IT戦略の有るべき姿を探る
百社あれば百通りの標的型サイバー攻撃対策

情報窃取を狙う、APT攻撃の見えざる脅威
カスタム化した多層防御と専門家の知見が企業を守る！　
ホワイトペーパー（TechTargetジャパン）

順調だったプロジェクトが迷走するとき
【ヘルプデスク運用】４つの導入事例にみる成功の秘訣〜お客様対応からＥＲＰ導入まで〜
CMSは魔法のツールではない！ CMS導入を成功へ導く9つの条件
ITプロジェクトポートフォリオマネジメントで、IT投資に関わる情報を一元的に可視化
要求どおりのシステムが出来上がらない？「エンドユーザーもにっこり」の要件定義

powered by newziaコネクト
TechTarget 製品情報

「素早く」「安全に」社外メンバーとクラウドで情報共有『IBM SmarterCloud Connections／IBM SmarterCloud Meetings』
効率だけのクラウドから、企業を革新するクラウドへ。『IBMクラウド事例集 2012年改訂版』
EIP・グループウェア・ナレッジマネジメント機能を統合し、”今やるべきこと”を可視化『INSUITE(R)』
あらゆるリスク領域への対応を可能とする『IBMセキュリティー・ソリューション総合カタログ』
1,800社超のノウハウが凝縮されたスマホ対応営業支援システム『eセールスマネージャーRemix Cloud』

page: 2
前のページへ 1|2 　　　　　　
（1） 開発期間6カ月程度のうち、最初の3カ月
UMLは高精度

　開発作業従事者は15名程度でした。この段階のフェイズはUPにおける推敲フェイズに相当します。UPに従い、設計はユースケース駆動を採用し、顧客の要求をUMLで記述していきました。この段階は、UPという開発プロセスの基本に丁寧に沿ったプロジェクト運営でした。つまり、UMLの精度は高く、実装作業者の負担はかなり少ない状況でした。
ALT 図1 推敲から作成フェイズへ

　この時点での成果物は、UMLの各図（ユースケース記述、シーケンス図、クラス図、ER図、業務フローを分析したフローチャート図）とフレームワークの一部でした。特にシーケンス図はほとんど実装レベルの詳細さで素晴らしい出来でした。なお、UMLの作成にはボーランドのTogetherを利用しました。

　設計者はエース級の上級エンジニアばかりでした。もう一度同じ人材を集めるのは非常に難しいと思います。EJB（Enterprise JavaBeans）を実装できるほどのスキルを持つエンジニアの数は決して多くはありません。設計もデザインパターンを利用した非常に技術レベルの高いものでした。
ALT 図2 設計者はエース級の上級エンジニアばかりだった

　さて、この段階で不思議なことが起こりました。15名程度のプロジェクト参加者のうち、特にアーキテクトを中心とする5名前後の人々が連日の徹夜残業を余儀なくされ始めたのです。プロジェクトは中盤に差し掛かっていました。残りの10人は18時ごろには帰り支度を始めていました。作業進ちょく管理表も少しずつ訂正が多くなり、誰の目から見ても予定より遅れ始めていました。このような状況でも、本当に働いている人は、不思議なことに数人でした。
このプロジェクトに何が起こったのか

　このプロジェクトに何が起こったのでしょうか？ そして何が原因でこうした状況が起こったのでしょうか？ 完ぺきな設計と優秀な技術者、UMLで書かれた素晴らしい仕様書、フレームワーク（Struts、EJB）をはじめとした実装を支援する最新技術がそろっていました。このチームには何が足りなかったのでしょうか？ いままでの記述だけで、多くの方は気付いたかもしれません。「設計者が不足している」というのが当時のプロジェクト従事者の意見でした。確かにそうだったかもしれません。

　しかし、本当の問題はこの段階で「完ぺきな設計」をするという態度にありました。プロジェクトの初期段階で一部のすきもない「完ぺきな設計」を行ったら何が起こるでしょうか？ 「設計」と「実装」が際限なく近づくという状況になるのです。つまり設計にかかる工数が実装なみに膨らんでしまうのです。

　多くの現場ではマネージャ＜設計者＜実装者という人数比率になっています。確かに推敲フェイズは設計の負荷が重いフェイズですが、設計の精度を100％に近づけようとする試みは、そもそも「イテレーション」の意図（変化の許容）に反するのです。

　UMLの有効性、初期の詳細設計の重要性とプロトタイプ（機能の一部）の動作までの詳細設計は、明らかにプロジェクトの効率を上げます。しかし、同時に実装者への「権限委譲」は実は非常に重要な要素なのです。それはしばしば「いいかげんな設計」として実現されますが、本当はそれこそ「良い加減」なのかもしれません。

　この時点ではプロジェクトは「地獄」というほどではなくむしろ多くの実装者にとって「天国」でした。
（2） カットオーバー1カ月前
新規エンジニアの参入

　この作成フェイズで設計段階の遅れを取り戻そうと、設計者の負荷が非常に高い状態になっていました。この時点でプロジェクトの進ちょくが大きな問題となり、大幅増員が決定しました。増員においては、テストを行いふるいに掛けたことなどが幸いし、質の高い技術者が集まりました。エンジニア各人のスキルレベルの高さは、プロジェクトへの参入障壁を下げたと思われます。

　また、仕様や環境設定、ツール類の情報をWeb上で管理していたのも、プロジェクトの新規参入者が（プロジェクトに）スムーズに合流できた要因だと思いました（このプロジェクトではWikiを活用し、サーバのIP／ID／パスなどの情報や開発環境構築のための手順書を管理していました）。ユースケース記述もすべてWebに格納され、実装担当者がその都度、設計者に聞き直す必要がありませんでした。ユースケース記述を基にユースケース駆動での開発がスムーズに進められたのです。
ALT 図3 作成フェイズで設計段階の遅れを取り戻そうとした

　その際に非常に興味深いのが、チームへの機能の割り振りを、機能の関連性や画面やエンティティの類似性によらず、緊急度の高いユースケースから順番に手の空いたチームに割り振ったことです。私はこの方針には反対でした。というのも、仕様的に近い機能は、同じチーム（や人）がまとめてやってしまった方が明らかに効率が良いからです。

　実際、効率は若干落ちていたように思われます。しかし、意外な効果が得られました。どのチームも触れたことのない機能を突然割り振られることに慣れ、開発者全体で“広く浅く”システム全体の仕様が理解されるようになっていきました。そして、障害の発生時には「ほかのチームの担当分でも直せる」という現象を生み出したのです。

　4〜5人のチームを1ユニットとし、計4ユニットが稼働している体制でした。さて、ここでユースケース駆動の大きな欠点の1つが洗い出されました。ユースケース駆動による開発作業では、ユースケース記述を書き並べたインデックスを基に作業を行っていきます。その記述1行1行がいわばストーリーカードのように各チームに配布されていくのです。
システム全体の姿が分からない

　ある日、開発者の1人がこういいました。「システム全体の姿が分からない」。つまり、それぞれが関連性のないユースケースを、1行ずつこなしていく実装チームには、自分たちの作成しているユースケースがシステム全体の中でどのように流れているかが見えなくなっていったのです。細かく分割された「ユースケース・オブジェクト」を開発している開発者・設計者には木はともかく、森の姿が見えなくなっていったわけです。システム全体の姿が見えない開発作業は各チーム間の連携を急速に失わせ、結果として仕様を含む情報の伝達不足、共有すべき技術の非共有化を招いていきました。各チームのリーダーは自分のチームが担当するユースケースにしか興味がなくなっていきました。例えば、後続の機能に影響があるような修正を行っておきながら、ほかのチームには知らせなかったり……。

　一方、この時点でも、設計者は詳細なシーケンス図の作成に追われていました。

　森全体を管理する人はなく、いつまでたってもシステム全体の姿が見えてこない状況でした。しかし、このような大規模システムでは、森全体を管理する方が設計者にとっては重要な作業なのではないでしょうか。

　この段階で、何とも不思議な問題が顧客と開発チームの間で取りざたされるようになりました。「仕様書がない」という問題です。前述のようにこのプロジェクトでは、UMLで非常に詳細な設計を行っています。数百万円ものUMLモデリングツールを活用し、クラス図、シーケンス図なども顧客に提示しています。ユースケース記述はWeb上で常に見ることができます。ではなぜ、「仕様書がない」という奇妙な問題が発生したのでしょうか。

　理由は2つ考えられます。

　第1の理由としては「画面仕様書がない」という点です。UMLでは画面仕様書を定義していません。しかし、実際の開発では、画面仕様書は非常に重要です。これがないために、顧客は仕様の追跡性を失ってしまい、結果的にシステム全体の姿を見失ってしまったのです。

　第2の理由には「UMLが顧客向けでない」ということが挙げられます。実装作業を想定して英語で記述されたクラス図やシーケンス図は、顧客にはとても難読なシロモノでした。特にユースケース記述は非常に重要な仕様書であるにもかかわらず、テキスト中心であるために、顧客に読みにくさを印象付けてしまったのです。その結果、われわれが納品した仕様書を片手に、仕様書を要求されるという奇妙な事態になってしまったのです。
プロジェクトが地獄になり始めた

　開発現場では、開発プロセスとは関係のない「よくある問題」もいくつか発生しました。例えば、テスト環境へ修正版をリリースするたびに基礎的なバグが大量発生しました。このことは顧客の（われわれに対する）信頼性の低下を招き始めました。なぜ、こんなことが起きたのでしょう。開発者も設計者も仕様変更やバグのおおよその影響範囲を短時間で想像できます。このことは逆に、テスト範囲を“効率化”させてしまいます。つまり、影響のありそうな範囲に焦点を当てたテストはきちんと行われるけれど、影響の薄そうな部分のテストを行う時間は削減されていってしまったのです。

　もちろん、JunitやHttpUnitは「繰り返しテスト」を簡単に行うことができます。しかし、ビューの問題（画面デザインの崩壊）や開発者・設計者の意図しない問題には、そもそもカバーするようなテストコード・シナリオが用意されていない場合が多いのです。結局、仕様書を片手に、全機能をテストするテストチームが結成されることになりました。この専任テストチーム（4?5人）がこの混乱を収束させたことはいうまでもありません。

　大幅増員を決めたことで分かるように、そのあたりから一気にプロジェクトは設計者だけでなく全員にとっての地獄となっていきました。経費的にも急速にふくらみ始めましたし、作業者への負荷は「設計の遅れ」を取り戻すべく異常な速度での実装を求められました。それはとりもなおさず、「28時までには仕上がります」という形でプロジェクト内を飛び交うようになったのです。
（3） カットオーバー直前からカットオーバー以降へ
仕様変更の連続

　いよいよカットオーバーが見えてきましたが、「イテレーション」を標ぼうする多くの開発プロセスで発生しているのと同じ問題も発生していました。つまり、提案段階で訴えた「可変性」に基づく直前の仕様変更の連続です。延々と続く新たな仕様への対応は開発者のモチベーションを急速に奪っていきます。今回の「イテレーション」では、ほかの機能に影響のある比較的大きな修正も相次ぎました。この場合、該当する新機能や修正した機能を各チームで調整し、タイミングを合わせてリリースする必要がありました。その結果、プログラムの異なるバージョンが大量に発生しました。

　この管理／運営にはCVSのブランチ機能が大変役に立ちました。ブランチ分けして、仕様変更や新機能を取り込んでいない「確実に動く検証可能なバージョン」と「新機能を取り込んだ調整中のバージョン」の共存により、ほかのチームへの影響を最小限にとどめることができました。CVSのおかげで比較的スムーズにバージョン管理ができたわけです。
ALT 図4 いよいよカットオーバーが見えてきたが……

　ただし、ブランチ機能を活用する際、修正をバージョン双方に反映させる必要があるため、「自分のしている修正がどちらに反映されるべきか」を慎重に管理する必要があります。設計者は常に、どのような機能がそれぞれのバージョンに取り込まれつつあるかを監視する必要があります。

　さて、この段階で「リリース時によく起こる問題」が発生してきました。主なものに、環境の違いによる障害対応があります。仮環境と本番環境でシステムの挙動が明らかに違う場合があることは当然です。その「誤差」をいかに修正するかというのが終盤に至って重要視される問題です。例えば、WebSphereにEJBを利用したシステムをリリースする場合はデプロイメントマネージャを利用するのが普通ですが、顧客の本番環境ではデプロイメントマネージャが利用されておらず、回避策などをベンダへ問い合わせて検討する必要がありました。致命的な問題であるにもかかわらず、ベンダや顧客のシステム運用部隊と協議し、調整をしなければいけない問題だったので非常に時間がかかりました。

　テストデータを誤ってチームメンバーが削除してしまい、復旧に多くの工数を要したということもありました。カットオーバーした後で、開発サーバを引き上げるという話も出ました。結局は引き上げたのですが、そのダメージは意外と大きかったことをのべておきます。どういうことかというと、新しい開発サーバは複数のプロジェクトで共有するルート権限がなく、その都度依頼しなければならないために効率ダウンを引き起こしたのです。また、長い開発期間のうちに少しずつ効率化を促進するためのツールの導入や設定改良を行っていたのですが、それを一遍（いっぺん）に失ってしまったわけです。
別案件の到来

　そして、この段階に至って、次々と別案件（別プロジェクト）が現れ始めました。これらの案件は現在進行中の開発環境に加わり、連携機能などを要求してきました。納期まで時間は限られています。現在作成している機能が“落ち着いて”から新たなプロジェクトを開始しようなどという悠長（ゆうちょう）なことはいっていられず、ほとんど並行開発のような状態で開発をしていました。

　もちろん、この状況でもバージョン管理は有効な解決策だったのですが、これ以上に有効だったのは、全体のアーキテクチャを監視し、交通整理を行い、技術リスクを排除していくチームの存在でした。このチームは非常に高度な技術者で構成されており、それぞれが実際の設計者以上に大きな視点でプロジェクト全体を見ていました。彼らの存在は、移行フェイズでのシステム連携といった多くのリスクを取り除く非常に有効な要素でした。

　完全に佳境に入ったプロジェクトは2日徹夜、3日徹夜の対応を作業者に求めました。机の上で眠り、3食を机の上でとるという、まさしく“開発現場の地獄”となったのです。
（4） プロジェクトの特徴を振り返る

　一般的にこのプロジェクトは、コスト超過という要因から失敗プロジェクトと認識されています。しかし、私の目から見た限り、

納期に間に合った
コードの品質は高い
技術的な再利用価値が顧客・開発者双方に残った
開発プロセス運用のノウハウが蓄積された

といったメリットを考慮すると、失敗プロジェクトと簡単に割り切るわけにはいきませんでした。最後に、このプロジェクトを構成する特徴的な要素を指摘して第1回をしめくくります。

完璧に近いシーケンス図は設計者の意図を正しく実装者に伝えることができるが、非常に設計コストがかかる
プログラムの書き方や実装方法までを設計情報に埋め込む必要はない
仕様を顧客に理解してもらうためには、UMLの記述だけでは不十分
予算を高めに設定してでも、優秀な人材を確保すること。納期に間に合った要因の1つは優秀な人材の存在にある
全体的なコードレビューを行い、技術リスクを取り除く“フレームワークチーム”の存在は有効。彼らが最終的なコードの品質確保した
難しい技術（今回はEJB）を利用しても、技術者のスキルレベルが十分にあれば、特に効率を落とすことはない
チームと機能を結びつけず、ユースケース単位で開発作業を進めた。その結果、開発者全体で“広く浅く”開発中の機能情報を共有できるようになったが、システムの全体的な流れを把握できなくなった
新しい技術を積極的に利用するのは、技術者のスキルレベルが高ければプロジェクトの成功につながるが、一般的にはプロジェクトの成否には関係ない
CVSは非常に有効にプログラムの管理を行った
高額なUML設計ツールを用いたが、十分に有効であった

著者プロフィール

佐藤大輔

　有限会社オープントーン社長。会社設立前から財閥系大手システム会社などで多くのシステム開発に主にマネージャーとして携わる。あくまで「現場主義」であり、自身含め社員全員が「本物の実装能力を持つ」がモットー。「案件完遂率100％」と「必ず新しい技術を織り込む」ことを前提とした技術集団を率いる。言語・フレームワーク・プロセス・ツール、あらゆるものをシラミ潰しに実際のプロジェクトに適用し、最適な開発を日夜探しつづける。今の使命は本稿などを通して、「実験結果」を社会にフィードバックし、「新技術や新発想」と「現場」の紐付けをしたいと考えている。