ベンダー下請けからの脱却

まさにリアルタイムな状態だけど、チームがベンダー下請け仕事からエンドユーザ仕事に転換するのには、障害が多くつきまといます。

一旦営業的なものはナシにして、現場レベルで書き上げてみましょう。 ・・・ウチだけだったらハズいなぁ・・・

ひたすら待つ

とにかくお客さん待ち。 んで、待つだけ。回答が出るようなアプローチを一切しない。 そしてスケジュールが遅れた時の言い訳は

お客さんから回答が来てないから。

ですね。

スケジュールの進捗を再優先にする

いや、それ自体は問題ないとは思うんですけど、スケジュールを守るためだけに、ものづくりに必要なステップをかなり飛ばしている。

  • アプリケーションの方式
  • 運用の方式
  • お客さん業務のケア
  • etc...

最も意識を向けているのは

タスクが終わること。

ですね。

スコープの切り方が極端 or 切れない

これは人によるのか、下請け時の契約体系にもよりますが、2パターンありますね。

  • 業務範囲を考慮せずに、アプリケーションレベルで要求をバッサリ切る
  • お客さんの要求を何でも聞いてしまう

こういった現場に対してこんな質問をすると、

これ使ってお客さん仕事できるの?

大体愚痴か黙秘しか生まれません。

大事なのは「お客さんの業務を手伝っている」という意識を持つこと

「業務システム」って、お客さんの業務を手助けするものに過ぎません。お客さんの業務にフィードバックされ、成果が得られない限りは、その業務システムに価値はありません。 *1

BtoCのサービスと、BtoBのサービスでは価値の生まれる場所が違います。 ・・・いや、あんまり違いはないかも。

システム開発は第4次産業あたりですけど、この産業って、第1〜第3次産業の価値を高めるためにある産業だと思っています。 作ったものを買って/使ってくれるのは第1〜第3次産業の人の場合が多いと思うので。


20代のうちに下請けから出ると、そういった意識改革は伝わりやすいのですが(まぁ上司命令と思われているかもしれませんが・・・)、問題は更に年齢が上、もしくは上司に対してその意識改革を行うことは、とても難しい。

まさに今私が直面している問題です。

・・・みんなどうやってるんだろうなぁ。

*1:成果といっても、コスト/リターンの生産性向上だけではありません。システム化が当たり前の昨今で人員の責任感を高めることを課題としている会社もあります。

どうしてこんなになるまで放っておいたんだ

f:id:saikou9901:20150921223104j:plain

これ読んでます。

プログラマが知るべき97のこと

プログラマが知るべき97のこと

この中の7つ目のエッセンス『共有は慎重に』ってとこ、ちょうど読んでるんですが、すごく頷きました。

考えた結果わかったのは、私が1つ重大なことを見逃していた、ということです。

それは「コンテキスト」です。

たとえシステム内に同様の処理を行う部分が2つあったとしても、両者のシステムにおける役割が大きく異なっていれば、再利用によるメリットは少ないのです。私がコードをライブラリ化するまで、そのコードを利用する部分間に依存関係はまったくありませんでした。元々の成り立ちが全然違うコードだったのです。従って、状況やニーズが変われば、その後各部分のロジックにはまったく別の変更が必要になる可能性が高いということです。

―『共有は慎重に』より抜粋

いま、あるお客さんが使っていたパッケージソフトウェアを、スクラッチで抜粋して移植するというプロジェクトを管理しています。 一部、新規設計の箇所もあります。

プログラマーが何人かいますが、提供されたパッケージのソースを追っていて、つくづくこういう言葉が出てきます。

  • 「このコードひどいな!何も考えてない!」

  • 「なんでこんな処理してんの?こうしたほうが理にかなってるじゃん」

新規の設計の箇所については

  • 「こうしたほうが無駄が無くないですか?」

無くないってなんだよ。今夜はブギーバックかよ。

そして共通の決めセリフはこれです。

  • 「ここ、こうしちゃっていいですか?」

ごもっとも・・・ごもっとも・・・


というわけで、もっぱら最近の私の仕事は次の通りです。

  • 「このコードは、きっとこういう運用を想定してつくってるんですよ。ですので、現行のままにしてくださいね。。。」

  • 「ここは、今後お客さんが運用していくとこういう風になりそうだから、冗長にしてるんですよ。ですので、設計書のままにしてくださいね。。。」


既存のコードがあって移植する時やリファクタリングする時、それだけでなく、新規に設計・コーディングするときも、冒頭の引用で謳われている「コンテキスト」(意図、歴史、背景・・・ってことでいいのかな?)を気にすることが大切だと思います。

この本は読み終わったら会社に設置しよう・・・

アクティブなPGとパッシブなPG

f:id:saikou9901:20150822015346j:plain は、どうやって判断しましょう?

(主に派遣の話です)

アクティブとパッシブ

アクティブなPG
  • 詳細設計不要(コーディングスキルはひとまず問わず)
  • 単体試験仕様書がなくても、普通運用では落ちない
  • 問題に直面した時、推理や解決策を持って報告
  • 「ちょっと待ってて」って言ったら、自分のコードと他の人のコード見比べてる
  • 土日明けたら、金曜終了時点で迷ってた処理をサラサラと書き始める
  • 指示者の仕様に対して、代案を提示してくれる
パッシブなPG
  • 詳細設計書が必要
  • 単体試験仕様書が必要
  • 問題に直面した時、問題が起きたことを報告
  • 「ちょっと待ってて」って言ったら、自分のコードと仕様書見比べてる
  • 土日明けたら、金曜終了時点からスタート
  • 指示者の仕様に従って、素直にコーディングしてくれる

ここでは、どちらのPGが良い・悪いかについては言及していません。
プロジェクトに応じて、必要なPGは変わってきますよね。

メーカー系ののようなでかい開発なら、管理チーム、技術チームの下にパッシブPGで人海持って、そりゃ軍隊のごとくシステムを踏破していくでしょう。

逆に数百万規模新規開発や、技術チーム補填には、アクティブなPGでなければ解決課題は貯まる一方。

楽しく仕事しましょうよ

派遣さんは面談して入れるけど、面談でどういう質問をしたら、この人が「アクティブ」or「パッシブ」なのかを見極められるのか、長いこと考えてます。

なぜか

その人が純粋に取り組める仕事を"任せたい"からです。

専門職でも、一般職でも、
楽しくなければ仕事の成果は出ないな~と思っています。

そのためには、その人に合った作業を任せることが大切だと思います。

本人が楽しくないと、仕事に成果が出なくて、任せるほうも楽しくない。
その仕込みをサボらないだけで、プロジェクト期間が1ヵ月でも半年でも1年でも、楽しく酒が飲めるわけですよ!


というわけで、「アクティブ」or「パッシブ」の判断ポイント、誰か教えてくだしあ

先生、アウトプットがしたいです

f:id:saikou9901:20150607143423j:plain

最近、定時間内だけでなく、そのあとや休日も、ずっと仕事のこと(悲しいかな、引きずられて会社のことも)考えてます。

※"定時間内"という考えに愚かさを感じる人もいるかもしれませんが、
 今回はそこには言及しません。

炎上しているわけでなく、お金が動く作業をずっとやっているわけでもありません。
次のようなことをやっています。

定時間内
  • タスクとして割り振られている開発作業
  • たまに割り込みで発生する運用・保守作業
定時間外
  • 進行中の案件の進捗整理・作戦立て
  • 次の案件に向けての提案・技術検証
  • 労働組合(には入ってないですが、社員が運営する似たような組織)の活動
休日

役職的なところもあり、定時間外にやる作業が結構増えてきました。
私は結構面倒くさがりで、休みの日は正直ゲームしまくって過ごしたいんです。

でも、最近パズドラもテラバトルも、スタミナ溜まりっぱなしで平日を迎えることが増えました。
Bloodborneも、"ヤーナムの闇"戦前で放置しっぱなしです。

続きを読む