新卒から文系エンジニア→人材業界に転職した人のブログ

新卒から文系エンジニア→人材業界に転職。技術・スキルがないためブログを通して勉強。その後、IT業界の業界知識が活かせる人材業界へ。異業種×異職種の転職経験有り。

このエントリーをはてなブックマークに追加

【読書メモ】システム開発の失敗を考える~「考え方の論理」~

【今回の紹介】

以下の方を読みながら、実務(システム開発)を思い浮かべながらおもしろいなーと思った部分を抽出しました。

考え方の論理 (講談社学術文庫 45)
考え方の論理 (講談社学術文庫 45)


【内容】

本書の内容として「考える」という行為について以下の二つのアプローチで進んでいきます。

 ①「考える」→ものやひと、景色などを知覚するという意味

  例)なにを考えているの?
    〇〇があるなーと考えていました
  
  
 ②モノとモノの関係について考察するという意味

  例)〇〇と〇〇の関係性についてどう思いますか?
  〇〇と考えます


全体的に文系の数学が得意でも何でもない自分が読めるほど内容としては簡易なものでした。

ここから面白いなーと思った部分と実務(システム開発)を考えながらを紹介します



①モノの名称を正確に認識し、その位置づけをわかっていることが大切


 筆者はモノを知っていることはとても大事だと言っています。

 そこでいう知っているとは、そのモノ自体がどのグループに属するか

 という位置づけを理解していること
 
 例)フランス人という名称は、
  
  狭鼻類というグループの中の
  
  人科というグループの人間という
  
  グループに属する。

 
 ■実務(システム開発)では
 
 
 こうしたある一つ用語が全体中のどういう位置づけなのかことは、システム開発でも
 
 顧客の業務用語を整理していくときに使用している
 
 気がする。
 
 〇〇という用語は、○○という業務の中で、○○という時期の中で〇〇という場合に
 〇〇することを指しているんですね。
 
 といった形で。
 
 同じような言葉でも、人によってその言葉の定義は微妙に違ったりしてUI工程以降に
  
 認識の齟齬が明らかになり、仕様調整になった例を知っている。
 

②複数の動作をまとめている動詞があることを意識する

 当たり前なんだけどいわれてみるとなるほどという感じ。普段はおおざっぱに動詞を定義して

 会話しているけど、人によってその動作の中身はその時その時で異なる。

 この例に挙げている「洗濯する」という動詞も時代によってさす動作の内容も変わるし、人によって

 どこまでが「洗濯する」という動詞に含まれるか変わるのかもなー。

 (「洗濯機をまわすとこまでだろ」とか「洗濯機をまわすとこからだとか」)
 
 例)洗濯をする
   ①洗濯物をかごにいれる
   ②洗濯機に入れる
   ③洗剤をいれる
   ④洗濯機をまわす
   ⑤洗濯物をとりだす
   ⑥洗濯物を干す
   
 ■実務(システム開発)では

 これも上流の工程の例だけど。顧客の要求を砕いていくときに同じような思考方法
 
 で考えていくのかもしれない。たとえば、
  
 顧客「ここで計算したい」
 
 というのは、「○○の時に計算したデータと〇〇の時に入力したデータを〇〇の時期に
 
 計算するということですか?」
 
 ということは、

 ①〇〇を計算する

 ②〇〇を入力する

 ③①と②という計算するという

 ことを計算するという認識でよろしいですか

 という具合に
 
 顧客が「したいこと」を順序だて・かつ細分化して、言葉がさしている動作を
 
 共有するときにこれを意識する
 
 気がする。
 
 んできっと、それをより詰めるためにそのあと「なんのために・だれが・いつ」
 
 を明確にして、それを実現する手段を提案していくと思う。
 
 
 ちなみにこれがうまくいかず、
 
 同じような動詞でも、定義は微妙に違ったりしてUI工程以降に認識の齟齬が明らかに
 
 なり、仕様調整になった例を知っている。

 

③「すべて」と「ある」を意識する

 よくテレビのトーク番組とかで見る光景だなーと。

 韓国人は○○だとか、中国人は○○だとか日本人は勤勉だとか

 「すべての」ではなく、ある韓国人とかある日本人はという表現を
 
 することが論理的なのではーと。自分の経験や勘、知識だけで
 
 すぐに物事を一般化することは注意しなきゃと思います。
 
 自戒を込めて。
 
 
 ■実務(システム開発)では

 
 顧客「ある時期にはこういうデータがはいってきます」
 
 SE「わかりました、ある時期にはこういうデータパターンがはいってくるんですね」
 
 顧客「はい」
 
 こういうときにこの時期に入ってくるデータパターン」うちの「あるデータパターン」なのか
 
「データパターン」はこれが「すべて」なのかを明確にすることが大事。

 何も意識してないと、すべて仕様におとしたように思ってしまう。
 
 ちなみにデータパータンもれで、UI工程以降に認識の齟齬が明らかに
 
 なり、仕様調整になった例を知っている。
 
 
 
自分達が思っているより、「考えること」の前提になっている「言葉」というのは「あいまい」

とくにSEという職業では顧客の実現したい業務を明確しなくてはならない。

その時に相手が使用する言葉がなにをさしているのか、砕きながら慎重に

認識を合わせなくてはならないんだなーと再認識



言うほど簡単であるならば、グーグル検索でSE 炎上とかで予測変換されないんだろうけど

.hatena-module:nth-of-type(10) { background: transparent; } .hatena-module:nth-of-type(10) .hatena-module-title{ display: none; } .hatena-module:nth-of-type(10) .hatena-module-body { padding: 0; }