『【軍曹が】携帯電話開発の現状【語る】』にみる組織運営の問題点

[【軍曹が】携帯電話開発の現状【語る】](https://gist.github.com/ryunosinfx/ea45e74d6df1d3bcd8fbd2f22dfb8b6a)
の事例に見る組織運営の問題点を、いまさらながら指摘してみようと思う。
ガラケーの携帯電話のソフトウェア開発という今はなくなってしまった開発分野なので、問題点をいまさら指摘しても実害を被る人もないだろう。

(個人的には、某都市銀行のソフトウェア開発における組織運営の問題点と解決するため指針とを知りたいとところだが、)

前に、[もし軍曹が携帯電話をいま開発したら](https://qiita.com/nonbiri15/items/6f9d362371bd4b9452d0) を書いたときには、ソフトウェア開発におけるツールの状況が、当時と今とでどのように変わっているのかを述べた。

しかし、個別の技術的な課題か山ほどあるときには、個別の技術的な課題以上の組織運営上の問題があることが多い。

そのような組織運営上の問題点が、個々の技術的な問題を生じさせていることが多い。

組織運営上の問題は、技術的に解決しうることを、解決不能なアプローチに落とし込んでしまう。


---

## 俺たちが派遣された場所の前任者(というより部隊)は全員ウツになって戦線離脱したらしい。引継ぎも全く無いまま、というよりドキュメントらしい物も無かった。

- 問題のある組織の場合には、あるチームのメンバーがまるごと離脱するということは、実際に起こりうることである。
    - チームのメンバーがまるごと離脱するというのは、ある意味チームワークが働いていて、互いにチームのメンバーが困らないように配慮している場合もあるだろう。
- チームを取り囲む組織運営に問題があるときには、新規のチームメンバーで入れ替わっても問題を再発する。 
    - チームのメンバーが全員離脱するということは、そのチームを取り囲む状況になんらかの問題があることを意味する。
    - その状況にある課題が開発の本質にある場合、チームのメンバーが入れ替わったとしても、同じような状況を繰り返してしまう。
- そのチームを取り囲む部分の問題を解決することが、チームを成功に導く。

## 仕様は何度問い合わせても、問い合わせが上位会社へ何段も口頭で伝えられるうちに伝言が自然消滅してしまうようだ。

- 開発を発注する側と受託する側はビジネスとして対等であるということを、この当時は自覚されていない。
    - いまならば、[「情報サービス・ソフトウェア産業における下請適正取引等の推進のためのガイドライン」](https://www.meti.go.jp/policy/it_policy/softseibi/070620soft_guide.pdf) が推進されている。

- 仕様の重要性・設計思想の重要性
    - 携帯電話のソフトウェアという巨大化したソフトウェアを、適切な仕様なしに分業して開発が遂行できると信じれる人がいるだろうか。
    - 適切な仕様とは、なぜそのような仕様になるのか、設計思想が明確になっていなければならない。
        - 実現したい内容の業務知識の理解の重要性
        - 実現するためのソフトウェア言語・ライブラリ・アルゴリズムの理解の重要性
        - 仕様を作成するためには、上記の２つの項目についての理解が２つとも必要である。
        - そのように仕様を作成すればうまくいくと判断できる高い能力がいる。
    - 設計思想が明確になっているときは、既に存在する仕様書に対する未定義部分が発生したときには、どのように未定義部分を実装するのかを考えることができる。
    - しかし、仕様書を提示することさえできないマネジメントがなされるときに、開発チームにできることは少ない。
- 仕様の重要性の軽視：
  - 該当の業務知識がない人・プログラミング経験に乏しい人に仕様設計をさせてしまう。
  - そのため、仕様には抜けがあったり、無駄に遅くなってしまう仕様だったり、テストの実行が困難な仕様になってしまう。


## 依頼主も孫請けらしく、正確な情報はかなり伝言ゲーム的にそれも口頭でしか伝えられない。

- 多重請負という責任・権限が不明確な状況をしているという問題。
    - 実現する価値がなにであり、どういう設計設計であるのかを開発プロジェクト全体で共有させること。
    - 外部仕様が明確になっているモジュールを下請けに発注して開発するのならば、外部仕様・コーディングのガイドラインを明確にしたら、テスト条件を明確にしたならを示したら、あとは受注した組織に任せるしかない。
    - 外部仕様が不明確な発注は、発注者の落ち度である。
- 外部に開発を委託するモジュールがあっても、それはそのモジュールを外部に委託して行う利点が明確であって、上手に仕様を切り出せる部分について行うべきだ。
- 開発速度を上げるためには、アジャイルな開発をするのがのぞましい。そういう分野では、仕様書を細部にわたって記載しきって、それのとおりに実装を依頼するという作業分けにはなりにくい。
    - 実装する開発言語で実用水準のコードを書いたことがない人が、机上で仕様を作成して、その仕様で開発を外部に依頼するというスタイルは、いまだに日本でのソフトウェア開発では存在している。
    - 一方では、実装する開発言語でどのようなライブラリがあるのか、その言語のどういう機能を使うと目的を達しやすいのか、そういう知見があったうえで外部仕様を作成する人もいる。
    - 机上で仕様を作成した人の場合だと、考えなければならない項目に対して抜けが生じたりする。
    - 机上で仕様を作成した人の場合だと、その外部仕様の実現可能性を無視したものになってしまうこともありうるだろう。
    - 仕様書を作成する側のスペシャリティを重視してほしい。


## 土日はすべてスケジュール回復対策会議のようなものに駆り出されて、膠着状態の会議に何時間もの間、発言権も無くただ同席させられた。

- 発言権がない人を会議に招くこと自体が組織運営として間違い。


## 10万行に及んだスパゲッティは、俺たちの日夜の努力によって5万行にまで減った。


- テスト駆動開発をしていない時点で、改変によって結果が変わってしまっていないか保証できない。
- リファクタリングは自動化テストというセイフティネットがあってこそ、安心して行われるのだということを、この開発現場では守られていない。


## 数日後、伝言が口頭で伝わってきた。俺たちが派遣されてきた当初のソースを、全てコメントアウトされた形でソース内に復元させろ、とのお達しだった。

- ソフトウェア開発で何をすべきで、何をしてはならないかを知らない人が、開発をコントロールしている。
- しかも、実際の問題のなかで、よりよい方法をさぐろうとしていないことが、この例の中では見られる。

## コンパイル担当の者(朝から晩までコンパイル！)から伝言が伝わってきた。「ダブルスラッシュなコメントは禁止だと伝わっていなかったのか？」

- 仮にコンパイラが貧弱でダブルスラッシュなコメントを受け付けなかったとしても、それを手動でソースコードを修正するのは、得策ではない。
- 言語仕様でダブルスラッシュなコメントをサポートするようになっているのだから、その処理系がいずれはダブルスラッシュなコメントを受け付けるだろう。
- 正規表現を用いて文字列を加工する仕組みをコンパイラの前処理に加えれば、手作業で修正する必要はない。
    - "//"で始まる場所から行末までを削除するだけの処理をコンパイルの前に行えば、いいだけの話だ。
-こういったところで、開発の現場に無駄な作業を発生させる時点で、組織運営として間違っている。 

## テスト要員を一気に5倍に増やして、人海戦術によるデバッグが賢明だとトップが判断した。

- トップの判断が間違っていることよりも、間違っている判断であることをトップに伝える方法がない・機能していないことが問題。
    - 最初から正しい判断だけをできる人は存在しない。
    - 自分の判断が間違いであることを学ぶこと。
    - 学び続けられるられるかどうか。
- ここにある状況では、技術的には次の問題があるだろう。
    - 品質は、ソースコードを書く時点で作り込むものであるということを軽視している。
    - 人による手動のテストではなく、可能な限り自動化テストを行うのがよいということを軽視している。
    - テスト不能なインタフェースをもつ設計は、設計として欠陥であると私は考える。

### 近年の日本では役職を職責ではなく何かの報酬かと勘違いしている事例が見られる。

- その職責を果たすために必要な資質は何なのか、必要な才能は何なのか、それらを考えることがなされていない。
- そのため、その責務を果たす上で必要な能力や誠実さに欠けた人物が要職についてしまうという事例に事欠かない。

### 人は判断を間違えるものである。（自分もしくは他人の）失敗から学べるかどうか 

- 失敗から学ぶためには、エビデンスを残すことが大切。
- （自分もしくは他人の）失敗から学べることが、成功する組織を作れるかどうかにつながっていく。

## すぐにも近隣の都市から派遣社員の吸い上げに入った。派遣会社も今までに無い大盛況なので、経験の有無を問わずにフリーターまで確保に走った。

- 人月での商売の悪癖。
- しかるべき水準の技能を持たないものは、いくら人数がいても役に立たないことを理解していない。
- 人月商売の発想が抜けきらない会社と組むと、「どれだけの人月数の作業をしぼりとるか」という発想の行動に巻き込まれ、開発の目的を達成するパートナーとしての行動をとってもらえないことがある。
- その場合には、投資した人月の割に使い物になる成果が得られないということがある。
- かたや、開発の目的を理解し、それをともに実現しようという会社と組んだ場合には、お互いに能力を高め合うような開発スタイルがなされる。
- そのため、お互いの知見を出し合ってよりよい開発がなされやすい。

### 目的を共有しない関係で開発がされるとき　生じうる悪癖
- 問題が生じた時に、問題をともに解決しようとするのではなく、「それは自分のところの責任じゃない」ということを主張する。
- 要求仕様に変なところがあっても、ほんとうにその仕様でいいのか確認するのではなく、「書いてあるとおりに実装したんだから、書かれていない部分に問題を生じても、それは自分たちの責任ではない」ということだけになりやすい。
- さらには、不十分な要因による影響を拡大解釈して、自分たちの開発がうまくいっていないのは、彼らのつくった不十分な仕様・不十分な実装のせいだというようになりかねない。
 
#### 排他的な利害関係者を組み合わせて、円滑な開発ができるわけがない。



### 俺の所属会社も本件では赤字状態に陥り、経験者まで数人失う損失を被ったのだ。

- 受託開発する会社は、発注先の仕事を選ぼう。
    - ソフトウェアを開発するのが人であり、その人を大事にすることができない発注元の会社とは付き合わないのが一番である。
    - 「うちのシステム開発では死人がでるのは日常茶飯事」などという会社とは付き合わないことである。
- チームとして、困っている人を手助けしよう。 
    - 人は、業務上のプレッシャーを過度に与えられしかも人的にも孤立してしまう状況では、弱い判断に陥ってしまいやすい。
    - たまたま与えられた部分が貧乏くじだったとしても、それから安全に逃げられること。
    - 貧乏くじの無理のある案件では、担当者とされてしまった人が、チームに助けを求められるようにしよう。
    - その貧乏くじの案件で困っている人を救い出すこともできない人が、困っている人を無能と判断するのは横暴だと私は考える。

## 背景：大手携帯電話メーカー(当時)の組織的問題点

- 当時の大手携帯電話メーカーでは、携帯電話の量的な拡大の中で、新機種の発表の頻度を高いものにしていました。参考：[携帯電話の機種の歴史](https://ja.wikipedia.org/wiki/%E3%83%91%E3%83%8A%E3%82%BD%E3%83%8B%E3%83%83%E3%82%AF_%E3%83%A2%E3%83%90%E3%82%A4%E3%83%AB%E3%82%B3%E3%83%9F%E3%83%A5%E3%83%8B%E3%82%B1%E3%83%BC%E3%82%B7%E3%83%A7%E3%83%B3%E3%82%BA)
- 量的な拡大をしているだけで、質的な改善がどれだけなされたかは疑わしいものです。
- 大手携帯電話メーカー(当時)は、その組織・人的な面でも量的な拡大はしましたが、質的な変化を引き起こせていたかは不明です。
- 量的な拡大は、市場の拡大によって引き起こされたもので、メーカー自体の組織運営の良さを反映したものとはいいかねます。むしろ組織運営の悪さを覆い隠してしまったと入れるでしょう。
- 携帯電話の出荷台数の増大のタイミングで、運良く部門のリーダーに選ばれた人に、複雑化していく携帯電話の開発を単純にするための設計と開発を指導する力量がどれほどあったのでしょうか。
    - 年功序列型の組織運営では、その組織をマネジメントするのにふさわしい能力の人選ではなく、それまでの実績に対する報奨としての待遇としての人選をしてしまう。
    - 実務を遂行する上での実務能力を軽視するマネジメントがなされる日本型組織運営。
    - 社内政治の圧倒的な影響力
    - 技術者を道具と見下していないか。
    - 専門能力の高い人を見下す（根拠なき）博士課程終了者に対する就職差別。
    - 結果を出している技術者の価値を評価できない人事システム
    - 職制の上の人の評価が高くなるように配慮された評価基準
    - 高い専門性に基づく結果を出すことのない人でも高い評価が得られるように配慮された評価基準

- 閉鎖的な組織運営
    - 問題点を指摘し改善への糸口を見つかられるような企業文化はあったろうか？
    - セクショナリズムに凝り固まった透明性の惡さ
    - 評価主義の導入にともなう排他的な利害関係を職場に持ち込んだこと。
- スマートフォンの台頭が既に始まっているのに、それへの対策をできなかった、組織運営のまずさ

### 大手携帯電話メーカー(当時)のすべきだったこと(私見）

- その職責を渡すのふさわしい能力を持つ人員を登用するマネジメントに組織運営を変えるべきであったこと。
- 排他的な利害関係を導入する評価主義ではなく、協調によって組織全体の利益が増えることによる評価システムの構築。
- 複雑化が進行し続けていた携帯電話システムで、複雑化を抑制するためのビジネス・設計・開発などのマネジメント。
- 顕在化する前にリスクに対して備えることのできる先見性のある人を活用すること。
- 先見性をもって対応するための企業内の部署間を超える知見を共有できるシステムの構築。

### いまだったらこうするよね
- 職制という支配によるマネジメントから合理性に基づくマネジメント
- プロダクトオーナーという役割の重要性
- テスト駆動開発・スクラムなどの重要性がわかっている人の採用
 

# 私見
- 失敗を繰り返し続けている組織は、組織運営上の問題を抱えている。
- その組織運営上の問題こそが、個別の問題を引き起こす大きな背景になっていると考える。
- 仕様とは、価値をもつソフトウェアの意味の塊を明確化する作業だと思う。
    - 作り出したものが十分な価値をもたない理由のひとつは、仕様の作成の時点で失敗している可能性すらある。
    - 仕様の不明確な点を明らかにしていく作業は、対話の積み重ねである。
- 対話は、組織運営の中の重要な要素である。
- 対話が、共通の目的を実現するために設計思想を共有してなされていくことを裏付けしていくのは、組織運営である。
- よりよい方法であるかどうかは、誰が言ったかには関係しない。
- よりよい方法を採用できる組織運営の柔軟さが求められる。

- ソフトウェアの開発は、新しい価値の実現であらねばならぬ。
    - ソフトウェアエンジニアは、自分がどのような新しい価値を提供できるのかを考え続けよ。
    - 社会がどのようなサービスに価値を見出すのかを見極めよう。
    - あるライブラリを使いこなせることに価値があるのではなく、どのような価値を実現できるかに価値がある。